1

I have tried to put Eclipse Scout application behind proxy using HAProxy and Docker with two Tomcat containers, but I have some problems. Application is working fine if only one server is active, or both of them. But when active server is shutdown, I am redirected to login screen. Also when only one server is active and second is started I am also redirected to login and session is lost.

What I want to achieve? Distribute traffic to another Tomcat instance if first is overloaded or active Tomcat instance is shutdown. When deploying new version, I would like if possible:

  1. Shutdown Tomcat1, traffic is redirected to Tomcat2
  2. Put new .war file and deploy it.
  3. Turn on Tomcat1
  4. Shutdown Tomcat2, traffic is redirected to Tomcat1 with new version
  5. Put new .war and deploy it
  6. Turn on Tomcat2.

This is my haproxy.cfg:

global
  stats socket /var/run/api.sock user haproxy group haproxy mode 660 level admin expose-fd listeners
  log stdout format raw local0 info

defaults
  mode http
  timeout client 10s
  timeout connect 5s
  timeout server 10s
  timeout http-request 10s
  log global

frontend stats
  bind *:8404
  stats enable
  stats uri /
  stats refresh 10s

frontend myfrontend
  bind :80
  default_backend webservers

backend webservers
  dynamic-cookie-key MYKEY
  cookie JSESSIONID prefix nocache
  option prefer-last-server
  stick-table type string len 36 size 1m expire 8h
  stick on cookie(JSESSIONID)
  server tomcat1 tomcat1:8080 cookie tomcat1 check
  server tomcat2 tomcat2:8080 cookie tomcat2 check

I tried:

  • HAProcy configuration without dinamic-cookie-key
  • to put JVMRoute to each tomcat instance and naming them tomcat1 and tomcat2
  • to add scout.nodeId config property on each myapp.server.war config.properties file naming them tomcat1 and tomcat2
  • setting sessionCookiePath in server.xml in each tomcat instance to "/" path.

Every time I get same result. Session invalidated, redirected to /logout.

This is my session in when viewing in developer tools, when tomcat2 is active, session has tomcat2 prefix and suffix: JSESSIONID tomcat1~10AD131758FD28D179111B2261ADD9BF.tomcat1

I am using:

  • Scout 11
  • Tomcat 8.5.79
  • OpenJDK
  • HAProxy 2.4

What can I try more to have active session when switching servers? What I am doing wrong?

Thank you!

sysdba
  • 57
  • 5

1 Answers1

1

In classic Scout, everything you see in the application is managed by a client model on the UI server. This statefull client model is held together by the IClientSession. (This is why you can reload the page and everything is still there.)

Unfortunately, the classes that make up the client model (destop, outlines, forms, fields etc.) are not serializable. This means that they cannot be "moved" to other server instances. If a server goes down, all of its state is lost and cannot be recovered. Therefore, all users with a client session on that server are automatically logged out.

There are basically two aproaches to solve this problem:

  1. Gradually phase out users on server A by updating your load balancer so that new sessions are always redirected to server B, but existing sessions stay intact. When the last session on server A is gone, you can update it, and enable it again on the load balancer. Then do the same thing with server B.

    Drawbacks:

    • The process is quite slow, since it may take a while for the last user to sign out. You might want to send them a notification like "This server will be shut down in 1 hour, please save your work and log in again" to speed things up.
    • For a while, server B has to handle the entire workload.

  2. Rebuild your application and use a stateless architecture. The frontend logic is completely running in the browser. Calls to backend services are stateless, e.g. don't rely on a server-side session. This can be achieved using ScoutJS, or any other frontend framework.

    Drawbacks:

    • Reimplementation of the entire frontend code in JavaScript necessary.
    • Change of paradigm. Many convenient features have to be replaced or redesigned (e.g. service tunnel, input validation, authorization).
bsh
  • 61
  • 2