This article explains the cause and what has been done to resolve this issue in the latest builds.
This issue only affects systems which do NOT have internet access, which means the majority of customer sites will never see it. If you are able to ensure external access for specific sites, it would be best to enable the following two sites for registration and version update checks respectively:
When logging in Winthrop products check they are registered. As part of the “table level” registration check, the code will “ping” the registration server once a month to check if it can be accessed. It turns out that this ping was taking up to 4 minutes before timing out. When the ping failed, the last checked date was not getting updated, so it would attempt to ping again any time a table level registration check was made (including subsequent logins).
This check could occur once for each of the modules for the product installed:
- Visual Studio Integration Toolkit (VSIT) has 2 modules
- Batch Posting Service Toolkit (BPST) has 1 module.
- GP Power Tools (GPPT) has 4 modules.
There are other registration checks made while the application is running but they work at the memory level only and so are very fast. However, when opening the product’s About window or Registration window the table level registration check is used and so there can be a delay before these windows open.
Also, there are two other situations where Winthrop products attempt to communicate via the internet.
- The version update check to look for new releases.
- The registration automatic check to look for new keys when the current subscription is due to expire.
Both of these checks can be disabled by an administrator user. Open the Update Check window from the Options menu on the About window.
Open the Registration window using the Registration button on the About window.
Use of the “No Automatic check” options on both of these windows is only recommended if you have no internet connection as you will lose functionality such as notifications to administrator users when updates are available and automatically updating subscription keys from the server when subscriptions have been renewed.
The solution to this performance issue comes with a number of changes in the latest builds to help resolve this issue.
- The monthly connection check will update the last checked date even if it fails and so will not check again for 30 days. This also ensures it only checks once regardless of how many modules are in the product.
- The version update check will update the last checked date even if it fails and so will not check again for the specified number of days.
- A different variant Ping command is being used which should timeout faster and so the delay should not be as significant.
- Once a system has been detected as offline by the Ping command, it will stay offline for the remainder of the session.
- An option has been added to the Automatic check drop down list for “System is not internet connected, stay in Offline Mode”. This option is only available if already in Offline Mode and will make sure the system stays in Offline Mode. This will disable all communication with the registration server including the monthly communication check.
The result of these changes is that an offline system might get one delay on login and one delay when opening the Registration window, but once the Automatic Check has been set to stay in Offline Mode, there will be no further delays.
Note: you would still want to set the Version Update Check to No Automatic check.
Please ensure you are running a build with Modified Date: 18-Feb-2019 or later with the build numbers below (or later):
- Visual Studio Integration Toolkit (VSIT) build 15.4.
- Batch Posting Service Toolkit (BPST) build 10.3.
- GP Power Tools (GPPT) build 26.2.
This article was originally posted on http://www.winthropdc.com/blog.