|
|
Rank: Newbie
Groups: Registered
Joined: 7/5/2011
Posts: 8
|
Hello,
We're experiencing problems with SlickUpload 5.5.11 when uploading to a load balanced environment (although we have successfully used the same config on another load balanced configuration). The load balanced environment uses sticky sessions, so users shouldn't be swapped between servers but we've used the SqlClient for the StatusManager anyway.
The basic symptoms are that when uploading large files (~60MB) the upload appears to abort. Looking at the responses from the server it looks like the control checks the upload status but each time the response from the server is "{state : "Initializing"}". After receiving around 10 replies from the server the page thinks that the upload has aborted. However, it appears that the file upload is still in progress because some time later the uploaded file actually appears on the server (too late to be processed though)
I've got a few questions about this:
1) What does the "Initializing" state mean, and when should this response be updated to provide a progress status?
2) Are there any scenarios that you know of that could cause a file to get stuck at "Initializing", and are there any workarounds?
3) Is the number of retries for checking the upload status configurable?
As I mention, what seems strange is that we have this same configuration on another cluster and it works fine - do you know of any other factors that could influence the file upload and make it behave in this way?
|
|
|
Rank: Administration
Groups: Administrators
Joined: 7/7/2005
Posts: 1,586
Location: Scottsdale, AZ
|
That is very strange. Here are some answers:
1) The "Initializing" state means that the upload request hasn't been received by the server. As soon as the server receives the first bytes of upload, it will switch the state to "ReceivingData".
2) The only things that should cause this are either the upload request actually not hitting the server (which it sounds like this isn't the case), or the upload request and the progress requests using different session state stores.
3) Currently, no. It retries 10 times, one second apart, and then times out. If we need to, we can release a new build for you that does have this timeout configurable, but my feeling is that this isn't an issue of timing out too early.
Some thoughts on things to try:
- I'm assuming you've tested and the requests do go through?
- Have you double checked the sticky sessions configuration and the SqlClient status manager configuration to make sure all servers in the cluster are configured properly?
- Have you tried using the default status manager rather than SqlClient to see if that works?
- Do you see the status information for an upload being written to the status table as the upload progresses? The record should be inserted initially, then updated every second or so.
|
|
|
Rank: Newbie
Groups: Registered
Joined: 7/5/2011
Posts: 8
|
Thanks for your reply.
I've double-checked the sticky session configuration and everything seems to be working okay (the rest of our site works, which it wouldn't if sticky sessions were playing up). The SqlClient configuration also looks correct:
<statusManager manager="SqlClient" connectionStringName="{deleted}" table="SlickUpload" keyField="[Key]" statusField="[Status]" lastUpdatedField="[LastUpdated]" />
I've also tried using the default status manager and I see the same effect.
Interestingly the problem only occurs with large files - small files upload okay. I think it's a problem with the time taken to upload rather than file size though because on a slow connection I can only upload ~5MB but at work I can upload ~30-50MB before I start seeing problems.
Looking at the IIS logs it appears that the POST containing the actual file doesn't happen until after my page has given up:
2011-10-10 07:50:33 GET /version10/Admin/DocumentationItemCreate.aspx - 200 0 0 40218 755 1890
2011-10-10 07:50:33 GET /version10/SlickUpload.axd handlerType=blank&uploadId=f4042140-a7f1-45af-aa58-039cfcc280eb 200 0 0 311 777 0
2011-10-10 07:51:22 GET /version10/SlickUpload.axd uploadId=f4042140-a7f1-45af-aa58-039cfcc280eb 200 0 0 316 725 250
2011-10-10 07:51:23 GET /version10/SlickUpload.axd uploadId=f4042140-a7f1-45af-aa58-039cfcc280eb 200 0 0 316 725 0
2011-10-10 07:51:24 GET /version10/SlickUpload.axd uploadId=f4042140-a7f1-45af-aa58-039cfcc280eb 200 0 0 316 725 0
2011-10-10 07:51:25 GET /version10/SlickUpload.axd uploadId=f4042140-a7f1-45af-aa58-039cfcc280eb 200 0 0 316 725 15
2011-10-10 07:51:26 GET /version10/SlickUpload.axd uploadId=f4042140-a7f1-45af-aa58-039cfcc280eb 200 0 0 316 725 0
2011-10-10 07:51:27 GET /version10/SlickUpload.axd uploadId=f4042140-a7f1-45af-aa58-039cfcc280eb 200 0 0 316 725 0
2011-10-10 07:51:28 GET /version10/SlickUpload.axd uploadId=f4042140-a7f1-45af-aa58-039cfcc280eb 200 0 0 316 725 0
2011-10-10 07:51:29 GET /version10/SlickUpload.axd uploadId=f4042140-a7f1-45af-aa58-039cfcc280eb 200 0 0 316 725 15
2011-10-10 07:51:30 GET /version10/SlickUpload.axd uploadId=f4042140-a7f1-45af-aa58-039cfcc280eb 200 0 0 316 725 0
2011-10-10 07:51:31 GET /version10/SlickUpload.axd uploadId=f4042140-a7f1-45af-aa58-039cfcc280eb 200 0 0 316 725 0
2011-10-10 07:51:32 GET /version10/SlickUpload.axd uploadId=f4042140-a7f1-45af-aa58-039cfcc280eb 200 0 0 316 725 0
2011-10-10 07:51:32 POST /version10/Admin/DocumentationItemCreate.aspx - 200 0 0 41122 6255 828
2011-10-10 07:51:33 POST /version10/SlickUpload.axd handlerType=upload&uploadId=f4042140-a7f1-45af-aa58-039cfcc280eb 400 0 64 0 916 12609
2011-10-10 07:51:33 GET /version10/SlickUpload.axd handlerType=blank&uploadId=de8ad932-1f70-458d-a16a-f5027c1aeda1 200 0 0 311 777 0
A similar thing is seen in the status table: an entry is added when the page is first loaded, but there are no updates when the form is posted. The entry is finally updated when the page has reloaded, without the file having been uploaded.
I've tested this in Firefox (5 and 7), IE (8 and 9) and Chrome (15?) and see similar results.
|
|
|
Rank: Administration
Groups: Administrators
Joined: 7/7/2005
Posts: 1,586
Location: Scottsdale, AZ
|
A couple more questions:
- Is there any difference in HttpModule or ISAPI module configuration between the two clusters?
- Do you have session state enabled?
|
|
|
Rank: Newbie
Groups: Registered
Joined: 7/5/2011
Posts: 8
|
On both the cluster that works and the one that doesn't there is only the ASP.NET ISAPI filter installed. One difference though is that the cluster that works has .NET framework 4.0 whereas the one that doesn't has .NET framework 2.0 only at the moment. Could this make a difference?
We do have session state enabled, this is configured to use a database. Other parts of our application make use of session state and this appears to be working as expected.
|
|
|
Rank: Administration
Groups: Administrators
Joined: 7/7/2005
Posts: 1,586
Location: Scottsdale, AZ
|
I doubt that the .NET version would make a difference.
Do you see the progress bar moving for the small files that work, or does it just snap to complete?
Can you try setting the EnableSessionState="false" in the <%@ Page %> directive of DocumentationItemCreate.aspx? If you have session state enabled, ASP.NET only allows one request per session to execute at a time, and blocks all subsequent requests until that request is complete. I doubt this is the issue here -- the SlickUpload client code should execute the upload POST before starting any other requests. Still, it'd be worth checking.
|
|
|
Rank: Newbie
Groups: Registered
Joined: 7/5/2011
Posts: 8
|
For the uploads that do work the progress bar doesn't seem to update until the very end of the upload, and then it quickly goes to 100%.
I'm afraid I can't turn off the SessionState in our application, it won't work because other components have dependencies on it. This sounds like an interesting point though - do you think that the ASP.NET session state could be causing problems? Looking at my IIS logs would suggest that the POST is being made after the progress requests, could this be related?
|
|
|
Rank: Administration
Groups: Administrators
Joined: 7/7/2005
Posts: 1,586
Location: Scottsdale, AZ
|
Can you turn off session state just for that page to see if that is the issue? I'm just trying to track down what is actually causing this.
If not, I'll give you a debug build with non-obfuscated javascript so we can step through and see what's going on. Would it be possible to give me a url and login so I can try to reproduce the issue from here? You can email me at chrish@krystalware.com.
|
|
|
Rank: Newbie
Groups: Registered
Joined: 7/5/2011
Posts: 8
|
I'm afraid I can't get this page to work with session state disabled as it contains components that depend on the session. I will look into creating a test page with just the upload component on and send you the details.
|
|
|
Rank: Newbie
Groups: Registered
Joined: 7/5/2011
Posts: 8
|
I’ve found the answer. After pestering our hosting company to find out more information about the problem it turns out that there were “several custom options setup for the UTM”. I’ve got no idea what this means but the upshot is that once these were disabled uploading files worked!
Thanks for all your help investigating this: the information and evidence you helped provide was crucial in finding the answer from the hosting company.
|
|
|
|
Guest |