Websocket-Ping doesn't stop directly after graceful application exit

[fls-indinf]

After exiting the current running application gracefully by calling launcher.dispose() after a logout(), the handled exitcode 1000 on closing the websocket connection is never sent by the server code and the sent "DISPOSE" isn't implemented.

   // WebSocketListener.java
    
    /**
    * {@inheritDoc}
    */
   public void pushDispose()
   {
     session.getAsyncRemote().sendText("DISPOSE"); 
   }
   // ...
   /**
    * {@inheritDoc}
    */
    public void close() throws Throwable
    {
    	session.close(new CloseReason(CloseCodes.GOING_AWAY /* = 1001 */, null));
    	
    	launcher = null;
    	session = null;
    }

The server just handles the 1000 exit code in AppProvider.tsx to stop the application:

     // ...
      ws.current.onclose = (event) => {
          // Stop sending ping and alive on ws close
          pingInterval.stop();
          clearInterval(aliveInterval.current);
          if (event.code === 1000) {
              // no reconnect
              wsIsConnected.current = false;
              console.log("WebSocket has been closed.");
              resolve();
          }
     // ...
      }

And because the reconnectInterval is currently not cleared, the websocket will try to reconnect to a closed session.
This way, the initially displayed "410 - Gone" message from the response will change to the "server is not reachable" message and restart the websocket connection.

Is there currently a other preferred way to close the application?
The EXIT request currently seems only be used in the development commands and also restarts the application.

[rjahn]

Not clear why you dispose an application after logout?

The server-side shouldn't dispose the application. The browser is the application and is responsible for such events.

[fls-indinf]

Thank you for your follow-up question.

In case e.g. the server is going down for maintenance or detects the session was killed, the application and launcher does get disposed.

[rjahn]

In this case, the client shows a banner and tries to re-connect.

What do you expect?

[fls-indinf]

Not clear why you dispose an application after logout?

It's not the common application logout, it's more of a exit function, which logs out and disposes the launcher to free all used ressources instantly.

The intent here is to tell the client to leave instead of to login again as it would be the case of a logout - but this is not what I intent to get out of this fix.

My issue here is, that the client currently (as far as I can tell) can't handle a full graceful application exit (a far fetched comparison to the Java exit where the application window is closing).
Currently the initial error (bright orange banner 410 - Gone) gets lost, a misleading? one appears (server is not reachable) and a error on the Middletier-Client (WebsocketListener#onClose - NullPointerException at launcher.removePushHandler) appears.

Back to the initial question:

Is there currently a other preferred way to close the application?

If not, should there be one or is it intended to keep the ping-task and session data active by design?

[rjahn]

It's not implemented to destroy the application on server-side and leave the page on client-side.
Could be a nice feature request (redirect after destroy).

If there's a problem with banners, we will check it.

The server-side stores all applications in http/intern sessions and the database objects (DBAccess, DBStorage) don't store records. So the UI (application, screens, databooks) consumes memory. If you do a logout, all/most resources should be closed and released.

The current implementation on server, already handles disposed applications:

//Application was disposed
if (launcher.isDisposed())
{
    setStatus(Status.CLIENT_ERROR_GONE);
    return null;
}

and client should handle it. In this case it makes no sense to keep the websocket open. Additional banners should be suppressed but I guess this is not fully checked.

[rjahn]

also check #474