SPDY/HTTP2 Profile Impact on Variable Use

Kai,

I didn't realize you meant for there to be additional iRule logic to determine the owning TMM. It does make the

table -subtable

a more palatable option if lookups were guaranteed to be local.

There are some cons to OneConnect, but reverting back to the default pool for every request is something I prefer. I have submitted RFEs to address some things I don't like and have several other features I'd like to see added, but haven't taken the time to submit those yet. Overall, in my experience OneConnect has helped far more often than not.

Maybe it's the original topic that bugs me, or I'm just in a feature request mood because this discussion sparked a few other features ideas:

1. TMM::hash Description

Command used to hash a value to calculate the owning TMM.

Syntax -

TMM::hash  

TMM::hash table 

TMM::hash table -subtable 

TMM::hash persist uie 

TMM::hash persist source_addr 

etc.

That would greatly simplify the process of determining the owning TMM instance. It would likely incur little CPU overhead and probably not too complicated to develop. It wouldn't be the most used command, but I would have found it useful on a few occassions. I could see it coming in handy for testing and troubleshooting.

2. New

table

command

What about an additional

table

command that is TMM specific, maybe

table_local

or preferably something shorter and more catchy. It would be similar to

static

variables, but with all the features of

table

which would be ideal for storing the default pool. It may be useful in other situations too.

3. New Variable Scope

One of your earlier comments you mentioned possibly using something like

uplevel

or

upvar

to get at variables at the connection level. I tried every way I could, but unless there is some sort of secret command, I don't believe it is possible. As I mentioned, it's like each concurrent HTTP2 session is its own connection. I would propose adding an additional variable scope, similar to

static

, but specific to connections. Something like

conn

,

client

or

session

.

It would be used something like this.

when CLIENT_ACCEPTED {
    set conn::default_pool [LB::server pool]
}
when HTTP_REQUEST {
    if {[HTTP2::active]} {
        log local0. "default pool is ${conn::default_pool}"
    }
}

I did do some testing a while back to get a little understanding of the variable scope in HTTP2. I did something like this:

when CLIENT_ACCEPTED {
    set CA "client accepted variable"
}
when HTTP_REQUEST {
    set REQ "HTTP request variable"
    if {[catch {log local0. "client accepted variable $CA"}] != 0} {
        log local0. "outside the Client Accepted scope"
    }
}
when SERVER_CONNECTED {
    set SC "server connected variable"
    if {[catch {log local0. "HTTP request variable $REQ"}] != 0} {
        log local0. "outside the HTTP Request scope"
    }
    if {[catch {log local0. "client accepted variable $CA"}] != 0} {
        log local0. "outside the Client Accepted scope"
    }
}
when HTTP_RESPONSE {
    if {[catch {log local0. "HTTP request variable $REQ"}] != 0} {
        log local0. "outside the HTTP Request scope"
    }
    if {[catch {log local0. "client accepted variable $CA"}] != 0} {
        log local0. "outside the Client Accepted scope"
    }
    if {[catch {log local0. "server connected variable $SC"}] != 0} {
        log local0. "outside the Server Connected scope"
    }
}
when CLIENT_CLOSED {
    if {[catch {log local0. "HTTP request variable $REQ"}] != 0} {
        log local0. "outside the HTTP Request scope"
    }
    if {[catch {log local0. "client accepted variable $CA"}] != 0} {
        log local0. "outside the Client Accepted scope"
    }
    if {[catch {log local0. "server connected variable $SC"}] != 0} {
        log local0. "outside the Server Connected scope"
    }
}

I found

CLIENT_ACCEPTED

and

CLIENT_CLOSED

shared a variable scope separate from everything else. Before testing, I half expected

SERVER_CONNECTED

to share scope with

CLIENT_ACCEPTED

, but I was wrong.

If I was give the power to pick a new feature, but I could choose only one, it would be the

conn

variable scope. At least for the purpose of this discussion.