Forum Discussion
Juha__Ranta_106
Nimbostratus
NimbostratusAny way to keep some values over different connections; how about fail-over?
Hi,
I need to maintain some iRule variable values over different connections.
I have managed to do this using Tcl global variables and now I would like to know more about 'session' commands:
Q1 : what is the difference between different session command 'modes' ?
mode := simple|sticky|uie|universal|...
Q2 : what is the default value for 'timeout', what if no 'timeout' parameter is given?
Q3 : how can i replace the value of existing key in 'session' table?
Q4 : Is it somehow possible to mirror these 'session' values between 'Active' and 'Standby' unit?
Q5 : And one more about Tcl 'global' variables. Is it somehow possible to define 'rule global' variables. Thus variables that would maintain their values between different connections but would be visible only within one iRule? (I would not like to pollute Tcl runtime with global variables)
-----
I tried to store some information between different connections using command
session add uie $mykey $myvalue $timeout
(mykey = string value, myvalue = string value, timeout = 3600)
and later retrieve these same value using
set storedvalue [session lookup uie $mykey]
... well, ...
I managed to retrieve the value previously stored value (on separate connection) but I was unable to replace the existing value.
I also tried to do 'session delete uie $mykey' before adding new values (under the same key) but that did not work either.
----
SEE ALSO:
1. Subject: Any way to keep same valuable over different connections?
http://devcentral.f5.com/default.aspx?tabid=28&view=topic&forumid=5&postid=1674 Click here
2. Subject: Concurrent connection limit
http://devcentral.f5.com/default.aspx?tabid=28&view=topic&forumid=5&postid=1990 Click here
----
Thanks in advance
- juha -
- Q1 : what is the difference between different session command 'modes' ?
This simply specifies the type of the "key". Different modes treat the key differently. For example, srcaddr and destaddr treat the key as an IP address use it to index into the session table differently than UIE which treats the key simply as a string.
Q2 : what is the default value for 'timeout', what if no 'timeout' parameter is given?
The default turns out to be the value of the default persist setting on the virtual or 180 if none is present on the virtual.
Q3 : how can i replace the value of existing key in 'session' table?
session add will do a replace if it already exists.
Q4 : Is it somehow possible to mirror these 'session' values between 'Active' and 'Standby' unit?
No, not currently though we have an open CR to add this functionality.
Q5 : And one more about Tcl 'global' variables. Is it somehow possible to define 'rule global' variables. Thus variables that would maintain their values between different connections but would be visible only within one iRule? (I would not like to pollute Tcl runtime with global variables)
You could always declare your own namespace for these variables. For example, if your rule was called "MyRule", then you could simply name all your global variables MyRule::myVar. This would not prevent access from other rules, but it would help keep from polluting the namespace (for example, if two rules both wanted to use a global variable called myVar).
I thought I had an example of replacing a session entry somewhere on this site... - CR40920
qqdixf5_74186We are on v10. I would like to create a namespace and declare some variables under it. So something like this:
set newNameSpace::myVariable "test"
this gives an error:
can't set "newNameSpace::myVariable ": parent namespace doesn't exist while executing "set newNameSpace::myVariable "test""
Do I need to declare the namespace first? How can I do that?
Thanks!- You would do this via the namespace command, but it is disabled in iRules, so there's no way to do it. You could do something like "myNameSpace_myVar" instead.
Are you trying to use this for global variables? Since you are on v10, you can use the session command to keep global data and keep CMP compatibility. There are some planned enhancements to make things like this easier.
