Queuing traffic in iRules - advisability!!

Thanks Jason - that's an interesting suggestion and I'll look into it, but I just need clarification that even with 'after' now being a suspending command it's still not recommended running loops of 'after' statement?

Wouldn't the previous concerns from 2008 "iRule execution is single-threaded, so if you did somehow pause execution (like run a tight wait-loop as someone suggested), then you would be holding up all other packet processing. The multiple watchdogs on the LTM would notice this, and take appropriate action (restart tmm, or failover, or reboot, or some combination thereof)." be nullified now that 'after' is suspending?

I've done some medium-level testing where I've had 50+ queued connections all running the after loop and no watchdog processes kicked in, although perhaps I wasn't running enough traffic to trigger that behaviour.

Are there other concerns that I haven't taken into consideration?

suspending commands like after and RESOLV::lookup are parked outside the event loop so they do not harm them flow while waiting for actions to occur. For non-suspending commands, like while and for, everything gets stacked behind that bus. A while loop that cuts through 200 counts, really no big deal. However, we've seen people (and by people, I mean me before I was edumacated on this!) suggest or implement for loops that bleed for seconds or longer, and at some point daemons get involved and bad things happen.

Colin wrote up connection state & suspension concepts a while back, hopefully this will help.

Thanks for the update and the link.

So how does an 'after' within a 'while' loop get treated? Does each execution of the 'after' result in connection suspension? Or because the 'after' is being executed within the context of a blocking command (while), does it in itself become blocking?

Will the following code block solidly for up to 120s? Or will it suspend 600 times?

set i 1
while {[table lookup "mytable"] ne "" } {
    if {$i > 600} {
         Ensure a single request can never keep queuing beyond 600 iterations
        break
    }
    after 200
    incr i
}