JSessionID URI Persist

Hi,

 

 

Can you check the entry in your persitence table ? you can do it through the GUI in Statistics > Persistence records (last one in the list of statistics available)

 

 

Do you see duplicate entries for the same jsession ID?

 

 

Your iRules seems definitely fine

 

 

The weird thing is that I never see any records for jsessionid in the table. I have confirmed that the rule is running since it is logging to my syslog server.

 

 

I also can see that it finds the jsessionid. I am really struggle to understand why the LTM doesn't seem to care about the persist.

Can you try this:

 
 when HTTP_REQUEST {    
   if { [HTTP::uri] contains "/mosAppWar" }{    
       set jsess [findstr [HTTP::uri] "jsessionid" 11 ";"]    
       if { $jsess ne "" } {    
         log local0. "creating persistency with $jsess" 
          persist uie $jsess    
       } 
       pool Application_Pool    
       log local0. "QA2 Server: [LB::server addr] jsessionid $jsess Query: [HTTP::uri][HTTP::query]"    
       return     
     } else {    
       pool Static_Pool    
       return    
      }    
  }   
 

And please provide the output. It really looks like it doesn't trigger the persist command

Thanks

I have changed my IRULE and also have the output (See attachment).

 

 

It still doesn't seem to work but I did find an interesting command to show the persistent values and have noticed that something doesn't look right with them. Maybe I am not grabbing the JSessionID from the URI in the right way.

 

 

