One-Way Persistence records problem

One thing you may want to look into and test with to make sure it does not upset your application server is to set the expires options on the JSESSIOINID cookie, or better yet see if the application server can set it.

That way the only time a inbound request will have the cookie is when the cookie is still valid in the application server. It would mean a bit more logic in your iRule.

In HTTP_RESPONSE you would do something like:

if { [HTTP::cookie "JSESSIONID"] ne "" }{
         Set the cookie to expire 290 seconds from now.
        HTTP::cookie expires JSESSIONID 290 relative
         Persist off of the cookie value with a timeout of 4m50s to ensure that 
         the F5 will never send an expired cookie back to the application.
        persist add uie [HTTP::cookie "JSESSIONID"] 290
    }

You might have to experiment, I'm not 100% sure that the above example will add the expired information, you might have to save the value of the current JSESSSIONID cookie, delete the existing one and then insert the cookie.

I also took the "string tolower" out, this removes the overhead of converting the JSESSIONID to all lower case letters. So you will need to take it out of the HTTP_REQUEST section of code. It will also remove the possibility of having two JSESSIONID's that are different due to case (JSESSIOND=AbCd and JSESSIOND=aBcD) end up being used in a persistence record as the same because they are both converted to "abcd".

I used 290 seconds instead of 315. I personally think it is better for the browser and the F5 to timeout the cookie sooner than the back-end application. That way a request will never get back to the application with an expired JSESSIONID.

Again, if you can get the application server to set the expires date, that would be best then you only have to worry about the persistence record, but still set it just slightly less than the applications time.