|
Rank: Newbie Groups: Member
Joined: 8/3/2007 Posts: 3
|
No matter what file size I upload, I never get any progress updates on the upload status. Each file uploads correctly, but the progress bar sits at 0% and the progress text does not display. When the file completes, the bar jumps to 100%. I have tried adding no-cache headers and content expiration to the ajax responses using IIS, but with no luck. Using Fiddler, I was able to intercept the packets returned to the ajax queries. Here's how an upload looks: First AJAX response:
Code: HTML/ASPX
<Data><Command>NewSession</Command><SessionID>fe066e0c-ede8-478c-af3f-a624d3121f30</SessionID></Data>
Second:
Third through next-to-last:
Code: HTML/ASPX
<Data><Command>GetProgress</Command><Total>-1</Total><Received>2</Received><TotalFiles>1</TotalFiles><TransferredFiles>-1</TransferredFiles><CurrentFileName></CurrentFileName></Data>
Last packet:
Code: HTML/ASPX
<Data><Command>GetProgress</Command><Total>10834750</Total><Received>10834750</Received><TotalFiles>1</TotalFiles><TransferredFiles>0</TransferredFiles><CurrentFileName>C:\Documents and Settings\PSI-Adam\Desktop\test.jpg</CurrentFileName><PostedFiles><File><TempFileName>eouploader.fe066e0c-ede8-478c-af3f-a624d3121f30.1.data</TempFileName><ClientFileName>test.jpg</ClientFileName><ContentType>application/octet-stream</ContentType><FileSize>10833632</FileSize></File></PostedFiles></Data>
As you can see, a progress update is only sent in the last packet. This is confirmed on several different machines and browsers, all with caching completely disabled. Further, I've noticed that if I upload large files (700+mb) around the 30% mark the progress indication kicks in. Please advise as to what the problem could be. We were about to purchase your component when we noticed this issue, and if this cannot be quickly resolved we will be forced to scrap our demos with your component and use another component.
|
|
Rank: Administration Groups: Administration
Joined: 5/27/2007 Posts: 24,194
|
Hi Adam, What version are you running? Also, if you try our demo here: http://www.essentialobjects.com/Demo/Default.aspx?path=AJAXUploader\_i0Do you see the same problem? Thanks
|
|
Rank: Administration Groups: Administration
Joined: 5/27/2007 Posts: 24,194
|
Hi Adam, I apologize for not having all the questions at the same time. Here are some more questions: 1. How long does it take for it to reach 30% thus the progress start to kicks in? 2. While it did not kick in, if you check your TempFilePath, do you see these files: a) eouploader.session_id.status. This file supposes to be refreshed every 5 seconds; b) eouploader.session_id.file_number.data. This file is the data file. It should keep growing as data is received; If those files don't appear/change from the very beginning, you can check this registry entry: http://support.microsoft.com/kb/260694This registry entry controls how much data IIS reads before it hands the control over to the extension DLL (in this case, ASP.NET). If this value is too large, you will definitely see uploader sits there a long time before it starts to show progress data. Thanks
|
|
Rank: Newbie Groups: Member
Joined: 8/3/2007 Posts: 3
|
Your demo works fine (although it does not work at all in Firefox, but that is an issue with your layout which I will work around on my own).
It takes the demo several minutes to reach 30% progress and kick in. To get it kick in at all, I have to upload over 700mb, which means that there is quite a delay. It does not always kick in on uploads this large, but it sometimes does.
The TempFilePath does contain the files you mentioned. The .data file does keep regularly growing, even while the packets do not contain updates. The file usually first appears at a size of about 300KB, but the status does not start updating until 50+ mb.
To be safe, I also updated the registry value you mentioned to 16 KB (Microsoft's now-recommended value). This has not helped.
|
|
Rank: Administration Groups: Administration
Joined: 5/27/2007 Posts: 24,194
|
Hi Adam,
Thanks for the update. Would it be possible for you to open up a machine for us to look at it? We use Citrix GoToMeeting to do remote access so you do not need any special configuration on your router. You will be able to see what we do on your machine to be safe.
Since it appears to be occuring rather consistently in your environment, so we feel pretty comfortable that we can get to the bottom of this issue as long as we have access to the environment.
Another option is for you to open up your server to us. We can then upload test version of our DLL and try to find out where it get stuck based on debug information that we added into our test DLL. The advantage of this option is that it does not tie up one of your machine; But it does require some configurations on your server (Creating a temporary ftp account for us, for example).
Please let us know. Thanks for your help.
Thanks
|
|
Rank: Newbie Groups: Member
Joined: 8/3/2007 Posts: 3
|
That is not possible. For security reasons, our machines operate on an internal network which is only accessible within our physical office.
I don't know if this makes a difference, but i did not run your installer on the server where the component is being used. I don't like to clutter the server drives with the documentation and demos this installs. I simply copied your DLLs and the ashx file to the web directory to test. Is there any reason why the installer would have to be run on the target machine?
|
|
Rank: Administration Groups: Administration
Joined: 5/27/2007 Posts: 24,194
|
Hi Adam,
I've sent you a private message. Please take a look of that and let us know. Also, you do not need to run our installer on the server (in fact it's not possible for a lot of shared hosting client to do so). Most of the work the installer does is to setup development environment (integrated with VS.NET) and setup of the sample application.
Thanks
|
|