You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The attached three threaddumps (nearly identical) were captured after removing the checkbox in the GUI for the SUT....so the SUT should have stopped when removing that check box, but it did not.
Manually, I executed this: C:\Users\eoste>taskkill /PID:12708 ERROR: The process with PID 12708 could not be terminated. Reason: This process can only be terminated forcefully (with /F option).
Need to compare the attached to threaddumps captured in the easy-to-reproduce scenario.
When thread dumps are captured prior to when it DOES stop correctly.
One possible cause is that running a load test somehow makes it harder to stop.
This gets a little weirder.
After I tried to windows taskkill WITHOUT the force flag, detailed above, I added the force flag and the SUT died.
So I thought, perhaps I just need to add the force flag in OsUtils 'kill' code...but I looked and the force flag is already there.
So it seems that the process died after the code submitted a kill, I submitted a kill from the command line WITHOUT the force, then I resumitted the kill from the command line.
I captured these three thread dumps (01b.txt, 02b.txt, 03b.txt) before adding the check mark to stop the SUT....and the SUT stopped completely.
There are MANY differences to analyze between 01.txt (jvm wouldn't shut down) and 01b.txt (jvm shut down correctly).
One other nagging thing to explore. In the first example when the JVM was shut down, I was probably running snail4j/build/postInstallDepsRefresh.sh WHILE the SUT was up and running....that's not a usual use case, trying to OVERWRITE the %USERPROFILE%/.snail4j/sutApp while the code in the same folder is UP AND RUNNING!!!
The attached three threaddumps (nearly identical) were captured after removing the checkbox in the GUI for the SUT....so the SUT should have stopped when removing that check box, but it did not.
Manually, I executed this:
C:\Users\eoste>taskkill /PID:12708 ERROR: The process with PID 12708 could not be terminated. Reason: This process can only be terminated forcefully (with /F option).
Need to compare the attached to threaddumps captured in the easy-to-reproduce scenario.
When thread dumps are captured prior to when it DOES stop correctly.
One possible cause is that running a load test somehow makes it harder to stop.
01.txt
02.txt
03.txt
This gets a little weirder.
After I tried to windows taskkill WITHOUT the force flag, detailed above, I added the force flag and the SUT died.
So I thought, perhaps I just need to add the force flag in OsUtils 'kill' code...but I looked and the force flag is already there.
So it seems that the process died after the code submitted a kill, I submitted a kill from the command line WITHOUT the force, then I resumitted the kill from the command line.
Source code, showing the kill parameter is in place for both linux and Windows:
https://github.com/eostermueller/performanceAnalysisWorkbench/blob/master/backend/src/main/java/com/github/eostermueller/snail4j/OsUtils.java#L218
The text was updated successfully, but these errors were encountered: