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/library/windows/desktop/ms740476(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

[linder]

Hi Tom,

:)

New HTTP test libraries sent. Please keep me posted.

Thanks,
Friedrich

[Tom H.]

Okay, recompiled wupdate.exe with a new http component (10 sec) and...

Works every time!

We ran side by side tests, 30 iterations, on an overloaded network, original (5 sec) vs new one. The original failed 99% of the time, new one never failed.

I thank you, and our Tech Support people thank you!

Tom

[linder]

Hi Tom,

PERFECT!!! Thank you for the very good news :)

BTW, I think we'll increase the default download timeout from 5,000 ms to 10,000 ms in the upcoming SB 7.7. If users prefer the old 5 sec timeout, they can use the new #pragma to reset it.

Thanks again!

Friedrich

[Tom H.]

Friedrich,

Another one from the vaults...:)

I had one report on this year but it was an outlier (person was using terminal services to log into a remote VM over slow lines, etc.)

In any case, it just got me wondering what the default timeout was actually changed to so I can tell our Tech Support staff.

Thanks again for such a great product,
Tom H.

[linder]

Tom,

Thank you! :)

In April 04, 2012, we changed the default timeout for blocking receive calls in HTTP download actions from 5,000 milliseconds to 10,000 milliseconds.

Friedrich