2

Ran into a very bizarre issue and am looking for direction.

Context: uploading large files (up to 100MB) in WordPress. As part of the process there is also a long task running on the server-side (pushing file to DropBox via their API using chunking), so the response is inevitably delayed for larger files. This part can be simulated easily by executing PHP's sleep() function.

Issue: Fineuploader gets to 100%, shows the waitingForResponse message for about 15 seconds (server is still not done processing at this point), then proceeds to restart the upload from scratch. After the second try it claims to have received nothing from the server and lists the upload as failed. Console debug messages:

[FineUploader] xhr - server response received for 0
XMLHttpRequest { readyState=4, timeout=0, withCredentials=false, more...}
[FineUploader] responseText =

Server logs show two requests and server echoes the success JSON twice; in the end there are two files on the server.

Question: What can I do to resolve this? Can I return something to FineUploader regularly to ensure there is no timeout?

montrealist
  • 5,593
  • 12
  • 46
  • 68

1 Answers1

2

Fine Uploader has no timeout mechanism in place. If you are seeing a timeout, either the browser itself is forcing a timeout, or there is some appliance between the browser and your server that is timing out.

I have run into this issue in the past when utilizing AWS (Amazon Web Services). Similar to your situation, I had to perform some processing server-side after the entire file had been received before returning the response. During this processing, of course, no TCP traffic was occurring. It turned out that the ELB (Elastic Load Balancer) had a TCP idle timeout of 1 minute. Processing for large files exceeded this value, causing the ELB to terminate the request.

You can only return a response to Fine Uploader when you are DONE with the request/upload. If you truly want to wait to return a "success" response to Fine Uploader until your server-side processing is complete, you will need to figure out what is terminating your request. Your options are likely to either increase the timeout period on the device that is terminating your request, or simply delegate the processing to a separate thread server-side and return the success response as soon as all of the file bytes have been received and are in order.

Ray Nicholus
  • 19,538
  • 14
  • 59
  • 82
  • Yes. In the case of AWS, you can request an increase in the the ELB's TCP idle timeout. This is not something that you can modify yourself, so you must ask an AWS admin to do this for you. I wasn't directly involved in dealing with this request (someone else on my team was assigned the task), but I believe we did request an increase, and it was granted. Before requesting an increase, we discussed simply delegating the processing to a separate thread and returning the response ASAP. If memory serves me correctly, it was determined that the processing should occur inline. – Ray Nicholus May 19 '13 at 03:34
  • I see. Any idea at all as to why the upload is being restarted? Is this intended functionality? – montrealist May 19 '13 at 04:02
  • Could be either fine uploader's auto retry feature (if enabled). If it's fine uploader, you will see a "retrying" status message next to the file briefly. Are you seeing anything like that? – Ray Nicholus May 19 '13 at 13:44
  • No, not really. It hangs at 99% and then restarts. It's most likely the server closing the connection. I'm just puzzled as to why it doesn't fail right away (or after a longer period), but actually _restarts_ the upload and completes it. – montrealist May 20 '13 at 21:27
  • Do you have the retry feature enabled? Is it apparent from the UI that a retry is being ordered by Fine Uploader? What sort of log messages are you seeing (with debug: true set in your options)? – Ray Nicholus May 20 '13 at 21:46
  • Finally it turned out to be an Apache timeout setting (which the host refused to modify). Lesson to take away is to always pick your host wisely. Thank you once again. – montrealist May 24 '13 at 16:13
  • @dalbaeb Glad you got this resolved and I was able to help in some way. Happy uploading! – Ray Nicholus May 24 '13 at 16:14