InstallAware modifies ReceiveTimeout (and other) setting

[CandiceJones]

That wouldn't actually be a very robust solution, because then the target system would be in two different states - one at install time, the other when no setup is running. But maybe people would prefer that?

[GlenG]

I'd have to defer to InstallAware and others more knowledgable on the consequences of that differing state.

Personally, I can't imagine a scenario where switching that setting between the IA desired value during install and back to the previous system value afterwards could be a problem... but I've not created the number of installers that others have.

[Bikedude]

I agree that an hour is too long. But I've found 10 seconds too short as it's caused other (slow) websites to stop working ...

Personally, I think the timeout should be somewhere near 2-5 seconds. If a webpage has not replied within then, it usually ain't worth the wait anyway.

That said... Hehe... Have any of you guys recently tried to generate a license on InstallAware's website?

Let me say it like this...: A 30 second timeout would not cut it!

--
Rune

[Bikedude]

your installer will freeze for an hour before the IE download engine reports at time-out.

Execute the calls to the IE download engine in separate threads. Kill these threads when your timeout is reached, and either abort the installation or retry at that point.

Or use a socket library capable of using IE's proxy settings.

[MichaelNesmith]

Killing the threads puts the installer in an inconsistent state, and produces unpredictable results when further download attempts come from the same setup instance. In a thread kill scenario, canceling out of setup altogether is the only workable solution, which defeats InstallAware's redundant download URL capabilities, as well as automatic re-tries.

[Bikedude]

Killing the threads puts the installer in an inconsistent state

...why?

Make the thread operate on a known dataset. Have a watchdog thread peek in every now and then and see if the timeout has been exceeded, then simply dump all the data that thread has been working on after killing it.

But OK, another idea, the thread fires off the request (through IE as before). Once that request returns, it will check if the installer decided things were taking too long (and presumably spun another thread).

Given that Windows did not get cancellable IO until Vista, this is somewhat hairy... BUT! Setting the ReceiveTimeout system setting is a much worse solution.

(As I said, your setting is probably why I had to get a colleague to download the license key thing from installaware.com)

[MichaelNesmith]

You may want to contact Microsoft directly and ask them why. Their APIs fail to behave properly after they have been killed in a thread once before.

Your failure to download licenses has nothing to do with this, obviously we download our own licenses also obviously and we have an installed copy of InstallAware.

Before jumping the gun to draw what are at best half-baked conclusions, you should take a moment and think that maybe we know better.

[[email protected]]

Your failure to download licenses has nothing to do with this

Honestly this is the frustrating thing. I am not sure that you understand that the registry setting that you changed causes lots of things like this to fail. It has EVERYTHING to do with this. The license download is an internet request. Since it can take more than 10 seconds, it can fail on machines that have run an IA install program. Interestingly, I had to post this message twice because the first one timed out.

Have you looked at using asyncronous http requests? They are a little more difficult to program, but it is the only way to control timeout values consistantly.

[MichaelNesmith]

We are working on improving the license download system. We do apologize about that - sorry

So what is the forum consensus, to get back on track - is everybody happy with a compiler variable to specify time-out duration, where 0 is "do not touch" and any other value is "set time-out in seconds"?

[[email protected]]

So what is the forum consensus, to get back on track - is everybody happy with a compiler variable to specify time-out duration, where 0 is "do not touch" and any other value is "set time-out in seconds"?

Wouldn't using async http calls make this issue go away? And prevent the need to modify registry values?

[Bikedude]

Before jumping the gun to draw what are at best half-baked conclusions, you should take a moment and think that maybe we know better.

Before jumping the gun on poo-pooing my excellent and quite frankly helpful suggestions, you should take a moment and consider the fact that some of your users are quite knowledgable in this field.

I have been using the Internet since 1991 or so. I've been a developer since about then too. I have been a member of the Indy development team, back when Kudzu first founded that group. I've been developing real-time stock information systems that streams a hefty amount of data across Internet from various sources. As part of that team, I had numerous encounters with users who experienced various proxy issues. I know the challenges posed by sniffing IE's proxy setup, but I also know it isn't impossible.

Oh, and I recognise some of the other names in this thread too from various fora.

I also know that your current approach (vis-a-vis the problem at hand) needs a rethink.

I will grant you this much though: I don't recall having used IE as a download engine. That particular idea never struck a chord with me. (not 100% true -- I've used it sometimes for non-critical stuff, but I'm very eager to repress those memories)

[[email protected]]

Before jumping the gun to draw what are at best half-baked conclusions, you should take a moment and think that maybe we know better.

Before jumping the gun on poo-pooing my excellent and quite frankly helpful suggestions, you should take a moment and consider the fact that some of your users are quite knowledgable in this field.

I have been using the Internet since 1991 or so. I've been a developer since about then too. I have been a member of the Indy development team, back when Kudzu first founded that group. I've been developing real-time stock information systems that streams a hefty amount of data across Internet from various sources. As part of that team, I had numerous encounters with users who experienced various proxy issues. I know the challenges posed by sniffing IE's proxy setup, but I also know it isn't impossible.

Oh, and I recognise some of the other names in this thread too from various fora.

I also know that your current approach (vis-a-vis the problem at hand) needs a rethink.

I will grant you this much though: I don't recall having used IE as a download engine. That particular idea never struck a chord with me. (not 100% true -- I've used it sometimes for non-critical stuff, but I'm very eager to repress those memories)

Well said Bikedude. Obviously we all like IA which is why we are participating in this discussion about how to improve a problem. But it is a little concerning that we can be attacked like that for our suggesstions. The reaility is that there is a better way to do this (somehow other apps are able to do this without changing a system registry that causes so many problems, probably using async http requests or threads).

[MichaelNesmith]

Nobody is attacking you for your suggestions. However, you are making assumptions which are untrue about what InstallAware has tried and hasn't - killing threads, for instance.

To make it clear, we're not looking for technical implementation advice. We are not looking for any free education on how to write code. We are looking for the best strategy given the constraints outlined.

So if you truly want to help - don't try to explain or teach us how great your strategy is, but accept the constraints provided here-in and tell us what you think would be the optimal route given your own and end-user scenarios.

[Bikedude]

So if you truly want to help - don't try to explain or teach us how great your strategy is, but accept the constraints provided here-in and tell us what you think would be the optimal route given your own and end-user scenarios.

I can tell you this much: I cannot deploy an installer that messes with the IE configuration of the end-user. Nor can I, as an end-user, accept an installer that fubars my browser's settings. (thank you for making it harder for me to access IA's own website!)

You guys have three options:

• Proceed as before, but don't mess with the user's settings
• Try again to use the IE engine differently
• Roll your own communication code (bonus: use IE's proxy settings)

This is hardly rocket science.

Michael, you guys have been caught with your pants down. I understand your first instinct is to get defensive, but for your own sake: Avoid the temptation.

[MichaelNesmith]

I have written here already that this has nothing to do with the license generator. InstallAware is installed on all our hardware with default settings and none of us are experiencing this issue.

We take feedback which is intentionally manipulated to be destructive very seriously. Since you are intentionally ignoring my posts, you are now publicly banned from the InstallAware forums.

We are all working very hard here and people who intentionally distort/abuse facts to justify their own agenda/perspective will not be tolerated at any official InstallAware support resource.

I'm not locking this thread for the moment, in hopes that some people are actually smart enough to provide us with constructive feedback (instead of trying to educate us on what we already know to not work).