I can see the JSessionID changing as it roams from one server to another (which it shouldn't do) It looks like it is grabbing more then the JSessionID!

 

 

bigpipe persist show all

 

PERSISTENT CONNECTIONS

 

| Mode universal Value 1A4B803633E1072A1602.0

 

| virtual 172.20.10.99:https node 10.70.10.84:8180 age 30sec

 

| Mode universal Value 1A4B803633E1072A1602.2?pgIWorkQueue_btProceed=

 

| virtual 172.20.10.99:https node 172.20.10.61:http age 92sec

 

| Mode universal Value 1A4B803633E1072A1602.2?pgIWorkQueue_btProceed=

 

| virtual 172.20.10.99:https node 10.70.10.78:8180 age 99sec

 

| Mode universal Value 1A4B803633E1072A1602.1?pgSignOn_btActMsg=CONFIRM_NEW_SESSION,6

 

| virtual 172.20.10.99:https node 172.20.10.61:http age 119sec

 

| Mode universal Value 1A4B803633E1072A1602.1?pgSignOn_btActMsg=CONFIRM_NEW_SESSION,6

 

| virtual 172.20.10.99:https node 10.70.10.84:8180 age 119sec

 

| Mode universal Value 1A4B803633E1072A1602.0?pgSignOn_btSubmit=

 

| virtual 172.20.10.99:https node 172.20.10.60:http age 119sec

 

| Mode universal Value 1A4B803633E1072A1602.0?pgSignOn_btSubmit=

 

| virtual 172.20.10.99:https node 10.70.10.81:8180 age 121sec

 

 

it seems like your ending caracter for the findstr command may be ? or ;

 

 

Since you have a "." in your jsession id couldn't you try the following:

 

 

Replace : [findstr [HTTP::uri] "jsessionid" 11 ";"] with [findstr [HTTP::uri] "jsessionid" 11 "."]

 

 

It should be fine with this

It looks like the findstr isn't set correctly. Can you add a new log line of just the URI or just reply with a few examples?

 

 

Thanks,

 

Aaron

Even though it looks better. I am still not completely sure it is working right.

 

 

This is a common user session.

 

1. Login

 

2. Your user is already logged in.

 

3. Press Ok to start new session

 

4. Random clicking in web application

 

 

Sep 5 10:15:30 tmm tmm[1599]: Rule Logic-v4 : URI: /mosAppWar/MosSystem/pgSignOn

 

Sep 5 10:15:53 tmm tmm[1599]: Rule Logic-v4 : URI: /mosAppWar/MosSystem/pgSignOn;jsessionid=23778039FC531A4BEC4A.2?pgSignOn_btSubmit=pgSignOn_btSubmit=

 

Sep 5 10:15:55 tmm tmm[1599]: Rule Logic-v4 : URI: /mosAppWar/MosSystem/pgSignOn;jsessionid=23778039FC531A4BEC4A.0?pgSignOn_btActMsg=CONFIRM_NEW_SESSION,6pgSignOn_btActMsg=CONFIRM_NEW_SESSION,6

 

Sep 5 10:16:07 tmm tmm[1599]: Rule Logic-v4 : URI: /mosAppWar/MosSystem/pgIWorkQueue;jsessionid=23778039FC531A4BEC4A.0?pgIWorkQueue_btProceed=pgIWorkQueue_btProceed=

 

Sep 5 10:16:11 tmm tmm[1599]: Rule Logic-v4 : URI: /mosAppWar/MosSystem/pgIWorkQueue;jsessionid=23778039FC531A4BEC4A.0?pgIWorkQueue_btProceed=pgIWorkQueue_btProceed=

 

Sep 5 10:16:19 tmm tmm[1599]: Rule Logic-v4 : URI: /mosAppWar/MosSystem/pgSourceofBusSearch;jsessionid=23778039FC531A4BEC4A.0?pgSourceofBusSearch_btProceed=pgSourceofBusSearch_btProceed=

 

Sep 5 10:16:33 tmm tmm[1599]: Rule Logic-v4 : URI: /mosAppWar/MosSystem/pgSourceofBusSearch;jsessionid=23778039FC531A4BEC4A.0?pgSourceofBusSearch_btProceed=pgSourceofBusSearch_btProceed=

 

Sep 5 10:16:36 tmm tmm[1599]: Rule Logic-v4 : URI: /mosAppWar/MosSystem/pgSourceofBusSearch;jsessionid=23778039FC531A4BEC4A.0?pgSourceofBusSearch_btProceed=pgSourceofBusSearch_btProceed=

 

Sep 5 10:16:39 tmm tmm[1599]: Rule Logic-v4 : URI: /mosAppWar/mosApp/JavaScript/rc/json.jspgSourceofBusSearch_btProceed=

 

Sep 5 10:16:39 tmm tmm[1599]: Rule Logic-v4 : URI: /mosAppWar/mosApp/JavaScript/rc/filogix.jspgSourceofBusSearch_btProceed=

 

Sep 5 10:16:39 tmm tmm[1599]: Rule Logic-v4 : URI: /mosAppWar/mosApp/JavaScript/rc/LenderProductRate.jspgSourceofBusSearch_btProceed=

 

Sep 5 10:16:39 tmm tmm[1599]: Rule Logic-v4 : URI: /mosAppWar/MosSystem/AJAXDispatching;jsessionid=23778039FC531A4BEC4A.0pgSourceofBusSearch_btProceed=loadtarget

 

Sep 5 10:16:39 tmm tmm[1599]: Rule Logic-v4 : URI: /mosAppWar/MosSystem/AJAXDispatching;jsessionid=23778039FC531A4BEC4A.0pgSourceofBusSearch_btProceed=loadtarget

 

Sep 5 10:16:39 tmm tmm[1599]: Rule Logic-v4 : URI: /mosAppWar/MosSystem/AJAXDispatching;jsessionid=23778039FC531A4BEC4A.0pgSourceofBusSearch_btProceed=loadtarget

 

Sep 5 10:16:40 tmm tmm[1599]: Rule Logic-v4 : URI: /mosAppWar/MosSystem/AJAXDispatching;jsessionid=23778039FC531A4BEC4A.0pgSourceofBusSearch_btProceed=loadtarget

 

Sep 5 10:16:40 tmm tmm[1599]: Rule Logic-v4 : URI: /mosAppWar/MosSystem/AJAXDispatching;jsessionid=23778039FC531A4BEC4A.0pgSourceofBusSearch_btProceed=loadtarget

 

Sep 5 10:16:40 tmm tmm[1599]: Rule Logic-v4 : URI: /mosAppWar/MosSystem/AJAXDispatching;jsessionid=23778039FC531A4BEC4A.0pgSourceofBusSearch_btProceed=loadtarget

Would the fact that some requests have no JSessionID mess UIE up? even though these types of requests don't need persistence?

 

 

i.e.

 

 

Sep 5 10:16:39 tmm tmm[1599]: Rule CIBC_Express_Logic-v4 : URI: /mosAppWar/mosApp/JavaScript/rc/filogix.jspgSourceofBusSearch_btProceed=

it shouldn't messed up the application, why do you say you're not sure it's completely right ?

Some of the entries in the table were showing uri instead of jsessionid. I think that is because of the the application doesn't use jsessionids. I have improved the code to keep the LTM from adding the bad entries to the table.

 

 

Below is my code at this point. I have a tester looking into it now to see if it is working.

 

 

when HTTP_REQUEST {    
   if { [HTTP::uri] contains "/mosAppWar" }{    
        Make jsess equal the jsessionid
   set jsess [findstr [HTTP::uri] "jsessionid" 11 "."]    
       Make sure that jsessionid is actually there since some requests don't have one.
  if {[HTTP::uri] matches_regex {jsessionid} } {
      Make sure jsessionid is not blank before adding it to the UIE.   
   if { $jsess ne "" } {    
                 Commit the record to the LTM database for 5400 seconds.
 persist uie $jsess 5400   
                } 
        }   
        Since it is /mosAppWar send the host to the application pool.
   pool CIBC_Express_Application_Pool    
       log local0. "QA2 Server: [LB::server addr] jsessionid $jsess Query: [HTTP::uri][HTTP::query]"    
       log local0. "URI: [HTTP::uri][HTTP::query]"
   return     
    
 Send all other requests to the static pool.
} else {    
       pool CIBC_Express_Static_Pool    
       return    
      }    
  }