Skip to Content

Web Application session expiry problem on SAP J2EE Engine in Load Balanced Environment

In my earlier Understanding the SAP J2EE Cookie in a Load Balanced environment I explained the structure of SAP J2EE Cookie in a Load Balanced Environment. The reason why we have to study the structure of the cookie was due to the following problem:

We were running ESS/MSS Applications (WebDynpro based) on SAP EP 7.0 (NW04s) in a Load Balanced environment with 3 physical servers. Whenever we use to login to the Portal and access the ESS/MSS Applications, it used to show up the first page properly. But when we want to navigate to the next page in the same application it used to give us the following error: ) to send the subsequent request to the same server node.

The solution to this problem is thus making sure that the Load Balancer is able to resolve the Load Balancing Cookie so that it sends the subsequent request to the same server node as the last request. This solution applies in general to all the load balancers.

Since we were using the Cisco Load Balancer, we have to configure Sticky Cookie to solve this problem. Below is the sample configuration of our load balancer.


!*************************** GLOBAL ***************************

  ip route 1

!************************* INTERFACE *************************

interface  3/2

  bridge vlan 2

!************************** CIRCUIT **************************

circuit VLAN1

  description “client vlan”

  ip address

circuit VLAN2

  description “server vlan”

  ip address

!The string value configured in the service must match the value of

the cookie for a particular server.

!************************** SERVICE **************************

service test1

  ip address

string < server1 Dispatcher Node ID >


service test2
ip address

string < server2 Dispatcher Node ID >


service test3
ip address

string < server3 Dispatcher Node ID >


!The string prefix must match the cookie name. We recommend that you
include the `=’ as part of the string prefix.
!*************************** OWNER ***************************
owner test

content stickyCookie
advanced-balance cookieurl
string prefix


    add service test1

    add service test2

    add service test3

    port 80

    protocol tcp


The dispatcher Node ID can be easily obtained through Visual Admin or Config Tool as explained in my earlier Understanding the SAP J2EE Cookie in a Load Balanced environment. After doing this configuration we were able to resolve the problem.

Here is my understanding of the solution. When the Load balancer sends a request to the SAP J2EE Engine for the first time for an application, along with the response, it receives a cookie from SAP J2EE engine in the following format – saplb_*=(J2EE1234500)1234550; PortalAlias=portal; JSESSIONID=( J2EE1234500) ID1111666655DB111111111111111End. To maintain the state of the application, the subsequent request from the load balancer should be sent to same dispatcher node i.e., J2EE1234500. To achieve this we need to relate the server IP Addresses to their corresponding SAP Dispatcher Node. By doing this the load balancer  will be able to identify to which IP Address it needs to send the subsequent request. So as per above configuration, our service test1 will look something like this:

service test1
ip address
string J2EE1234500

If incase you have multiple server nodes, to send the request to correct instance you need to add the command

string match specific first-string-found

in the configuration above. In that case the configuration will look like :

service test1
ip address
string match first-string-found J2EE1234500

Summary :

I have explained above the problem of session expiry in a load balanced environment. The solution is very specific to Cisco Load Balancer. But in general the concept of “sticky cookie” will apply regardless of the Load Balancer you use.

References :

You must be Logged on to comment or reply to a post.
  • Nice to see some infrastructure related blogs.

    However, I think it can be done in a simpler way.  For each user always be sticky for subsequent request to the ip-address you load balanced the first request to. We’re using this approach with another load balancer against a portal contain WD components without any problem. We just make sure the sticky timeout is larger than our session timeout on the portal.

    It would surprise me alot of cisco doesn’t have a similar functionality.

    It also works fine when you have multiple server nodes (jlaunch process) pr physical server, since the dispatcher will read the cookie information and forward the request to the correct node.

    What happens with this setup
    First request:
    1. Load balancer sees user has no session. Picks a server to load balance to based on health checks and forwards the request
    2. Dispatcher on target server sees no loadbalancing cookie, and therefore forwards the request to an arbitrary server node

    Subsequent request within sticky timeout
    1. Load balancer sees the user has a session against one of the servers. If it is up, it forwards the request, if it is down it picks a server as if this was the first request. Sticky time is reset again for the user.
    2. Dispatcher on target server see a load balancing cookie, and forwards the request to a particular server node


    • Hello Dagfinn,

      We actually initially tried playing around with the timeout option. But this didn’t worked for us. May be we were not doing it at the right place.

      Then after reading the Cisco Documentation we got the information about the Sticky Cookie. If you read the links to Cisco Documentation, they talk about the same problem and Cisco’s solution for the same.

      By the way, which Load Balancer were you working with? Please let me know.


  • Hi Shubham,

    We are also having problems with sessions on our Cisco load balanced SSL portal… We’ve looked at some our cookies, and have noticed that sometimes the dispatcher of the J2EE cookie differs to that of the Load Balancing cookie in the same session – i.e. we get a cookie that looks like this:

    saplb_*=(J2EE9542000)9542050; PortalAlias=portal; JSESSIONID=(J2EE9408900)ID1686578750DB00245375545564637943End; SAPWP_active=1; DSMKeepAliveStamp=1179226311375

    Is this a sign that we have a problem? Surely the two dispatcher ids should always match? I would really appreciate your comments on this.

    Many thanks

  • Hi, I am having exactly the same problem, but in SAP Web Dispatcher.
    What is the syntax that I need to add to the config file?

    Stuart Banner

  • Hi I ama getting the Same error But on apache web server.

    Could you throw some light on how resolve the same issue on Apache.My load balancing and Reverse proxy everything work fine. But when i try to access the ESS from the Portal it throws the pagebuilder error..


    • Hi Jamshid,

      I have never worked with Apache Load Balancer and hence will not be able to help you with the code/config.

      However, the concept should be something similar. You would need to find out what is the counter part of sticky cookie in Apache Load Balancer.


      I am not a Basis Consultant

  • Hi Shubbam,
    We are also facing similar kind of issues.

    It looks like config is not related to CISCO ACE 4710 as I don’t see the commands specified in the blog. We would appreciate if you please let us know if we can get similar commands for CISCO ACE 4710 in routed mode.

    Thank You.