Page History

...

In a typical flow a user start the application and it gains a HTTP session and a Blueriq session, the applications is displayed and the user will perform its task. Once the user is done the application is closed and the Blueriq session including its child sessions are closed, afterwards the HTTP session is closed and everything is disposed of. This is the flow where users close their application and Blueriq is notified of the closure, so it can dispose of the user's resources. 

Session expiration

Session Sessions can expired expire once the user becomes inactive, or closes the application without notifying the Runtime.

...

External Flow can be run on different Runtime servers and therefor the session lifecycle can be distributed over one or more Runtime. 

Just like The initial part of the External Flow Lifecycle is the same as the traditional Session Lifecycle an application is started and , a HTTP session and Blueriq session is are created , afterwards the External Flow is initialised on the main Runtime so it keeps a weak link to the External Flow. A new External Flow Session is started on the other Runtime that includes an HTTP session and a Blueriq session. Once the External Flow is closed or ended a notification is send to main Runtime that the External is completed, for the application on the Blue Runtime. The Blueriq Runtime will initialize the External Flow to build a weak reference to the External Flow Session in The Green Runtime, this weak reference is required for when sessions are not cleaned up properly. The External Flow is started in the Green Runtime and a new HTTP session and Blueriq session is created with a reference to Blueriq Runtime session.

Once the External Flow has ended the Blue Runtime will be notified an continues the application, at this point the External Flow resource can be disposed on the Green Runtime ending the External Flow Lifecycle. 

External Flow Session expiration

External sessions are created when different runtimes start an external flow on the current runtime. The external sessions are closed when the http session has expired or it was idle. When the user logs out from the host project or the host session simply expired, the external session has no knowledge of that and will remain open even if not used.

To mitigate the problem an mechanism was introduced that uses the same redis connection (check configuration section) to store information about the host session, and the target runtime will check for all of its host sessions if any of them are closed or are still opened. Every time it finds one that was closed, then it will also close the external sessions that were created by that host session.

Image Added

Both Runtimes have a session which checks if the session is expired, the External Flow Session has an additional responsibility of notifying that the session has been closed. By doing so other External Flow Sessions can be notified that the parent session has been closed and no further actions should be performed.