Wupdate, 5060, etc.

[Tom H.]

Friedrich,

We are validating some patch downloads using wupdate.exe and have been getting a few anomalous issues.

1) Sometimes we get the 5060 "can't read manifest" error.

2) Sometimes we get the message that it can't find/download the patch installer, which implies it did find the manifest/INI since it displays the correct URL and patch executable name in the error message.

3) Other (most) times it all just works.

The most common denominator seems to be a delay when clicking on the 'next' button on the initial wupdate wizard, which would imply some sort of timeout, etc. Additionally, once it has failed once, it seems to work from that point on (manifest being cached on the network?).

Is there a way to set the wupdate timeout? Or do you have any other thoughts? I've checked all the 5060 threads, but the fact that it works most of the time would indicate that the basic settings are correct. No special MIME types, etc., just an INI and an EXE.

Finally, the manifest and download files are hosted at Amazon, so I don't have any access to server settings, etc.

Thanks,
Tom

[linder]

Hi Tom,

The "timeout" is set to 5000 and is used in the "setsockopt" WinSock function:

http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

On November 21, 2005, we set the timeout to a fix 5000 milliseconds, for blocking receive calls.

So you are looking for an option to increase this timeout, right?

Would it be possible to send me a link to a test manifest file and a test .exe on your Amazon server? Perhaps I can retrieve extended error information from the server.

Friedrich

[Tom H.]

Sure, I'll send you a private link tomorrow (ummm, make that later today -- it's awfully late!)

SB7 logs created with /E just basically show the 5060 as well.

Thanks for your help with this,
Tom

[linder]

Hi Tom,

Perfect. We'll then add debug information to the HTTP component to try to find out what might cause this. BTW, we did not change the HTTP component for years, so perhaps this is "Amazon specific".

Friedrich

[Tom H.]

For anyone curious about this thread, we have determined that the issue is with our download service and the default timeout period in SB 7.5 of 5 seconds.

It seems our service has an average delay of 4.5 to a bit over 5 seconds between a request being issued and the download stream being fed back. Thus our preponderance of 5060 and timeout issues.

Friedrich has provided excellent support in helping to nail this down, and is looking at options to alleviate this kind of issue in the future.

Tom H.

[Tom H.]

Friedrich,

Is there any chance the latest SB 7.6 updates included an increase to the timeout (greater than 5000) in the Download File function?

Thanks,
Tom

[linder]

Tom,

The latest manintenance release was only a bug-fix build without any improvements. In SB 7.7 we have added a new #pragma to define the HTTP Download timeout.

But if you are interested, I can send you a private HTTP component build with an increased timeout. What timeout would you prefer? 10,000 ms, 15,000 ms, ...?

Friedrich

[Tom H.]

Good on the pragma, and absolutely I'd love any interim option you can provide.

Maybe just go with 10,000. That should cover it and reduce (hopefully eliminate) support calls over this issue.

Thanks in advance,
Tom

[linder]

Hi Tom,

I'll compile and send you a component with 10,000ms and another one with 15,000ms to test it. You only have to replace the current library (I'll send further instructions tomorrow morning) and recompile your setup.exe. And if it still does not work as expected, we'll investigate further.

Friedrich

[Tom H.]

Your support continues to be absolutely stellar!

Thanks again,
Tom