Closed guirak closed 11 months ago
That would basically our suggestion:
We add these Properties to the WebAPI (to the new class InstanceInfo)
BooleanProperty afkProperty;
BooleanProperty backgroundProperty;
LongProperty lastUserActionProperty;
// Case 1, disable the default behaviour in the jpro.conf:
closeInstanceStrategy = {
// This disable the default configuration
}
In the code you can use method WebAPI.closeInstance() and the properties above, to write an own logic.
// Case 2 in the jpro.conf:
closeInstanceStrategy = {
short = {
duration = -1 // optional
closeOnDisconnectAfter = ... // -1
closeOnAFKAfter = ... // -1
closeOnBackgroundAfter = ... // -1
}
medium = { // optional
duration = 100s
closeOnDisconnectAfter = ... // -1
closeOnAFKAfter = ... // -1
closeOnBackgroundAfter = ... // -1
}
long = { // optional
duration = 1000s
closeOnDisconnectAfter = ... // -1
closeOnAFKAfter = ... // -1
closeOnBackgroundAfter = ... // -1
}
}
// You can add custom values to all of them.
Hi Florian,
It seems to be exactly what I need.
What is the difference between background and AFK ?
Thank you.
HI Guirak,
As Florian already explained in the previous quote, we have added new properties called afk
, background
and lastActionTime
to the InstanceInfo
class in the WebAPI. Following up is the resume of our current implementation of the closeInstanceStrategy feature containing also the default values. Please use newest JPro version 2023.3.0-M1
and let us know if this works well for you.
Also you asked:
What is the difference between background and AFK ? An instance goes into background mode when new switch to a new tab in the browser, but not when you focus another window.
The configuration is structured into three optional strategies: short
, medium
, and long
. Each strategy contains the following properties:
until
: This property defines, until which duration the strategy is used. It must be not set, for the last strategy.closeOnDisconnectAfter
: The second after which the instance will close if a disconnect is detected. -1 means it will not close after disconnect.closeOnAFKAfter
: The second after which the instance will close if a user is detected to be AFK (Away From Keyboard). -1 means it will not close after AFK.closeOnBackgroundAfter
: The second after which the instance will close if the application goes to the background. -1 means it will not close after going to the background.Here is the current default configuration:
jpro {
closeInstanceStrategy {
short {
until = 60
closeOnDisconnectAfter = 5
closeOnAFKAfter = -1
closeOnBackgroundAfter = -1
}
medium {
until = 900
closeOnDisconnectAfter = 30
closeOnAFKAfter = -1
closeOnBackgroundAfter = -1
}
long {
closeOnDisconnectAfter = 180
closeOnAFKAfter = -1
closeOnBackgroundAfter = -1
}
}
}
Regards
Hi besidev,
Thank you for this proposal. I have tested the mechanism and its working well.
I see 2 points to improve :
1st point : When the instance is closed, the graphical interface is frozen. For an end-user this will look like a bug. I have seen in the shutdown logs that the reason for closing is indicated : close-afk, close-background :
[INFO ] c.j.i.c.InstanceImpl - [JPro] -> Instance closed: {app_name: mmione, host_name: Unknown, instance_id: 1409629544, browser: Unknown, browser_url: , client_ip: , reason: close-background}
Ideally, I wish be able to have the possibility to be triggered on these events (close-afk, close-background) to open an URL which indicate the session has expired.
2nd point : When closing the tab, the instance closed trigger is for close-background instead something like close-tab. It's not the case with the view :
[INFO ] c.j.i.s.ViewInfo$ - [JPro] -> View closed: {app_name: mmione, host_name: localhost:8082, instance_id: 1409629544, browser: Unknown, browser_url: http://localhost:8082/, client_ip: 127.0.0.1, reason: tab closed}
[INFO ] c.j.i.c.InstanceImpl - [JPro] -> Instance closed: {app_name: mmione, host_name: Unknown, instance_id: 1409629544, browser: Unknown, browser_url: , client_ip: , reason: close-background}
Furthermore the instance is not closed immediatly but with the duration configured for the closeOnBackgroundAfter. It will be good to differentiate this case from the afk and background cases to be able to release the heap quickly. Is it possible ?
Regards,
Hi Guirak,
We just published a second milestone release of JPro, which now contains an updated InstanceCloseManager
by introducing closeOnTabCloseAfter
property which holds the seconds after which the instance will close if the tab is closed. Please checkout the newest JPro version 2023.3.0-M2
to try it out.
Here is the updated default version of the Close Instance Strategy Configuration:
jpro {
closeInstanceStrategy = null // important to disable all values of the default strategy
closeInstanceStrategy {
short {
until = 60
closeOnTabCloseAfter = 0
closeOnDisconnectAfter = 5
closeOnAFKAfter = -1
closeOnBackgroundAfter = -1
}
medium {
until = 900
closeOnTabCloseAfter = 0
closeOnDisconnectAfter = 30
closeOnAFKAfter = -1
closeOnBackgroundAfter = -1
}
long {
closeOnTabCloseAfter = 0
closeOnDisconnectAfter = 180
closeOnAFKAfter = -1
closeOnBackgroundAfter = -1
}
}
}
Hi Besidev.
Perfect for me! It's working well. Thank you.
About my remark :
Ideally, I wish be able to have the possibility to be triggered on these events (close-afk, close-background) to open an URL which indicate the session has expired.
When the instance closed happens, the Application.stop method is triggered. Is it possible to know the reason of the closure in the stop method ? (Maybe changing the public signature of the JProApplication.stop method : stop(ClosureReason) or providing a getClosureReason in the WebAPI).
I would like to open a dialog or go to a specific URL or something else to inform the user the app has been closed and invite it to reconnect.
Currently the UI stays frozen. For the end-user, it looks like more as a bug than an app or session timeout closure.
Thank you,
Regards.
CloseReason We can provide the closeReason! That should be a simple change.
Post-Close Action It's tricky to do something when the Instance is closed. By definition - the connection to the server has stopped. Maybe it's possible to define a javascript function, which is executed on close? But all these actions are quite limited.
We first need a good design for such a feature.
Can't you just let the user reconnection automatically, when he opens the tab again? This should already be the default behavior. Afterward, you can do whatever you want. If it's just a simple login screen, then it shouldn't require many resources anyway.
Hi Florian,
In fact, when the tab is open again after a close-afk or a close background, all buttons and controls are frozen as the app has been closed, JPRO doesn't reconnect automatically in this case (it's what I'm seeing in my app, maybe I have something in my code that causes this behavior).
For a non trained user, this behavior looks like a bug because he has gone out to take a coffee and 10 minutes after the interface become frozen, he come back and see that he can't do anything else without any explanation. He must to think in refreshing the page to reload it.
The behavior that seems to me ideal would be to keep frozen all with a dark overlay and to have a HTML dialog over the frozen interface that say the session has been closed (customizable message) and a button "Reconnect" to reload the page.
If not possible, receiving an event before closing the instance would be a good alternative, in this case I will simply use the WebAPI.openURL to go to an html page that say the session has been closed.
Regards,
Hi Florian and Besidev.
I have tested JPRO 2023.3.0. The message with the blur overlay on AFK and the reloading on click and on showing again the tab are perfect for me .
Thank you.
Is it possible to provide a custom message (jpro.conf parameter or WebAPI method or resource file) ?
Hi Florian,
I create here a ticket about our discussion.
For the keep alive mechanism, you said me that there is 2 variables to configure it :
The delay to close an instance is the following : keepAppAliveFor + keepAppAlivePercentage * TimeItWasAlive
I think you do this to close quickly a just opened instance but ensure a used instance will not be closed on short internet disruption. The problem with this is if the server is running for a long time. For example :
I think it doesn't make sense.
I suggest you something in the following way with 3 variables :
With this, the close instance delay will be the following : if(TimeItWasAlive > shortLongSessionsThreshold) => keepAppAliveOnLongSessions else => keepAppAliveOnShortSessions
This permit to distinguish the case of a not used app vs one that is really used.
Additionally of this, it will be good to have some mechanism to close instance for tabs that are afk since a certain time. This will permits to release the RAM when a user has finished to use the app but keep it open.
For this, maybe it will be good to have the possibility to control it from the code : for example a closeInstance function in the WebAPI. This will permit to control the condition to close the instance or to save some state before closing.
Regards