If i have deployed camunda spring boot app as a hosted instance and i am running 3 instances of the camunda.These 3 instances are behind load balancer.
If i tried login in cockpit it will login in and open the dashboard page and well logs me out at the same time.
In network call i could see 401 errors. Can you tell what might be the issue?
Hi @Nishant-sehgal,
you have to configure sticky sessions in your load balancer.
Hope this helps, Ingo
1 Like
@Ingo_Richtsmeier sticky sessions are need to be configured only if physical load balancers (server side load balancers) are used?
1 Like
Hi @aravindhrs,
I could rephrase my statement:
You need sticky sessions if you use the prebuild login mechanism from the Camunda Webapps.
As it is based on cookies, you have to hit the same servlet engine with your login request, otherwise you have to login again.
I tried it a while ago by myself. I configured 2 camunda engines running in separated tomcat servers as shared engine using the same database. I inspected that the login is returned with a cookie from server one and the next request was handled by server two. server two didn’t know anything about this cookie (and the session), so the user has to login again.
As your session is saved in memory of server one, every upcoming request from this user has to be sent to server one as well.
Hope this helps, Ingo
@Ingo_Richtsmeier
Is there any other solution that is possible. Like Distributed Session Manager or session persistence that can be used along with camunda?
Will REST api’s that we will be using for deploying and communicating with camunda will also be enabled with session affinity as there will be no login required for REST API’s?
Hi @Nishant-sehgal,
the REST-API (engine-rest.war or camunda-bpm-spring-boot-starter-rest) and the Camunda webapp (camunda-webapp-*.war or camunda-bpm-spring-boot-starter-webapp) behave differently.
As stated above, Camunda Webapp uses a session cookie for authorization. It should be possible to share the session between more than one application server instance. But I haven’t tried it by myself.
For the REST-API, you define the authorization way by yourself in the web.xml. If you just remove the comment (https://github.com/camunda/camunda-bpm-platform/blob/master/engine-rest/assembly/src/main/webapp/WEB-INF/web.xml#L27-L42), the REST-API uses basic authorization, which is stateless and every request need the header to authorize.
If you change to any other authorization method, you have to deal with the state if there is any.
Hope this helps, Ingo
1 Like
Nice solution, I already enabled Sticky session in my target group on AWS and now it works fine!
Thank you.
1 Like