Forums

by Stephen >> Sun, 19 Feb 2006 21:43:56 GMT

Hi,
I have had a few issues lately with people uploading files to our Jade webserver.
They can navigate around the web site no problem at all, but when they get to a page that gives them a form to fill in, and files to upload (just a standard web form with <input type="file">), they keep getting the jadehttp.htm "Server Unavailable" message.

What makes this unusual is that the web monitors are definately running, and requests from other users are coming in at the same time. So the server is definately running, and still running after the upload request, its not crashing anything.
If I edit the jadehttp.htm file, and get the user to refresh their window, they get the new message I put in. So it is not a caching issue, the request is definately making it through to the server. They do have to wait a while for the error message to come back too. Its not instant. Would would suggest to me, that the files have been uploaded, then it fails when Jade starts to process the request.
If they get rid of the files they are trying to upload, then it works for them no problem at all.

Just to make thing interesting, at the same sort of time another user may well be uploading files no problem at all. Which would tend to suggest to me that maybe it's a security setting within their browser that is not letting the form get submitted. But if that was the case, why would it be getting the response back from the Jade server? The form submission must be making it to the Jade server to get the Jade error back, but for some reason the web monitors are not picking up the request.

I notice with the Jade monitors, that any files being transferred are first put into the transfer directory, then once they are uploaded the web monitor will then start processing the request. We have been getting a few tmp files left in the transfer directory too, that have not been tidied up by the web monitors. I presume these are the remnants of these failed submissions. The file is uploaded, but then the web monitor doesn't take the request successfully, says the server is unavailable, when it fact it is still running, and the uploaded file is left in the transfer directory.

Anyone that could shed some light on this one would make my day
Many thanks
Stephen

by John >> Mon, 20 Feb 2006 1:30:55 GMT

Some random thoughts for you, I'm not very familiar with Web apps:

How large is the file they are uploading and how slow is their link?

Could it be getting timed out before the file can be uploaded?

Does attaching a smaller file, which will take less time to transmit, complete successfully for them?

by Stephen >> Mon, 20 Feb 2006 3:59:43 GMT

Thanks, but it doesn't appear to be linked to files sizes.
Some customers have uploaded 100Mb files (cough!!) but it worked, while others have failed with a Word document that is 100kB.

by Anonymous >> Tue, 21 Feb 2006 1:30:01 GMT

The jadehttp.dll (which runs under the IIS process) returns the jadettp.htm response to the client, so the request isn't necessarily getting as far as the Jade server. The jadehttp.log may offer clues - there is a trace setting (set in jadehttp.ini) that logs additional information, and should show IIS requests coming in, tcp'd to Jade, then a response, timeout, or other error. The log will also show the client response (jadettp.htm) sent to close the connection.

by Stephen >> Wed, 1 Mar 2006 2:52:18 GMT

I just had another one. There is now a tmp file left in the transfer directory that I can not manually delete. It says it is in use by another process.
The jadehttp.log says the following:
01\03\2006 12:37:18 4016 Unable to read additional user input data from IIS via ReadClient. Error =10054 A existing network connection was forcibly closed by the remote host.

"A existing network connection was forcibly closed by the remote host" - does this mean the user killed their browser window while the file was still uploading?

by John >> Wed, 1 Mar 2006 3:21:52 GMT

The 10054 certainly indicates that the underlying TcpIp connection that was being used has been closed. This could be caused by the user closing their Web Browser or possibly by a firewall or similar closing the TcpIp connection after it has been opened for a certain length of time - some firewalls are configured in this manner, particularly if the company in question wants to prevent their staff downloading large files via their work internet connection.