wlnode function

Here is what I have developed so far as way to persist based on the issued JSESSIONID:

 
 rule WeblogicJSessionPersist {  
   when HTTP_RESPONSE {  
     set key [HTTP::cookie "JSESSIONID"]  
     set value [IP::server_addr]:[TCP::server_port]  
    
     if {$key != ""} {  
        log local0. "Adding jsess of: $key, value of: $value"  
        session add uie $key $value  
    
        set value2 [session lookup uie $key]  
        log local0. "Re-looking up key: $key, provides value: $value2"  
     }  
   }  
   when HTTP_REQUEST {  
     set jsess [findstr [HTTP::uri] "jsessionid" 11 ;]  
     log local0. "Entering REQUEST, jsess is: $jsess"  
    
     if { $jsess != "" } {  
        set server [session lookup uie $jsess]  
        log local0. "Server IP is: $server"  
    
        if { $server != "" } {  
           pool Weblogic_HTTP_Pool member $server  
        }  
     }  
   }  
 } 
 

I know it's not the most efficient way of doing the job, but the limited testing I have done so far seems to indicate that it's a good start. Any suggestions for making this work in a more streamlined manner would be much appreciated.

I don't see that you're using value2, was this just for error checking while building the rule?

 

 

This is very cool, I was just approached about this ability. Thanks for posting.

 

 

Jason

This is an interesting rule. The interesting aspect of it is that you have re-implemented persistence using the session table. Way to go.

However, a slightly simpler approach may be to just do the following with persistence:

  
  rule WeblogicJSessionPersist {  
     when HTTP_RESPONSE {  
        if { [HTTP::cookie exists "JSESSIONID"] } {  
           persist add uie [HTTP::cookie "JSESSIONID"]  
        }  
     }   
     when HTTP_REQUEST {  
        set jsess [findstr [HTTP::uri] "jsessionid" 11 ";"]  
        if { $jsess != "" } {  
           persist uie $jsess  
        }  
     }  
  }  
  

On another note, to be more complete, you may want to check for a client cookie and only use the uri query string if the cookie isn't present. Here is an update:

    
 rule WeblogicJSessionPersist {   
    when CLIENT_ACCEPTED {   
       set add_persist 1   
    }   
    when HTTP_RESPONSE {    
       if { [HTTP::cookie exists "JSESSIONID"] and $add_persist } {    
          persist add uie [HTTP::cookie "JSESSIONID"]   
          set add_persist 0   
       }    
    }    
    when HTTP_REQUEST {    
       if { [HTTP::cookie exists "JSESSIONID"] } {    
          persist uie [HTTP::cookie "JSESSIONID"]    
       } else {    
          set jsess [findstr [HTTP::uri] "jsessionid" 11 ";"]    
          if { $jsess != "" } {    
             persist uie $jsess    
          }    
       }    
    }    
 }    
 

I'm not totally sure this is what you want to do, but it potentially makes sense to me. You may also want to reverse the order, as in, look for the uri query string and use that first and then fallback to the cookie.

Let us all know how it turns out. I'm sure there's a few people that would like to know whether this works great.

Does BigIP purge the persistence table of entries to servers that have been marked down, or would this validation need to be checked in the iRule before persisting?

Well, sort of...

 

 

When a node gets marked down, the persistence entries referring to it are not actually purged. However, when a persist entry that refers to the down node gets accessed, it is then discarded and replaced with a newly load-balanced node.

 

 

So, the short answer to your question is that no, they are not purged, however, it's not necessary to add that logic to the rule because that logic is already done in the persistence picking code.

 

We are finally getting around to inserting bigip into the application tier between our web and app servers. We will be utilizing a similar rule to above, but I also need to replace and remove some headers. Is it better to include that in this rule, or attach another rule with that logic? Which logic should come first, or does it matter if the values being set are not the same within the HTTP_REQUEST event?

I am trying to use a similar rule to persist to weblogic servers based on the jsession id; here is my rule

when HTTP_RESPONSE {
       set key [HTTP::cookie "JSESSIONID"]
       set value [IP::server_addr]:[TCP::server_port]
       if {$key != ""} {
          log local0. "Adding jsess of: $key, value of: $value"
          session add uie $key $value
          set value2 [session lookup uie $key]
          log local0. "Re-looking up key: $key, provides value: $value2"
       }
     }
     when HTTP_REQUEST {
       set jsess [findstr [HTTP::uri] "jsessionid" 11 ;]
       log local0. "Entering REQUEST, jsess is: $jsess"
       if { $jsess != "" } {
          set server [session lookup uie $jsess]
          log local0. "Server IP is: $server"
          if { $server != "" } {
             pool pool_weblogic_pool_http member $server
          }
       }
     }

I am having an issue where I am consistenly presented with a "We're sorry but your session has timed out" error presented by the app/web server

here is what my ltm log says

***** BEGIN LOG*********************

Nov 5 13:57:09 tmm tmm[16895]: Rule rule_jsession_persistence-2 : Entering REQUEST, jsess is:

Nov 5 13:57:09 tmm tmm[16895]: Rule rule_jsession_persistence-2 : Entering REQUEST, jsess is:

Nov 5 13:57:09 tmm tmm[16895]: Rule rule_jsession_persistence-2 : Adding jsess of: CgVcFTBSfrKkbxP14

6B2wv5jfGSxtcRvGsv9rz6DcFlhvg9s11lk!-267782270, value of: 10.1.1.22:11080

Nov 5 13:57:09 tmm tmm[16895]: Rule rule_jsession_persistence-2 : Re-looking up key: CgVcFTBSfrKkbxP

146B2wv5jfGSxtcRvGsv9rz6DcFlhvg9s11lk!-267782270, provides value: 10.1.1.22:11080

***** END LOG*********************

Can someone help be figure out what I am missing here?

I have just been informed that we need to persist on anyone of about 5 cookies that come from the weblogic servers; I found out that the reason I was not persisting, was the client is presenting one of the other cookies on about the 4th HTTP GET request; I am searching this forum now for persisting on multiple cookies. If anyone knows how to do this I would appreciate the help.

What would be really interesting is to figure out if the client browser doesn't accept the cookie, to write the JSessionID to the URL as part of the query string. There are folks that turn off cookies in their browser, so in this instance, how could we ensure they persist to the same SessionID but not in the browser, in the URL. You capture this in the HTTP_REQUEST portion of the code, where you set the jsess variable, which it looks for the ID in the URL, question is, how does it get there?

 

 

I know weblogic I believe at times will default the ID to the URL if it knows the browser blocks it, in which case you'd see that jsess findstr work great, but what about other servlet engines like JBoss?

 

 

I'm going to play around with this iRule and see if I can figure out how to force it into the URL, just to see if it's possible (meaning, the client denies the cookie, so default to the URL).