Can an "after" job be referenced from a different context?
This is related to a previously un-answered question: https://devcentral.f5.com/questions/periodic-summary-logging-with-table-and-after. I'm trying to accomplish roughly the same thing, but I'm looking for a more specific answer. I'm trying to count the number of times a certain kind of request has been processed, then dump those counts every X seconds. Is it possible to reference an "after" ID that was registered in a different thread of execution? The docs don't explicitly state one way or the other: after info [ …] * Returns information about currently scheduled scripts, or about a specific . * Returns active timer ID(s) ( ...) for the current executing context (i.e., client, server). * If called without supplying or multiple s supplied, return value is TCL list. When I pass a after ID to "after info " that was registered in a different thread (The ID was saved to/retrieved from a session table), I get something like: TCL error: MY_IRULE - Invalid after ID: afterbf8f674 My code looks something like this: set count [ table incr "count_$tbl" ] set after_id [after info [table lookup -subtable ${static::prefix} -notouch count_monitor]] if { [ info exists after_id ]} { do nothing, don't log right now } else { set after_id [after 10000 { log local4.notice "prefix=${static::prefix} -- count=${count}" table delete "count_$tbl" }] table set -subtable ${static::prefix} count_monitor ${after_id} 120000 } When I run that code, it fails on the second line, trying to reference the "after info" by ID. If I log "[after info] by itself, it returns nothing. After some playing around, it appears that after IDs can't be referenced outside of the original context. Is there a way that they can be registered in such a way as to be able to access them from a different context? If not, is there a different (v10-compatible) way that I could achieve some sort of asynchronous "dumping and clearing" of session table data?
table and HA
Hi, I am pretty sure after reading SOLs and description of table command that keys stored via table or subtable on active unit should be mirrored to standby (for given traffic group). I just would like to confirm if it's indeed the case and if possible that it is reliable in production. Question is if we can assume that data stored on active unit will be available on standby and in case of failover we can assume that data will be exactly the same - so iRule logic based on table stored data will work as expected. What bothers me a bit is how exactly this is working in case of sub/table stored keys. I assume connection mirroring has to be configured and enabled. Next StateMirror.MirrorSessions db var should be set to enabled (but if I am not wrong it is enabled by default?). For TCP session mirroring it has to be enabled per VS (Connection Mirroring checked) - I assume that only session entries related to this VS are mirrored to standby - not whole session table? What about iRule created sub/table keys? All are mirrored by default? Even if VS with iRule has not Connection Mirroring checked? What if we have Active-Active HA? Let's say sub/table keys are created via iRule attached to VS belonging to Traffic Group (TG) 1 active on device A, connection mirroring is enabled so keys should be copied to device B being standby for TG1. Then there is VS on device B belonging to TG2 (active on device B). Keys in sub/tables are created via iRule attached to this VS - again those should be copied to device A being standby for TG2. From table cmd description I have such statement I am not sure about: If the table command is used on the standby system in a HA pair, the command will perform a no-op because the content of the standby unit's session db should be updated only through mirroring. What exactly "will perform no-op" means? It seems no modifications could be performed - sounds logical. But is that mean no lookup operations can be performed as well? I am just curious if iRule on VS in TG1 can read keys created by iRule on VS in TG2 - in other words if iRule in TG1 can read copy (as device A is standby for TG2) of sub/table keys created by iRule on TG2. Last question is about info from SOL13478 "Note: Only FastL4 and SNAT connections are re-mirrored after failback." - what fallback means here? It's related to automtic fallback option for TG or to situation like that as well: TG1 active on device A - TG1 moved to device B (any reason, session table should contain up to date entries on device B) - device A back online/available, so it should became standby for TG1, table keys should be mirrored from device B to device A - TG1 migrated to device A - table keys up to date - or it won't work like that? Piotr