Retry

[vlad]

Hi,

I'm using the chunked HTTP upload with the "retry" parameter set to "3".
If one chunk fails ([ERROR] HTTPUploadTransfer - java.net.SocketException: Connection reset by peer: socket write error) and the applet has to retry the transfer, at the last chunk the applet fails with the following error:

Code: Select all

Upload failed: java.lang.ArrayIndexOutOfBoundsException: 29

Seems that by retrying something in the Java code goes wrong.
Please advise.

Thank you,

Vlad

[support]

This only appear if "retry" parameter is enabled, correct ?

[vlad]

Yes. If the "retry" parameter is not set, the transfer simply stops (being interrupted by various networking reasons).
This error that I'm getting is making the "retry" parameter pretty useless, as the file doesn't get transferred completely.

[vlad]

It is really important to get this fixed in a timely manner. I hope you understand.

Here is the last part of the console log:

Code: Select all

[INFO] HTTPUploadTransfer - Upload completed
[INFO] HTTPUploadTransfer - Split started 48/49
[INFO] HTTPUploadTransfer - Split completed 48/49
[ERROR] HTTPUploadTransfer - java.lang.ArrayIndexOutOfBoundsException: 1
[INFO] HTTPUploadTransfer - Upload failed

[support]

Yes, we're going to try to reproduce it by the end of this week and then provide a fix quickly (for next week).

[vlad]

I traced the error to ProgressPanel.java, inside the "transferStarted" callback function.
Seems that this happens only when "progress.info=overallprogressbar".
Disabling the overall progress bar stops the array index Java error, however, the file is not uploaded correctly when a retry is needed. There is one or two chunks missing. So I guess when it retries, the chunk count is lost or something.

[support]

Thanks for the info.

[vlad]

I now think the chunk count problem was caused by the server as it doesn't happen anymore. I suspect this happens when the web server is being restarted while the user is uploading a file. Even though it is something that it doesn't happen that often, it is a problem could have been easily handled.
Unfortunately the upload applet decides that the file was successfully uploaded if the server is returning a HTTP 200. So, pointing it to a plain HTML file will always be "successful".
As the uploads are handled by the server side script (PHP/ASP/JSP, etc.) I think it should be more "fair" for the server side script to decide if the file was uploaded or not, by providing a hint in a custom HTTP header or inside the response body. This way the script will be able to tell the applet to stop if some server limitations or errors were encountered while delivering the file/chunk to its destination. As you know, at this time the applet is pumping the entire file to the server, even if the server side script got some error (because most of the servers are configured to show the error to the user using a 200 OK response, not a 500 Internal Server Error); and the user looks at the progress bar thinking that everything is fine.

Anyway... the progress bar can be improved as well. The progress bar continues to grow even if the chunk fails (and most of the time the chunks fail at the end of their transmission). So instead of going back to the point of retrying the failed chunk, the progress bar spends more time showing 100%. This is confusing for most people as 100% means the files was successfully uploaded.
I guess the additional overall progress bar throws the array index error as it doesn't handle too well the chunk retries either.