session file

[Desrever Nu]

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@

[Desrever Nu]

Navigating to http://localhost:4567/opstatus , on a fresh start, results in

{"duration":"16546.44 days","stopped":0,"sessionstart":"01/01/1970 01:00:00","status":"running"}

where does this data come from?

this is the fresh start log

12:34:02.995 [main] INFO  - start ui server. configfile config/myconfig/bitcoincoid.json [com.nubits.nubot.webui.UiServer:31]
12:34:02.996 [main] INFO  - launching on http://localhost:4567 [com.nubits.nubot.webui.UiServer:36]
12:34:03.422 [Thread-0] INFO  - == Spark has ignited ... [spark.webserver.SparkServer:120]
12:34:03.423 [Thread-0] INFO  - >> Listening on 0.0.0.0:4567 [spark.webserver.SparkServer:121]

[Desrever Nu]

note: the problem probably lies in the fact that the sessionFile doesn't get deleted properly in certain situations

[Benjamin Cordes]

This is the only call to session remove: SessionManager.removeSessionFile(); in NuBotBase Line 355

[Benjamin Cordes]

perhaps if System.exit is called?

[Desrever Nu]

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

[Desrever Nu]

update on the proposed solution : the file should be checked on "start" button,not on startup

[Desrever Nu]

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 "

[Benjamin Cordes]

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.

[Desrever Nu]

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 #542 is in place, this wouldn't be a problem anymore since I wouldn't be able to start in a first place(?)

[Benjamin Cordes]

We force delete here: https://bitbucket.org/JordanLeePeershares/nubottrading/src/26bed5e1dd6cd784d7d22c54555599c8f4f82bde/src/main/java/com/nubits/nubot/bot/SessionManager.java?at=develop#cl-194

[Desrever Nu]

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

[Desrever Nu]

you can replicate it by manually adding the file to the folder

[Benjamin Cordes]

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.

[Desrever Nu]

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 .

[Benjamin Cordes]

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.

[Desrever Nu]

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.

[Benjamin Cordes]

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.

[Benjamin Cordes]

some links on a more robust solution

http://stackoverflow.com/questions/19082265/how-to-ensure-only-one-instance-of-a-java-program-can-be-executed http://stackoverflow.com/questions/10508846/how-to-make-sure-that-only-a-single-instance-of-a-java-application-is-running

[Desrever Nu]

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.

[Benjamin Cordes]

removed session file. I left the code in the branch and commented it out.

[Desrever Nu]

Removing milestone: 0.3.3 - T2>T1 (automated comment)