session file

Issue #569 resolved
Desrever Nu created an issue

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)

  1. Desrever Nu reporter

    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]
    
  2. Desrever Nu reporter

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

  3. Benjamin Cordes

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

  4. Desrever Nu 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

  5. Desrever Nu reporter

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

  6. Desrever Nu 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 "

  7. 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.

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

  9. Desrever Nu 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

  10. 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.

  11. Desrever Nu 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 .

  12. 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.

  13. Desrever Nu 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.

  14. 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.

  15. Desrever Nu 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.

  16. Log in to comment