Help troubleshooting for customer, please

[Marstol Nitely]

Thanks Allen. I can't find the asset number in my inventory, so I'm at a loss as to what the problem was. It's on its way. Let me know if you have any other problems. Thanks for your patience.

[Marstol Nitely]

I uploaded the item again yesterday and received no error messages. I tried to find the problem and no such asset exists in my inventory. I sent the item to Allen under a different name, at another grid. He is receiving the same error. The second jukebox I sent cost me the 60KC in market fees. I was willing to put that down to the cost of doing business, but it's looking more like I'll have to refund the money that was paid through Pay Pal originally. Not sure why you seem so unwilling to help me out here Ilan. Have I done something to offend you?

[Ilan Tochner]

You haven't done anything to offend me Marstol and I AM trying to help you.

First, if you use go to your store's Sales History page you'll see an option to Refund a purchase. Doing so gives the buyer the full amount of the purchase in KC, taking the marketplace sales commission back from Kitely (as per the Kitely Market section of our Terms of Service). There is no out of pocket money for you if you refund purchases that way.

If the delivered item can't be rezzed because it is missing some asset then either something in that delivered object has that asset UUID but hasn't been delivered to the buyer's grid or that delivered item is trying to access a UUID of something which it doesn't contain. Looking at the item in question can help determine what in that object has that UUID. It can be referenced by a prim, a mesh, some script, etc. Fnding what is referencing that UUID in the product can help pinpoint the source of the problem.

Did your customer get a message about the same UUID missing? If the UUID changed that may help us in the investigation.

[Marstol Nitely]

I have refunded him and I did look at the item and looked for the original asset that was reported missing. It was not in my inventory. I see that you are right about me not losing money out of pocket, but I have now lost a sale. It's not a lot of money. The main problem is making sure it doesn't happen again. There isn't much use in my allowing export on items if people can't export them and I can't solve the problem. I feel like I've already wasted a lot of Allen's time (which he's been very nice about), but I'll see if he still has the message or can repeat the error.

[Ilan Tochner]

We also want to make sure all purchased items are properly delivered. It's important for our marketplace's reputation.

When exactly is he getting the error?

Is he getting it when trying to rezz the delivery box from Kitely Market (the one with the order ID on it)?

Is he getting it when trying to rezz the box inside it that contains your item?

Is he getting it when trying to get the content of that box?

Is he getting it when trying to rezz the item once it is already inside his inventory?

His Kitely Market purchase included delivery of items from multiple merchants, did any of the other items fail to rezz?

[Marstol Nitely]

I will relay the questions.

[Ilan Tochner]

Thank you Marstol.

[Dot Matrix]

The problem seems to be that the asset in question is so large that the asset server in the grid "p0qp0q" is failing to store it. To check this theory, I made a test delivery of the product to my avatar in Metropolis and it was delivered fine (I was able to rez both jukeboxes).

Here are some more details:

This is the product: http://www.kitely.com/market/product/25 ... ar=2524331

It contains a couple of Coalesced Objects: "Jukebox V.3 (Google - No Radio)" and "Jukebox V.3 (Radio & YouTube)". The first of these coalesced objects is failing. Our logs show that the asset was sent to the grid p0qp0q, and the grid claimed to receive it, but in fact the asset doesn't exist there. This is why rezzing the object fails.

There have been two attempts to deliver this product to grid p0qp0q, and in both cases this particular object ("Jukebox V.3 (Google - No Radio)") failed to be saved on the grid's asset server. The size of this asset is about 2100 KB, whereas most of the other assets are under 100 KB. The log shows that sending the asset took longer than usual, in both delivery attempts (that's what causes the log line "Slow SynchronousRestObject request"):

Code: Select all

2014-10-16 21:19:28,776 INFO  (132) OpenSim.Framework.SynchronousRestObjectRequester - [LOGHTTP]: Slow SynchronousRestObject request 2212 POST to http://www.p0qp0q.com:9000/assets/ took 5950ms, 5406ms writing, <U+FEFF><?xml version="1.0" encoding="utf-8"?><AssetBase xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><Data>PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmL
2014-10-16 21:19:28,777 DEBUG (132) OpenSim.Region.CoreModules.Framework.InventoryAccess.HGAssetMapper - [HG ASSET MAPPER]: Posted copy of asset 0c9d28d6-53dc-480c-821d-bbcbbb046198 from local asset server to http://www.p0qp0q.com:9000/

....

2014-10-17 20:38:02,182 INFO  (618) OpenSim.Framework.SynchronousRestObjectRequester - [LOGHTTP]: Slow SynchronousRestObject request 3102 POST to http://www.p0qp0q.com:9000/assets/ took 6056ms, 4291ms writing, <U+FEFF><?xml version="1.0" encoding="utf-8"?><AssetBase xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><Data>PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmL
2014-10-17 20:38:02,182 DEBUG (618) OpenSim.Region.CoreModules.Framework.InventoryAccess.HGAssetMapper - [HG ASSET MAPPER]: Posted copy of asset b14550bc-e037-4c18-a4ad-8d25448e5866 from local asset server to http://www.p0qp0q.com:9000/

The fact that sending this item took longer than usual is not a problem: that's to be expected with an asset of such a size. But it leads me to believe that the problem is that the asset server in that grid is unable to receive or store such large assets.

You can see that the asset server failed to store the asset by attempting to access the asset directly from the asset server. The following URL *should* return the asset, but it actually returns nothing:

http://www.p0qp0q.com:9000/assets/0c9d2 ... cbbb046198

In comparison, here's a URL that accesses one of the other assets that were sent in this order. This URL *does* download its asset:

http://www.p0qp0q.com:9000/assets/e740a ... e153c383ce


We've sent large assets in Kitely Market in the past, so we know that they work. For example, Amiryu Hosoi sells very large Japanese structures, which are also coalesced objects (and therefore large assets), and they were delivered ok. And, as I mentioned in the beginning, I sent this Jukebox to Metropolis and it worked fine.

So my conclusion is that the problem is in the receiving grid's asset server, which is failing to store large assets. Even though it's failing to store the asset, the asset server doesn't return an error code (if it had returned an error code then we would have reported that). The next step is to find why the asset server is failing and fix it.

One random guess: perhaps the MySQL Packet Size is set too low? In older versions of MySQL the maximum packet size was set to 1 MB, which would prevent storing an asset that's over 2 MB in size. See: http://dev.mysql.com/doc/refman/5.5/en/ ... large.html

Another random guess: if the grid is hosted on a limited network (e.g., a home computer?) then the network might fail or not allow receiving such large objects.

[Marstol Nitely]

Thanks Oren. That's a lot of very good information. Fortunately, this is my largest item and I have a smaller version that I was going to upload once we figured out what the problem was. I'll try to update it in a little while. Hopefully, that one will work. And thanks to Ilan for hanging in there until something could be figured out.

[Allen Partridge]

Oren,

Thanks for the tip. I've updated the database to support larger MB files (I hope) and will see if that helps.

--Allen