JSessionID Expiration

Not sure what you're asking here, but 1800 seconds is the amount of idle time a persistence record will be maintained in the persistence table. As long as the client is making requests that record is maintained. If the browser is left open but doesn't make any requests, then the record will go away (unless there's some Ajax happening in the background).

Hi Kevin, Based on the testing, even we proved that persistence record was removed (after the timeout set) our expectation was the browser session will be disconnected and it will going to redirect it back to logon page.

thanks

You might be confusing persistence with session management. The F5 is going to use your JSESSION value to maintain load balancing affinity to a single selected backend server. Once that persistence record goes away the F5 should make a new load balancing decision. That has nothing to do with how the application and/or server behaves. If the client is still presenting a JSESSION token it's possible that the server (potentially a different server) could be honoring that.

Hi Kevin,

Hopefully the changes we done resolved the issue.

Version: BIG-IP 11.6.0 Build 1.0.403 Hotfix HF1

1. Set the virtual server - Default Persistence Profile to "cookie"
2. Add as well i-Rule JSession script below and set timeout to 60secs.

when HTTP_REQUEST { if { [HTTP::cookie "JSESSIONID"] ne "" }{ persist uie [string tolower [HTTP::cookie "JSESSIONID"]] 60 } }

when HTTP_RESPONSE { if { [HTTP::cookie "JSESSIONID"] ne "" }{ persist add uie [string tolower [HTTP::cookie "JSESSIONID"]] secs. } }

1. Logon to the application server (HTTP Server) via browser (Internet Explorer).
2. Monitor the persistence records and found to be deleted after 60secs.
3. Connection to the HTTP Server automatically logout.

Great if it works, but you're basically using two different persistence mechanisms, and I'm guessing the default cookie method is the one being honored. But again, I think we're talking about different things here. The persistence profiles are used to control server affinity in a load balanced environment - making sure that a client request is sent to the same server every time. There are a lot of ways to do this, including the default cookie persistence which generates a cookie from the BIG-IP to the client, and the "universal" persistence option that allows you to write an iRule that controls affinity based on something in the client request (ie. the JSESSIONID cookie from the server). And then there's application session management. Separate from affinity, this is how an application knows that a new HTTP request is coming from an existing user "session". This has absolutely nothing to do with server load balancing affinity, but obviously affinity helps session management work since you generally need to get that server session cookie back to the same server.

Ultimately though, if you're trying to control the expiration of an application session, the load balancing persistence function is not generally going to help with that. If you kill the server affinity session/cookie, then the load balancer just load balances to a new server. You need to control the application session cookie (ie. JSESSIONID), and most likely you want to delete it when the user logs out. If you can do that from the application itself that's probably best, but you can certainly delete a client's cookies from the BIG-IP with an iRule assuming you have something unique to trigger that function (like a unique logout URI).

Hi Kevin,

I get your point persistence mechanisms. It seems that we are just mitigating the issue and just killing the server's affinity session/cookie wherein the result is disconnection/auto-logout of the users then it will just go to another available server.

thanks Ryan