SPDY/HTTP2 Profile Impact on Variable Use

Kai,

You are correct, the scenario would be a rare case. Generally it's not something I would even be concerned about myself, but because it is possible, it's good to know it could happen for that rare case.

I didn't think about coercing the F5 to assign a specific owning TMM for the subtable. I would be a little surprised if the TMM responsible for creating the subtable is always the TMM that owns the subtable. Is there a feature of subtables that allows the name of

table_hash_1

to using TMM 0 and

table_hash_2

to use TMM 1? I'm not even sure how to test the owning TMM for a

table

entry, at least not directly.

I would still shy away from

table

, static variables should accomplish the task. And if the purpose is to select a default pool like in this example iRule, I would still prefer OneConnect over attempting to store the default pool for later use.

when CLIENT_ACCEPTED {
    set static::default_pool([virtual name]) [LB::server pool]
}
when HTTP_REQUEST {
    switch -glob -- [HTTP::uri] {
        /images/    { pool image_pool }
        default     { pool $static::default_pool([virtual name]) }
    }
}

If it's desired to keep them cleaned up, contents could checked periodically with something like this.

when RULE_INIT {
    if {[array exists static::default_pool]} {
        foreach VS [array get static::default_pool] {
            log local0. "[lindex $VS 0]  [lindex $VS 1]"
        }
    } else {
        log local0. "default_pool array does not yet exist"
    }
}

Whenever loaded or updated, that rule would log each virtual and associated pool once per-TMM. One could even set an alertd event to trigger a script for these messages, though that may be a bit overkill. In my opinion it's not worth it, only 1 copy per-TMM of the array, even with hundreds of virtual servers it's not a significant memory concern.

New Feature Maybe?

I haven't written up an RFE for it yet, but if we could query the pool on the VS directly, we wouldn't have to rely on

table

or

static

variables to get the default pool. Maybe add a VS namespace (or whatever it's called) exposing some key config on the VS, similar to the

PROFILE

commands.

VS::pool

VS::rules

VS::type

VS::destination

etc.