Problem with persistence

That could explain it.

 

 

We can have multiple clients who can connect with the same uid value, and they should all go to the same server. The code you have there looks like it'll do the add for each individual client, instead of just once for that specific value. Will the add call have any problems if it's already in the table, or will it just ignore it? Is there a way to only do that add if the uid isn't already there instead of once per client (again, I may be misinterpreting things)

Hmm...not sure if it's possible (or how) to compare values that are already in the table...

 

 

As long as it's adding the same record I wouldn't see a problem with that, but that's probably not as efficient as one would hope.

 

 

Denny

As long as it doesn't reset the persistence (change the server it points to) then it should be fine.

 

 

Looks like the persist function has a get method. I could probably use that to query to see if the uid is already in the table and if so just skip it, but I'm not sure what the format of the returned stuff is (how to tell if there's no value or not). I'm guessing just checking if it is equal to "" would be enough. Does anyone know?

It doesn't seem to like the

persist add uie $uid

call. I'm getting the following error in the log:

 

 

TCL error: Rule UID_Persist - Prerequisite operation not in progress (line 1) invoked from within "persist add uie $uid"

 

 

Can anyone help me out here? I have no idea what that error means.

 

 

Here's the iRule code I currently have:

 

 

when CLIENT_ACCEPTED {
  set add_persist 1
}
when HTTP_REQUEST {
  set fulluri [HTTP::uri]
  set uid [findstr [HTTP::uri] "uid=" 5 "&"]
  if { $uid != "" } {
    if { $add_persist } {
      log local0. "Adding persist value to table: $uid | $fulluri"
      persist add uie $uid
      set add_persist 0
    }
    else {
      log local0. "Set persist value to uid: $uid  | $fulluri"
      persist uie $uid
    }
  }
  else {
    log local0. "No uid found in HTTP REQUEST  | $fulluri"
  }
}

I've only seen the persist add statement on the serverside events.

From my experience, the general idea seems to be:

 

1) there must be a response event in which the persistence value is extracted from the response to create the persistence record;

 

and

 

2) there must be a request event in which the persistence value submitted in each request is compared to the persistence table

 

3) a rule containing that logic must be applied within a persistence profile, rather than applied directly to the virutal as a resource.

 

 

The error you're getting /may/ be caused by applying the rule directly to the virtual. Try applying the rule to a persistence profile instead, then apply the persistence profile to the virtual.

 

 

The persistence profile will manage the timeout of the record, so from what I understand you need to re-add the persistence record on each response to prevent the record from timing out on an active session.

 

 

Here's an example of the rule structure and the placement of the 2 "persist" commands: Click here

 

 

The same persistence record may be shared by multiple clients submitting a persistence token with the same value. Persistence record looks something like "persist_value pool_member", so any request coming in with that persistence value will use that node.

 

 

HTH

 

/deb

The persistence value isn't generated in a response. The persistence value is part of all connections to the server, including the very first one.

Also, you're saying the timeout for the persistence value is a timeout on when it was added? I thought it was a timeout on when it was last accessed, so just doing the

persist uie $uid

should restart it.

Not sure about the applying to virtual vs persistence profile. I believe it's applied to the profile, but I'm not sure (I'm not the one doing the configuration, just the one writing the iRules).

I changed the iRule to do the add in the response. According to the logs it's adding the correct value, but it's happening every time someone connects (which might be ok, I'm not sure). Unfortunately, the persistence still isn't working. The connections with the same uid are going to different servers.

I did verify that the iRule is applied to the persistence profile, so that part at least is correct.

Any ideas why it wouldn't be persisting? Is there anything else I might be missing?

Here's the current iRule I'm using:

when HTTP_REQUEST {
  set fulluri [HTTP::uri]
  set uid [findstr [HTTP::uri] "uid=" 5 "&"]
  if { $uid != "" } {
    log local0. "Set persist value to uid: $uid  | $fulluri"
    persist uie $uid
  }
  else {
    log local0. "No uid found in HTTP REQUEST  | $fulluri"
  }
}
when HTTP_RESPONSE {
  if { $uid != "" } {
    log local0. "Adding persist value to table: $uid"
    persist add uie $uid
  }
}

Try using the CLIENT_ACCEPTED event that I used earlier to limit the addition of a record to the first connection.

Also because you aren't setting $uid in the HTTP_RESPONSE event, I don't think anything's getting added, and you're seeing the log from the HTTP_REQUEST event.

I don't think order matters, but it might make it easier to see the logic if you move the response event before the request event, since it's on the first response that you want to set the persist record.

when CLIENT_ACCEPTED {
  set add_persist 1
when HTTP_RESPONSE {
   set uid [findstr [HTTP::uri] "uid=" 5 "&"]
   if { $uid != "" and $add_persist} {
   log local0. "Adding persist value to table: $uid"
   persist add uie $uid
   set add_persist 0
}
when HTTP_REQUEST {
   set fulluri [HTTP::uri]
   set uid [findstr [HTTP::uri] "uid=" 5 "&"]
   if { $uid != "" } {
   log local0. "Using persist value uid: $uid | $fulluri"
   persist uie $uid
  } else {
     log local0. "No uid found in HTTP REQUEST | $fulluri"
  }
}

This still may not help with the fact that you said you have different clients using the same uid however.

Denny

The value for $uid was still in scope during the HTTP_RESPONSE message, so it had the correct value (same reason the add_persist value keeps it's value of 1 between CLIENT_ACCEPTED and HTTP_REQUEST). The logging messages I put in place verified this.

 

 

Also, the CLIENT_ACCEPTED stuff wouldn't really work for my case as we can have multiple clients using the same $uid (the uid indicates an application instance, and that application can be shared between users).

 

 

Actually, I'm going to take a few steps back, going back to the original iRule. When using this iRule we *are* seeing the persistence table records created correctly, so it looks like just doing the `persist uie $uid` call is adding it to the table correctly. While monitoring it the persistence values themselves are correct, but BIG-IP doesn't seem to be honoring it. The persistence is set up, but it's doesn't seem to be affecting the connections.