Details
-
Type:
Bug
-
Status: Closed (View Workflow)
-
Priority:
Critical
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: 9.1.0 Major Release
-
Labels:
-
Story Points:1
-
Epic Link:
-
Sprint:Fall 6 : 28 Oct to 8 Nov
Description
I ran across an issue when running the IGB 9.1.0 installer on macOS high sierra, which resulted in 'hang-ups' when progressing through the installation process. These involve a spinning color wheel that lasts for around a minute between steps/clicks. The installation completes successfully, but after multiple of these hang-up occurrences. Hang ups are not specific to any specific step; they seem to be present for all steps. The same issue is observed with the IGB 9.0.2 installer, but not with the one for IGB 9.0.0, which seems to have a different UI and likely uses a different version of install4j.
Building and running from netbeans or terminal works just fine.
For reference, the system used was a MacBook Pro (13-inch, Early 2011), running macOS high sierra version 10.13.6 (17G65).
Attachments
Issue Links
- relates to
-
REL-17 Verify functionality of the installer
-
- Testing Complete
-
Activity
For the next steps, probably we should search through the user support issues at EJ Technologies, vendor of Install4J.
If this is a new bug, we can notify them and hopefully help them make the software more robust.
Going along with this, we can check into whether there is a new version of the installer software available and also if there is a new version of the JRE. If yes, upgrading might fix the problem.
Thank you for finding this Philip Badzuh !
I tried running the installer on a new user account and the issue went away. Logging into my main account, I tested the installer after individually starting several programs that I have set up to run at startup and learned that the issue results from the window manager I use, Moom. Quitting/starting Moom, both when the installer is running and before running it, affects installer responsiveness.
I tried to examine outgoing packets using tcpdump on all ports, since I am unsure how to route installer traffic through a proxy. I did this for both the normal and problematic state, however, even with all user applications closed, the OS makes its own requests, making comparison difficult - I'm not entirely sure what requests install4j and Moom make.
I also examined the process tree using pstree and found that the installer and Moom run off of the root process, launchd, like all other processes. I'm not entirely sure how to determine whether the issue is associated with resource contention, but throughout my testing, it was always the installer hanging up (Moom never showed any issues), so this doesn't seem likely.
Request: Could you use a packet sniffer to observe any network requests the installer might be making?
In thinking of newer versions, I noticed that my Moom version was out of date, tried running the newest version, and the issue went away!
I also tried running tcpdump for the problematic version of Moom again with a -k flag which can show the process associated with each request. After determining the process IDs of Moom and the installer, it doesn't seem like either are making any requests, which makes sense, considering the installer should already have all the files required for installation.
EJ Technologies points to stackoverflow for its support issues, and suggests using the 'install4j' and 'jprofiler' tags when seeking help. I was unable to find any Moom-related issues associated with either of these tags. It would be nice to report the issue, however, since there's an update to Moom that fixed the problem and my network logging doesn't seem to provide any useful information, I will hold off from asking for assistance on stackoverflow, unless you think it would still be useful, [~aloraine].