You are viewing the documentation for Blueriq 17. Documentation for other versions is available in our documentation directory.
Introduction
When running on multiple nodes without concurrency control, it is possible for the session to become desynchronized during a failover event. Consider the following scenario, where the user (browser) is on Page 1 of an application:
| Step | Actor | Description |
|---|---|---|
| 1. | User / Browser | The User clicks a button on Page 1. This should cause the application to flow to Page 2. |
| 2. | Load Balancer | The Load Balancer sends the request to Runtime 1. |
| 3. | Load Balancer | Because Runtime 1 takes a long time to respond, the load balancer decides the failover to Runtime 2 |
| 4. | Runtime 2 | Runtime 2 successfully handles the request, flows to Page 2 and stores the session state in the key-value store (Redis in this example) |
| 5. | Runtime 2 | Runtime 2 sends the success response to the Load Balancer |
| 6. | Load Balancer | The Load Balancer sends the success response to the User / Browser. The User now sees Page 2. |
| 7. | User / Browser | The User clicks a button on Page 2. This should cause the application to flow to Page 3. |
| 8. | Load Balancer | The Load Balancer sends the request to Runtime 2. |
| 9. | Runtime 2 | Runtime 2 successfully handles the request, flows to Page 3 and stores the session state in the key-value store |
| 10. | Runtime 2 | Runtime 2 sends the success response to the Load Balancer |
| 11. | Load Balancer | The Load Balancer sends the success response to the Browser / User. The User now sees Page 3. |
| 12. | Runtime 1 | Runtime 1 finishes handling the request received at step 2, flows to Page 2 and writes the session state in the key-value store. |
After step 12. there is a discrepancy between what the user sees (Page 3) and the state of the session in the key-value store (Page 2). Additionally, all data entered by the user at step 7. is lost, as the profile written in the key-value store at step 9. is overwritten at step 12. The problem is further compounded if the flow from Page 2 to Page 3 called an external web service.
Another symptom of the desynchronized session is that the Runtime ignores all further events from the user. The user is clicking buttons on Page 3, but the session is actually on Page 2. In order to re-synchronize the state of the session with the front-end, the user needs to refresh the page.
Clearly, this scenario presents a problem. Blueriq Runtime addresses this multi-node concurrency problem by using the keyspace notifications and interruptible flows.
Overview
Content Tools