Page History
...
When the monitor receives a notification that a new guard was written, it can identify the session and request which caused that guard to be written. It then interrupts all registered sessions which did not register on that request. The following diagram illustrates this process:
| Step | Actor | Description |
|---|---|---|
| 1. | User / Browser | The user clicks a button on Page 1 of the application. |
| 2. | Load Balancer | The Load Balancer sends the request to Runtime 1. |
| 3. | Runtime 1 | Before the event handling begins, the session and request are registered with the monitor component. The monitor component generates a GUID to represent the request, registers the session/request pair for the duration of the request and writes a guard key in the key-value store (which is composed from a namespace, session id and the request GUID). |
| 4. | Redis | Redis notifies Runtime 1 that a guard has been written. Runtime 1 has a single session and request pair registered, and the request GUID of the request matches the request GUID of the guard. Therefore, this does not represent a concurrent modification and no action is taken. |
| 5. | Redis | Redis notifies Runtime 2 that a guard has been written. Runtime 2 has no session/request pairs registered at this time, so no action is taken. |
| 6. | Load Balancer | Since Runtime 1 takes too long to respond, the Load Balancer decides to failover to Runtime 2 and resends the request to Runtime 2. |
| 7. | Runtime 2 | Before the event handling begins, the session and request are registered with the monitor component. The monitor component generates a GUID to represent the request, registers the session/request pair for the duration of the request and writes a guard key in the key-value store. |
| 8. | Redis | Redis notifies Runtime 1 that a guard has been written. |
| 9. | Redis | Redis notifies Runtime 2 that a guard has been written. The session ID and request GUID from the guard match those of the registered session/request pair, so no action is taken. |
| 10. | Runtime 1 | Runtime 1 has a single session and request pair registered. The session ID from the guard matches the session ID of the registered session/request pair, but the request GUID does not match. This indicates that while the request started at step 2 is still executing, another request was started for the same session (potentially on another node, but it may be the same node as well). The monitor component on Runtime 1 interrupts the registered session. This sets the interrupted flag |
| 11 | Runtime 1 | As soon as the Flow Engine exits the current service call or function call node (or as soon as entering one), it detects that the interrupted flag is set and exits with an exception. An error response is sent to the Load Balancer. The Load Balancer does not forward this response back to the user. |
| 12. | Runtime 2 | Runtime 2 finishes handling the event, flows to Page 2 and saves the session state in the key-value store. |
| 13. | Runtime 2 | Runtime 2 sends a success response to the Load Balancer. |
| 14. | Load Balancer | The Load Balancer sends the success reponse to the User / Browser. |
How a request which may modify the session is identified
...
When using a key-value store other than Redis, the IKeyValueStore interface must be implemented and exposed as a Spring managed bean. In order to provide concurrency control an additional interface, IKeyspaceMonitor, must also be implemented and exposed as a Spring managed bean. The concurrency control component within the Runtime will use the provided implementations for IKeyValueStore and IKeyspaceMonitor to register for keyspace notifications and write guards in the key-value store.
Thread Pools and Configuration Options
...
The default implementation in the Blueriq Redis Key-Value Store Component uses 2 thread pools:
- the subscription thread pool is used when subscribing for notifications for a specific key or key pattern
- the task thread pool is used for dispatching notifications
See 3. Key-value store API and default component [editor] for details on how to configure these thread pools . The default configuration used is:
- Subscriptions use a CACHED thread pool. The Runtime subscribes for a key pattern only once, at startup. If the keyspace notifications API is used more often, the thread pool type may be changed to FIXED.
- Notifications use a FIXED thread pool with 4 threads. Each session modification request causes a guard to be written, which in turn triggers a notification on all Runtime nodes. The amount of work done for each notification is low. Depending on load, the default pool size and type may be adjusted as needed.
Overview
Content Tools