Ignite Web Session Clustering design delima

387 views Asked by At

I have design question about Ignite web session clustering.

I have springboot app with UI. It clustered app ie multiple instance of springboot app behind the load balancer. I am using org.apache.ignite.cache.websession.WebSessionFilter()to intercept request and create\manage session for any incoming request.

I have 2 option

  1. Embed the ignite node inside springboot app. So have these embedded ignite node (on each springboot JVM) be part of cluster. This way request session is replicated across the entire springboot cluster. On load balancer I don’t have to maintain the sticky connection. The request can go to any app in round robin or least load algorithm.

Few considerations

  1. Architect is simple. I don’t have worry about the cache being down etc.
  2. Now the cache being embedded, its using CPU and memory from app jvm. It has potential of starving my app of resources.

    1. Have ignite cluster running outside of app JVM. So now I run client node in springboot app and connect to main ignite cluster.

Few considerations

  1. For any reason, if the client node cannot connect to main ignite cluster. Do I have to manage the session manually and then push those session manually at later point to the ignite cluster??
  2. If I manage session locally I will need to have sticky connection on the load balancer. Which I want to avoid if possible.
  3. I am leaning to approach 2, but want to make it simple. So if client node cannot create session (override org.apache.ignite.cache.websession.WebSessionFilter()) it redirects user to page indicating the app is down or to another app node in the cluster.

Are there any other design approach I can take? Am I overlooking anything in either approach?

If you have dealt with it, please share your thoughts.

Thanks in advance. Shri

1

There are 1 answers

1
Michael On BEST ANSWER

if you have a local cache for sessions and sticky sessions why do you need to use ignite at all?

However, It's better to go with ignite, your app will have HA, if some node is failed, the whole app still will work fine. I agree you should split app cluster and ignite cluster, however, I think you shouldn't care about the server and client connection problems. This kind of problems should lead to 500 error, would you emulate main storage if you DB go down or you can't connect to it?