Odd 2032 Error...

[Guest]

I've had 2032's before, and typically they are from a malformed URL or file name... not this time. I am getting thie when trying to upload a b64 encoded jpg to a server. It works fine 100% of the time when on a fast connection. When in the field however, or if I throttle my bandwidth with Charles, I am getting it. Listening for a HTTPStatusEvent gets me nowhere, it traces a 0 when I get the stream error. It's not a script timeout issue either, I've tried increasing that with no result. If I turn off throttling everything works... if I simply turn it back on then I get the stream error (2032) after 15-20 seconds of uploading.

I'm not sure how to fix, or if it's possible. The data is uploading to a .net script if that matters. Anyone else seen this before?

[Guest]

Figured this wouldn't get much traction... I was thinking I could rephrase this as "Why can't Flash upload something for as long as it takes?" I need to experiment a bit, as I don't recall seeing this as an issue, and I think I would have. Maybe it's something with specifically uploading to IIS...

Another thing I am seeing - there does seem to be some bug with URLLoader. I am using Charles to see the request and it goes like so: Flash starts sending and gets to some amount of data sent - then I get the 2032 error. But Charles still shows the upload progressing... So I close the player window. Charles still shows the upload progressing... Seems a thread was started by the player and it's not being shut down.

[Guest]

Well, I thought since the upload kept progressing I might be able to just suppress the 2032 and let it go. It does complete, and the server even returns the success code, however the COMPLETE event never fires - Charles says the client has closed the connection... hmmmm

[_spoboyle]

I don't envey you trying to sort this one out.

Is it possible to try and test this on a low bandwidth network without the throttling, just in case it's the throttling process that's causing an issue?

[Guest]

Thanks, but it's not the throttling - I am throttling to simulate the slow connection in the field. I don't think there's much more I can do on this one. Definitely seems to be a bug in URLLoader / Player as the thread just continues to send data even when the player has been closed... I even tried re-adding the COMPLETE listener in the error handler and it still doesn't ever fire. Going to go file a bug report now.

[sinious]

Have you tried the bandwidth simulator built into the flash debugger itself?

URLLoader is async, it will not cause any kind of script timeout. Want a script timeout? Run an infinite loop (e.g. while (true) {}). Anything async will never cause a script timeout.

Are you using any try {} catch() {}? That may catch the error and give you more information on its nature.

[Guest]

I can't use Flash's bandwidth simulator - it's an AIR app. Charles' throttling is tried and true though, that is definitely not an issue. And Yes the load is wrapped in a try/catch but the load isn't failing, the catch never fires. An IOErrorEvent is what's being thrown - though there seems to be no reason for it as the load continues as I've mentioned.

[sinious]

It's a generic stream error from IOErrorEvent. A file not found can trigger that off too. I'm going to assume since it works without throttling that it's not a malformed URL. Though are you sure Charles, which is intercepting every packet, isn't doing something undesirable? Seems hard to write off.

[Guest]

I use Charles a lot... I'm pretty certain it's not the issue - and beside the error is generated in the field, when on a slow connection and not throttling. I am simply trying to replicated the field environment. And the URL is definitely correct.

As far as a throttle threshold - not exactly. It seems more time dependent than anything. At 30 seconds I'm getting the error, no matter how much has been uploaded... there's just more or less uploaded depending on the speed. I know it's async an all, but as of right now it certainly seems time dependent.

[sinious]

Is the server that's receiving the image doing it via something like PHP? If so do you know the PHP scripts timeout setting?

[Guest]

It's a .net script that's accepting the post, and no it's not timing out. As I mentioned earlier, once that 2032 is thrown the upload actually continues - and finishes - and I get a result back from the server. It's just that once the error is thrown, the complete event is never thrown so I can't listen for it.

[sinious]

So ASP. A 2032 isn't thrown for fun, there must be a reason flash player (especially at a repeatable exact interval) is thinking it's no longer receiving data.

What do you trace() while the progress happens? Do those events continue to fire after you 2032? I realize "a thread" is still doing it but I'd like to know if Flash itself is aware and still sending events based on progress.

[Guest]

Yes, as I did say - once the 2032 is thrown no other events are captured. The complete never fies, even once the upload is completed and the server returns the success variable. So no, Flash is no longer aware after the error.

I can't waste any more time on this. I'm going with this - 'get a better connection or it isn't going to work'.

[kglad]

are you using the file class, file reference class or bytearray to upload your file?  are you listening for progress events so the player knows updates are occuring?

[sinious]

Yes the OP just mentioned the progress events are ending after the 2032 is reached. I'm still thinking this is some kind of server issue rather than flash. Flash is sensing an issue with the server, throws up the appropriate error for that situation. The continuing transfer is strange but how many times has anyone ever packet sniffed flash to see what really happens when that error fires? Perhaps it ALWAYS finishes the transfer and we just never knew.

Regardless, if possible, you should try putting that file on a completely different server. A non-windows box if possible. If you want I can host a test file and give you a direct URL for you to see if my servers act the same as yours.

[Guest]

I am using URLLoader and POSTing.

[kglad]

ohhh, you're uploading data.  (and, it must be a fair amount.)

how much data are you uploading and what's being returned from the server?

[sinious]

Yes meaning if it's a technology I support I'll host the upload script and give you an URL to test, assuming it's no proprietary piece of software.

[Guest]

Yeah, it's anywhere from about 400K to 2MB - it's a B64 encoded jpeg along with some form data. From the server I get a success=false or success=GUID

Thanks sinuous, but I can easily test on another server. If I have some time today I'll give it a try.

[sinious]

If it's PHP the default is 2MB on upload just FYI. Taking a shot in the dark there. You can increase that limit.

[_spoboyle]

look's liek you've definately found something odd going on.

out of interest can you find a throttle threshold where it starts working again?