session file
From times to times, especially after running and stopping the bot several times, I can't get the UI starting with the bot in status "stopped@
Comments (28)
-
reporter -
reporter note: the problem probably lies in the fact that the sessionFile doesn't get deleted properly in certain situations
-
This is the only call to session remove: SessionManager.removeSessionFile(); in NuBotBase Line 355
-
perhaps if System.exit is called?
-
reporter That is an option for sure.
here is a workaround to the issue which will also help moving towards
#542:On startup, if GUI= true AND there is an existing sessionFile, ask the user* to chose one of the following :
1) delete the file and continue
2)show a warning that a session file already exists therefore the GUI cannot be started. Print path to file in the warning.
Or, we can chose ourselves 2) .
If we prompt the user, since he is in UI mode, we can use JOptionPane
-
reporter update on the proposed solution : the file should be checked on "start" button,not on startup
-
reporter the failSafe check should be there in any case after pressing "start", if for whatever reason the file has not been canceled
show a LOG.warn and popup "A session file already exists in /path/to/file/ , cannot start the bot. Do you want to force file deletion and try again? yes|no "
-
reporter - changed title to Check existence of session file when pressing "start" button
-
I think this should not happen anymore with the deleteOnExit method. The problem was that the sessionFile was not deleted although it should have been.
-
reporter Earlier I got stuck because the file hasn't been deleted correctly. I was launching the server (without launching the bot) and shutting it down from the IDE hoping the shutdown sequence would delete the file.
Do you see any inconvenience in forcing the sessionFile.delete in the Global shutdown hook?
Maybe if a session (s1) is running, and I launch a second server and stop it, that would delete the sessionfile of s1. When
#542is in place, this wouldn't be a problem anymore since I wouldn't be able to start in a first place(?) -
-
assigned issue to
-
assigned issue to
-
-
reporter That line was also present last friday when I experienced the problem above :
I was launching the server (without launching the bot) and shutting it down from the IDE hoping the shutdown sequence would delete the file.
Try to reproduce that
-
reporter you can replicate it by manually adding the file to the folder
-
reporter - changed milestone to 0.3.0 - UI
-
I propose deactivating use of session file in ".nubot". If needed can be introduced later again, but at present I think the use is limited compared to issues with such a file.
-
reporter Would you be able to determine the session status without that file? If the answer is "yes" then this is a good idea.
the purpose of having a file on disk is to prevent/alert another java process from starting.
At the current state, it won't be possible to run two instances of the GUI server, since the system will block it with exception. And if running without GUI, then the bot shouldn't care if another session is already running.If you think that it makes sense, we can proceed .
-
on current develop the file is not used. we simply use the variables in memory (sessionmode).
without session file it is possible to startup multiple instances (as before without GUI). it's the question whether we need to prevent multiple sessions and if its worth the overhead. an alternative solution would be to check for running processes and show a warning (not trivial either). in general its not bad having this feature, but the solution is too fragile at the moment.
-
reporter Then we can definetly remove the session file :)
it's the question whether we need to prevent multiple sessions and if its worth the overhead.
We don't want. We will be moving in the future to an UI able to manage multiple instances at the same time.
-
I see. there is also the scenario that someone starts two instances - one with UI and one without. I guess in such extreme cases we can't prevent possible damage. it should not be too bad to assume that the user starts only one instance of the app to manage several bots.
-
-
reporter there is also the scenario that someone starts two instances - one with UI and one without. I guess in such extreme cases we can't prevent possible damage
Good catch, however I doubt this can do any damage. Each session will have its own state variable and the only filesystem operation are done on logs, which you have done an excellent work in separating.
-
removed session file. I left the code in the branch and commented it out.
-
- changed milestone to 0.3.1 - Price-feed streaming service implementation
- changed title to session file
-
- changed milestone to 0.3.2 - Consume price-feeds via web-sockets (instant shift, synchronised)
-
- changed status to resolved
-
reporter - changed milestone to 0.3.3 - T2>T1
-
reporter - removed milestone
Removing milestone: 0.3.3 - T2>T1 (automated comment)
- Log in to comment
Navigating to http://localhost:4567/opstatus , on a fresh start, results in
where does this data come from?
this is the fresh start log