This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- FlexNet Connect
- :
- FlexNet Connect Forum
- :
- Re: UpdateAgent.EnumUpdates() locks my app for 5-10 seconds
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 08, 2005
12:07 PM
UpdateAgent.EnumUpdates() locks my app for 5-10 seconds
Well, I was very excitied with the possibilities of UpdateAgent.EnumUpdates() giving me tons of updatable information that I could manually process and download myself. Unfortunately, I've hit a major snag that's holding me up.
My Visual Basic app hangs for 15 seconds while UpdateAgent.EnumUpdates() is being run. It seems the more update conditions that could apply to it, the slower it goes. When there was only 1 update, it took about 2-3 seconds. At the moment, there are 4 possible updates can apply to this app. And because of the nature of Visual Basic, it seems any call to an early bound dependency object causes the main thread to lock up until it's finished.
So, it seems I have no way of cleanly and silently checking for updates in the background without a huge and long hang in my app.
My question is this...is this normal? Our customers are still running on the Update Service v3.0 files. Has this hanging problem been fixed in later releases? Or do I have to accept that if I try to send out more than a couple updates to an app, that I have to accept the baggage of the app hanging for a long time?
My Visual Basic app hangs for 15 seconds while UpdateAgent.EnumUpdates() is being run. It seems the more update conditions that could apply to it, the slower it goes. When there was only 1 update, it took about 2-3 seconds. At the moment, there are 4 possible updates can apply to this app. And because of the nature of Visual Basic, it seems any call to an early bound dependency object causes the main thread to lock up until it's finished.
So, it seems I have no way of cleanly and silently checking for updates in the background without a huge and long hang in my app.
My question is this...is this normal? Our customers are still running on the Update Service v3.0 files. Has this hanging problem been fixed in later releases? Or do I have to accept that if I try to send out more than a couple updates to an app, that I have to accept the baggage of the app hanging for a long time?
(21) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 09, 2005
02:22 PM
Hi Brad,
I am experiencing the same situation. I currently have 7 updates registered. When I start my PowerBuilder application it takes anywhere between 6 and 20 seconds to perform the enumupdates().
On high speed Internet connection with WinXP and a decent machine, it takes 6 seconds when all updates have already been applied, and 9 seconds when none of the 7 updates have been applied.
On a dial-up Internet connection with Win98, it takes approximatly 20 seconds...! This is obviously not acceptable.
Since I have provided my users with a way to deactivate the "Automatic Checking for upates" functionality (just in case they dislike the experience), I am afraid they will start using it, and that my app will not get updated promptly...
I am therefore looking for another solution. One thing I am going to look into within the next month, is to create a silent process that's going to be launch at the machine start-up (like the IS agent provided with the kit) and silently look for updates on daily basis, for example... Once an update would be found, it would create a registry key with enough information so that my app, during its launch, could let the user know that updates are available.
I'll let you know how it goes...In the mean time, if you can find a better way, do not hesitate to publish it here!
thanks,
Patrick
I am experiencing the same situation. I currently have 7 updates registered. When I start my PowerBuilder application it takes anywhere between 6 and 20 seconds to perform the enumupdates().
On high speed Internet connection with WinXP and a decent machine, it takes 6 seconds when all updates have already been applied, and 9 seconds when none of the 7 updates have been applied.
On a dial-up Internet connection with Win98, it takes approximatly 20 seconds...! This is obviously not acceptable.
Since I have provided my users with a way to deactivate the "Automatic Checking for upates" functionality (just in case they dislike the experience), I am afraid they will start using it, and that my app will not get updated promptly...
I am therefore looking for another solution. One thing I am going to look into within the next month, is to create a silent process that's going to be launch at the machine start-up (like the IS agent provided with the kit) and silently look for updates on daily basis, for example... Once an update would be found, it would create a registry key with enough information so that my app, during its launch, could let the user know that updates are available.
I'll let you know how it goes...In the mean time, if you can find a better way, do not hesitate to publish it here!
thanks,
Patrick
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 10, 2005
12:58 PM
I had two alternate solutions.
1) Have a separate .exe that is loaded as the main appliation .exe is loaded. This separate .exe runs behind the scenes, does the update check, and then sends a Windows message to the main .exe telling it new updates were found. Since the separate .exe is not locked in with the application in any way, it won't make it freeze or hang. The problem here is....I have no way of cleanly sending the object that contains the enum'd update information from the separate .exe back to the main .exe. So, the main .exe only knows new updates are available, it simply doesn't know what they are. Wait a minute, I just realized something. I don't need to pass that object from one .exe to another .exe. I just need the object's information for each update, such as URL, size of file, command line to run, etc. I could have the separate .exe load the enum'd object's information to a file, and then the main .exe will load that information from a file, and it has the update info it needs.
I like your solution better, of just setting a registry key that is polled. Windows message communication between processes sometimes is ugly. Huh, this solution just might actually work.
The big drawback I have with this approach, is that due to the nature of our application, the user could potentially be done with the appliation in less than a minute. I really really don't want an update notice to spring up 30 seconds in, when the user is almost done with the using the app. Also, if I have critical updates, I want them processed immediately, not several seconds later when the user when the user is already using the older unpatched version of the app. I suppose I could make an option that says the application will process updates when it's closing. But still, that doesn't solve the issue where I'll need users to update the application immediately before they try to use the program. I suppose I could make some background app that checks for updates and that is loaded on Windows startup, but I really hate the concept of those. They feel more like spyware than legimate apps, in how they suck up extra memory.
2) Dump InstallShield completely. I'm finding InstallShield is costing us more time and money to work around their products' bugs than it would be if we just wrote our own in house updating solution.
Here's the detailed reason why InstallShield's bugs are costing us time and money. (Now, to be fair, the worst bugs have come from InstallShield Express X.) I've spent the last month pulling my hair out and taking calls from angry customers because InstallShield Express's MSI patch creater didn't register .dll files for us as it should have done. To make it worse, it won't let me create any new updates, because there is some annoying 15 updates limit that no employee told me about. I got pretty mad when Express X sent out a bad update, and was really mad when I couldn't use Express X to send out another update to fix the problem it created. So, we've spent countless hours on the phone having customers manually register their files. We've also given out refunds to customers to make up for their time and lost productivity. On top of this, the time spent fixing users problems one by one also took away far too much programming time.
As a workaround solution, I wrote our own auto updater that downloads files one by one, and processes them itself. So all I needed from InstallShield is Update Service to publish updates online and their API to see if new updates are available. Unfortunately, the API is flawed, and takes an obscene amount of time to do a few simple checks.
Now, since I've already written the code to download and process files one by one, all that's left for us to write is an online publishing system and some code to see what potential updates should be processed. We've speced out a fairly quick and simple approach to this, and we think it would only take us another 1-2 weeks to write this last remaining portion. Once it's written and it works, there would be no need any longer for Update Service.
I feel bad saying that I'm ready to dump Update Service, as some of the employees here on the board have been very courteous and helpful to me. But the hard facts make the decision...Update Service simply does not do what we need it to do, and overall, Express X's MSI patch and Update Services publishing and API solutions are costing us more money than if we wrote our own in house solution.
At the moment, we're not sure what whether to use solution #1 or solution #2.
A third solution which we are currently using is to package all the updates in one self extracting .exe file. The self extracting .exe runs another file when it extracts, and that app quickly moves files to the appropriate destination and registers any that need to be registered. This was surprisingly only took a couple of days to write. It also requires that we only need Update Service to tell us one update is available for an app. Now, with this solution, we need Update Service to handle very very few tasks. And that is to publish 1 update per app, and providing the version and url this update should apply to. This could easily be rewritten ourselves as well.
1) Have a separate .exe that is loaded as the main appliation .exe is loaded. This separate .exe runs behind the scenes, does the update check, and then sends a Windows message to the main .exe telling it new updates were found. Since the separate .exe is not locked in with the application in any way, it won't make it freeze or hang. The problem here is....I have no way of cleanly sending the object that contains the enum'd update information from the separate .exe back to the main .exe. So, the main .exe only knows new updates are available, it simply doesn't know what they are. Wait a minute, I just realized something. I don't need to pass that object from one .exe to another .exe. I just need the object's information for each update, such as URL, size of file, command line to run, etc. I could have the separate .exe load the enum'd object's information to a file, and then the main .exe will load that information from a file, and it has the update info it needs.
I like your solution better, of just setting a registry key that is polled. Windows message communication between processes sometimes is ugly. Huh, this solution just might actually work.
The big drawback I have with this approach, is that due to the nature of our application, the user could potentially be done with the appliation in less than a minute. I really really don't want an update notice to spring up 30 seconds in, when the user is almost done with the using the app. Also, if I have critical updates, I want them processed immediately, not several seconds later when the user when the user is already using the older unpatched version of the app. I suppose I could make an option that says the application will process updates when it's closing. But still, that doesn't solve the issue where I'll need users to update the application immediately before they try to use the program. I suppose I could make some background app that checks for updates and that is loaded on Windows startup, but I really hate the concept of those. They feel more like spyware than legimate apps, in how they suck up extra memory.
2) Dump InstallShield completely. I'm finding InstallShield is costing us more time and money to work around their products' bugs than it would be if we just wrote our own in house updating solution.
Here's the detailed reason why InstallShield's bugs are costing us time and money. (Now, to be fair, the worst bugs have come from InstallShield Express X.) I've spent the last month pulling my hair out and taking calls from angry customers because InstallShield Express's MSI patch creater didn't register .dll files for us as it should have done. To make it worse, it won't let me create any new updates, because there is some annoying 15 updates limit that no employee told me about. I got pretty mad when Express X sent out a bad update, and was really mad when I couldn't use Express X to send out another update to fix the problem it created. So, we've spent countless hours on the phone having customers manually register their files. We've also given out refunds to customers to make up for their time and lost productivity. On top of this, the time spent fixing users problems one by one also took away far too much programming time.
As a workaround solution, I wrote our own auto updater that downloads files one by one, and processes them itself. So all I needed from InstallShield is Update Service to publish updates online and their API to see if new updates are available. Unfortunately, the API is flawed, and takes an obscene amount of time to do a few simple checks.
Now, since I've already written the code to download and process files one by one, all that's left for us to write is an online publishing system and some code to see what potential updates should be processed. We've speced out a fairly quick and simple approach to this, and we think it would only take us another 1-2 weeks to write this last remaining portion. Once it's written and it works, there would be no need any longer for Update Service.
I feel bad saying that I'm ready to dump Update Service, as some of the employees here on the board have been very courteous and helpful to me. But the hard facts make the decision...Update Service simply does not do what we need it to do, and overall, Express X's MSI patch and Update Services publishing and API solutions are costing us more money than if we wrote our own in house solution.
At the moment, we're not sure what whether to use solution #1 or solution #2.
A third solution which we are currently using is to package all the updates in one self extracting .exe file. The self extracting .exe runs another file when it extracts, and that app quickly moves files to the appropriate destination and registers any that need to be registered. This was surprisingly only took a couple of days to write. It also requires that we only need Update Service to tell us one update is available for an app. Now, with this solution, we need Update Service to handle very very few tasks. And that is to publish 1 update per app, and providing the version and url this update should apply to. This could easily be rewritten ourselves as well.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 10, 2005
02:38 PM
Hi Brad,
I won't deny that it's a bit depressing (in the sense that I'd rather we made your life easier) to hear about your trials in utilising the Update Service, but that just means we have more to do to to ensure we cover your needs and meet your expectations as our customer. I have PM'd you about whether you'd be interested in discussing your issues more in-depth.
Also, if you do agree, it would help us tremendously if we can separate the issues Express / Update Service / "Starter" account. I realize that our "Starter" editions leave something to be desired, and there has been some talk about what can be done to make it more useful.
Just reply to my PM if you are interested.
Regards,
Kelly
I can speak for many of us in the team in that we want to know where you feel we've failed you in making things easier/better. I hope we have the chance to prove it, but we'll need your feedback, both positive & negative.
I won't deny that it's a bit depressing (in the sense that I'd rather we made your life easier) to hear about your trials in utilising the Update Service, but that just means we have more to do to to ensure we cover your needs and meet your expectations as our customer. I have PM'd you about whether you'd be interested in discussing your issues more in-depth.
Also, if you do agree, it would help us tremendously if we can separate the issues Express / Update Service / "Starter" account. I realize that our "Starter" editions leave something to be desired, and there has been some talk about what can be done to make it more useful.
Just reply to my PM if you are interested.
Regards,
Kelly
I can speak for many of us in the team in that we want to know where you feel we've failed you in making things easier/better. I hope we have the chance to prove it, but we'll need your feedback, both positive & negative.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 10, 2005
02:55 PM
KellyF, heh, I completely understand. I'm a developer too with a much desired product that seems to have unlimited scope to it. I seem to relate to many of the problems. As long as I know the Update Service team does take pride in their work and wants it to succeed, then I know that problems like mine are not just brushed aside.
I've sent you a PM in reply.
I've sent you a PM in reply.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 10, 2005
03:09 PM
I briefly read your posting here is my feedback on it.
a) I am looking at implementing EnumUpdate2 or some thing which shall be multithreaded so your application does not seem to hang. No promises and No ETA as of now. I shall send you information on it when I know more about it.
b) You quoted "because there is some annoying 15 updates limit...". I am not fimilar with this limit, Can you share where did you get this information.
Thanks
-Sunny
a) I am looking at implementing EnumUpdate2 or some thing which shall be multithreaded so your application does not seem to hang. No promises and No ETA as of now. I shall send you information on it when I know more about it.
b) You quoted "because there is some annoying 15 updates limit...". I am not fimilar with this limit, Can you share where did you get this information.
Thanks
-Sunny
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 10, 2005
03:47 PM
Sure. It's not an Update Service bug. But it is an InstallShield installer/patching problem that affects a good number of products.
http://support.installshield.com/kb/view.asp?articleid=Q111711
Apparently, this bug is not known by everyone, since I talked to about 4 InstallShield people over the phone before purchasing it and specifically asked about doing as many as 50 updates. They all said it should work.
Regarding enumupdates...would making it multi-threaded help out with the speed? Personally, I can't see why 4 possible updates would take a total of 15 seconds to process. Is the time involved with downloading a list of the updates, or with checking all the various variables on the client system?
http://support.installshield.com/kb/view.asp?articleid=Q111711
Apparently, this bug is not known by everyone, since I talked to about 4 InstallShield people over the phone before purchasing it and specifically asked about doing as many as 50 updates. They all said it should work.
Regarding enumupdates...would making it multi-threaded help out with the speed? Personally, I can't see why 4 possible updates would take a total of 15 seconds to process. Is the time involved with downloading a list of the updates, or with checking all the various variables on the client system?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 10, 2005
06:09 PM
Gotta love MSI.... thanks for the link, I was under the impression that you were discussing some Update Service limitation.
I have to agree with you in that I don't know where such an extended time would come from. I'd probably want to check it out to track the time spent in particular areas. If you wouldn't mind me digging into it further (probably around mid-December), please PM me. I would probably need to use an evaluation if it's US enabled.
Regards,
KellyF
Brad Peterson wrote:
Regarding enumupdates...would making it multi-threaded help out with the speed? Personally, I can't see why 4 possible updates would take a total of 15 seconds to process. Is the time involved with downloading a list of the updates, or with checking all the various variables on the client system?
I have to agree with you in that I don't know where such an extended time would come from. I'd probably want to check it out to track the time spent in particular areas. If you wouldn't mind me digging into it further (probably around mid-December), please PM me. I would probably need to use an evaluation if it's US enabled.
Regards,
KellyF
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 10, 2005
10:44 PM
KellyF, I went ahead and did a little investigation to help things out.
And something very strange happened. I set the complicated conditions exactly as I had them before...ran a few tests...and this time it only took 1-3 seconds to find that new update were available.
Very strange. But it's good news! About the best I can have right now :). It's good news because this shows the holdup is probably not caused by the API on the client's machine. Since my Update Service 3.0 API ran enumupdates() in 1-3 seconds, I'm guessing that shows it can always run that fast.
I'll keep testing more in the future. Maybe the 15 second hang occurs from the servers in heavy load portions during the day. If so, Sunny's multithreaded enumupdates idea is spot on. I know when I was seeing the problem, I saw it multiple times that day during a span of several hours. I'll keep investigating it more and will provide feedback through this thread, unless you want me to provide feedback in a more private channel.
Also, sorry for confusing both of you about the 15 update problem I had. I should have linked to that doc beforehand. It would help keep things less complicated. 🙂
And something very strange happened. I set the complicated conditions exactly as I had them before...ran a few tests...and this time it only took 1-3 seconds to find that new update were available.
Very strange. But it's good news! About the best I can have right now :). It's good news because this shows the holdup is probably not caused by the API on the client's machine. Since my Update Service 3.0 API ran enumupdates() in 1-3 seconds, I'm guessing that shows it can always run that fast.
I'll keep testing more in the future. Maybe the 15 second hang occurs from the servers in heavy load portions during the day. If so, Sunny's multithreaded enumupdates idea is spot on. I know when I was seeing the problem, I saw it multiple times that day during a span of several hours. I'll keep investigating it more and will provide feedback through this thread, unless you want me to provide feedback in a more private channel.
Also, sorry for confusing both of you about the 15 update problem I had. I should have linked to that doc beforehand. It would help keep things less complicated. 🙂
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 30, 2005
03:29 AM
I just wanted you to know, that I'm always having this issue that my application is locked during the EnumUpdates() call. When there are more updates online, the time to finish the EnumUpdates() call takes longer. (I'm using the Update Service 4.6 Agent.)
I wrote a separate executable that's being called from my main application, which does all the update checking and installation processing. At the moment, the time to finish the call is acceptable, but I expect some troubles when we publish more updates on the US Publisher Web Site.
Regards,
Marcel
I wrote a separate executable that's being called from my main application, which does all the update checking and installation processing. At the moment, the time to finish the call is acceptable, but I expect some troubles when we publish more updates on the US Publisher Web Site.
Regards,
Marcel
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 30, 2005
06:59 AM
Marcel & Brad,
I would like to take a closer look with some tools (agent log output, traffic analyzer, etc.) to check whether the delay you see comes from network connectivity, the agent, or some other thing. If you don't mind, please PM me the info I'd require to replicate what you see.
For example, productcodes, versions passed, approximate time of day, number of times you issue the request, etc. (If you only do it once, you'll be seeing the potential worst-case scenario without a cache hit; twice and you stand a % chance of hitting the cache; five times and a much better chance of hitting the cache, etc.)
Regards,
Kelly
PS. I will say now that I won't be able to immediately look into your items as I do have three other tasks on my plate at work. That said, I do believe I'll eventually be able to check it out.
I would like to take a closer look with some tools (agent log output, traffic analyzer, etc.) to check whether the delay you see comes from network connectivity, the agent, or some other thing. If you don't mind, please PM me the info I'd require to replicate what you see.
For example, productcodes, versions passed, approximate time of day, number of times you issue the request, etc. (If you only do it once, you'll be seeing the potential worst-case scenario without a cache hit; twice and you stand a % chance of hitting the cache; five times and a much better chance of hitting the cache, etc.)
Regards,
Kelly
PS. I will say now that I won't be able to immediately look into your items as I do have three other tasks on my plate at work. That said, I do believe I'll eventually be able to check it out.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 30, 2005
09:13 PM
KellyF wrote:
Marcel & Brad,
I would like to take a closer look with some tools (agent log output, traffic analyzer, etc.) to check whether the delay you see comes from network connectivity, the agent, or some other thing.
I won't be able to get to your request right away, but I'd be happy to help. You understand what it's like being busy.
In the mean time, I know when I checked the delay more thoroughly using the Ethereal packet sniffer, the delay was definitely coming from the server side. Agent sent out a request...and the server sent the response a few seconds later. Agent always seems to instantly process the info once it receives it from the server. Also, I'd have to question that it takes longer over dialup than it does over high speed. Looking at the data sent to and from the server shows that the data is very small, just some parameters and several small VB script functions. Overall, the size is in the order of a few KB.
When I can get some time to set it up again, I'll PM you the 3-4 updates we're doing, and the conditions and version checking I've set for each.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 30, 2005
09:48 PM
Brad,
Curious question as you've also indicated that you've seen it at 3 to 4 seconds at other times. How many times did you run it during your testing? Approximately what times were you checking?
Thanks,
Kelly
Curious question as you've also indicated that you've seen it at 3 to 4 seconds at other times. How many times did you run it during your testing? Approximately what times were you checking?
Thanks,
Kelly
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 01, 2005
12:31 AM
KellyF,
Heh, my testing isn't very scientific or thorough.
One day, I saw it take a long time. I tried repeatedly, same result. I tried a few hours later, same result. I tried again, it took 15 seconds. I posted here, saw another person mentioning the same problem, and thought multiple updates slowing EnumUpdates() is normal.
A few days later, I went ahead and tried again. I posted about it here. It only took about 1-3 seconds the few times I tried it. If I recall, the times it hung for a while was during business hours, and the 1-3 seconds was a in the evening. Again, I'll test it out more thoroughly for you in a week or two.
Heh, my testing isn't very scientific or thorough.
One day, I saw it take a long time. I tried repeatedly, same result. I tried a few hours later, same result. I tried again, it took 15 seconds. I posted here, saw another person mentioning the same problem, and thought multiple updates slowing EnumUpdates() is normal.
A few days later, I went ahead and tried again. I posted about it here. It only took about 1-3 seconds the few times I tried it. If I recall, the times it hung for a while was during business hours, and the 1-3 seconds was a in the evening. Again, I'll test it out more thoroughly for you in a week or two.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 05, 2005
04:48 AM
Kelly,
I just tested it again (5 times). Each test resulted in the same delay: 23 seconds. This if for a total of 9 updates (6 active updates and 3 test updates). I've never seen that the EnumUpdates() call only took about 3 seconds, it always takes much longer.
I have tested it with a dial-up connection some time ago, and it then takes even longer I think. It seems to me that each update is processed separatedly. Some data is sent to the server and approx. 3 seconds later some data is received and the next update is processed and 3 seconds later some data is received and so on. I didn't use a packet sniffer or something, I looked at the data transfer LED's of the modem.
I'll PM you the details about the specific product versions / updates.
Marcel
I just tested it again (5 times). Each test resulted in the same delay: 23 seconds. This if for a total of 9 updates (6 active updates and 3 test updates). I've never seen that the EnumUpdates() call only took about 3 seconds, it always takes much longer.
I have tested it with a dial-up connection some time ago, and it then takes even longer I think. It seems to me that each update is processed separatedly. Some data is sent to the server and approx. 3 seconds later some data is received and the next update is processed and 3 seconds later some data is received and so on. I didn't use a packet sniffer or something, I looked at the data transfer LED's of the modem.
I'll PM you the details about the specific product versions / updates.
Marcel
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 05, 2005
08:30 AM
Marcel, thanks for the info. My big fear is that it'll be related to the network connectivity, so I plan to test from my home as well as asking someone in our other offices around the world to have a peek.
When I finally find the time to do the testing, I'll be sure to post a follow-up for us all.
Regards,
Kelly
When I finally find the time to do the testing, I'll be sure to post a follow-up for us all.
Regards,
Kelly
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 03, 2006
07:45 AM
Hi Kelly,
Do you know if this issue regarding the delays when checking for updates is resolved? I tested it with US agent 5.0.100.43906 but I'm still getting the long delays as mentioned in my previous postings.
Regards,
Marcel
Do you know if this issue regarding the delays when checking for updates is resolved? I tested it with US agent 5.0.100.43906 but I'm still getting the long delays as mentioned in my previous postings.
Regards,
Marcel
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 04, 2006
10:43 AM
Hi Marcel,
I can't say that I do, offhand. You probably already knew, but today is a national holiday so none of my fellow devs are available for me to ask. I will ask them about it when I return to the office on Thursday.
Regards,
Kelly
I can't say that I do, offhand. You probably already knew, but today is a national holiday so none of my fellow devs are available for me to ask. I will ask them about it when I return to the office on Thursday.
Regards,
Kelly
Marcel_NL wrote:
Hi Kelly,
Do you know if this issue regarding the delays when checking for updates is resolved? I tested it with US agent 5.0.100.43906 but I'm still getting the long delays as mentioned in my previous postings.
Regards,
Marcel
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 11, 2006
10:20 AM
Just an update to this thread. The EnumUpdates() is a blocking call and it does pull down the necessary vbscript to check conditions that are set; additionally, as it's interpreting vbscript, the more conditions, the slower the process is.
I believe that one of our engineers was working on an asynchronous call that would perform similarly to EnumUpdates(), but I won't pretend that I know the status on it. I'll check out that.
Regards,
Kelly
I believe that one of our engineers was working on an asynchronous call that would perform similarly to EnumUpdates(), but I won't pretend that I know the status on it. I'll check out that.
Regards,
Kelly
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 11, 2006
11:06 AM
I was purely trying to speed up the process of checking for updates since it takes a lot of time to execute. An asynchronous call would therefore not be interesting for me.
As I understand, it's the VBscript that's taking so long to execute. I was wondering if grouping all VBscript actions for all updates would reduce the amount of time, since I've noticed that each update is processed one-by-one. In my humble opinion, it takes a lot of time (2.5 seconds) to do a simple check (for each update) for the existance of a registry key or file on a local computer. Aren't there any other possibilities to speed up the process?
Best regards,
Marcel
As I understand, it's the VBscript that's taking so long to execute. I was wondering if grouping all VBscript actions for all updates would reduce the amount of time, since I've noticed that each update is processed one-by-one. In my humble opinion, it takes a lot of time (2.5 seconds) to do a simple check (for each update) for the existance of a registry key or file on a local computer. Aren't there any other possibilities to speed up the process?
Best regards,
Marcel
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 17, 2006
10:12 AM
Marcel,
My apologies for not having replied immediately, but I've had a few other tasks keeping me busy.... You're quite right, it does take quite a chunk of time to process the vbscript to perform the checks. We have discussed some possibilities including moving the condition checks into dlls/native code to reduce interpreter time, batching like condition checks, etc. However, we also realize that we need to take care with the choices we make as they will be distributed with all agents going forward. We also need to keep the older agents in mind.
I wish I could say more about what we're planning, but I cannot. This is a topic of discussion internally, but I can't give you a specific date or release. I do encourage you to use the company's feedback mechanism to ensure your concern is directed to those who make the decisions, as it can help escalate it in priority.
If you're looking for things you can do explicitly to speed the process: if your package were to provide a dll for client callout, whatever checks you desire could be done in native code (at least until we do something of that nature).
Regards,
Kelly
My apologies for not having replied immediately, but I've had a few other tasks keeping me busy.... You're quite right, it does take quite a chunk of time to process the vbscript to perform the checks. We have discussed some possibilities including moving the condition checks into dlls/native code to reduce interpreter time, batching like condition checks, etc. However, we also realize that we need to take care with the choices we make as they will be distributed with all agents going forward. We also need to keep the older agents in mind.
I wish I could say more about what we're planning, but I cannot. This is a topic of discussion internally, but I can't give you a specific date or release. I do encourage you to use the company's feedback mechanism to ensure your concern is directed to those who make the decisions, as it can help escalate it in priority.
If you're looking for things you can do explicitly to speed the process: if your package were to provide a dll for client callout, whatever checks you desire could be done in native code (at least until we do something of that nature).
Regards,
Kelly
Marcel_NL wrote:
I was purely trying to speed up the process of checking for updates since it takes a lot of time to execute. An asynchronous call would therefore not be interesting for me.
Aren't there any other possibilities to speed up the process?
Best regards,
Marcel
