You are viewing the documentation for Blueriq 17. Documentation for other versions is available in our documentation directory.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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:

StepActorDescription
1.User / BrowserThe User clicks a button on Page 1. This should cause the application to flow to Page 2.
2.Load BalancerThe Load Balancer sends the request to Runtime 1.
3.Load BalancerBecause Runtime 1 takes a long time to respond, the load balancer decides the failover to Runtime 2
4.Runtime 2Runtime 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 2Runtime 2 sends the success response to the Load Balancer
6.Load BalancerThe Load Balancer sends the success response to the User / Browser. The User now sees Page 2.
7.User / BrowserThe User clicks a button on Page 2. This should cause the application to flow to Page 3.
8.Load BalancerThe Load Balancer sends the request to Runtime 2.
9.Runtime 2Runtime 2 successfully handles the request, flows to Page 3 and stores the session state in the key-value store
10.Runtime 2Runtime 2 sends the success response to the Load Balancer
11.Load BalancerThe Load Balancer sends the success response to the Browser / User. The User now sees Page 3.
12.Runtime 1Runtime 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 keyspace notifications and interruptible flows.

Keyspace Notifications

Keyspace notifications are a feature of the key-value store. The key-value store clients (the Runtime nodes in this case) subscribe for notifications for a key or key pattern. The key-value store then notifies its clients when a change occurs for a subscribed key. 

When using Redis, keyspace notifications may be enabled using the following command:

config set notify-keyspace-events g$xKE

In order to enable keyspace notifications across restarts of the Redis instance, the setting should be made in the Redis configuration file, or the current configuration must be saved using the "config rewrite" command.

 

For possible values for the notify-keyspace-events configuration option and for more detailed information about Redis keyspace notifications, please see Redis Keyspace Notifications.

The values for this configuration option are used for the following purposes:

OptionUsed ByUsed For
gSpring SessionSpring Session uses this setting, among other things, to detect when an HTTP session is manually deleted.
$BlueriqBlueriq uses this for concurrency control on multiple runtimes.
xSpring SessionSpring Session uses this setting to detect when an HTTP session expires.
KBlueriqBlueriq uses keyspace notifications. That is, it can detect operations on a specific key or set of keys which match a pattern. This is used for concurrency control on multiple runtimes.
ESpring SessionSpring Session uses keyevent notifications. That is, it can detect keys affected by a specific operations.

 

Interruptible Flows

TBD

 

  • No labels

Didn't find the answer you were looking for? Try the advanced search!