Forum Discussion

wilcdr's avatar
wilcdr
Icon for Nimbostratus rankNimbostratus
Aug 14, 2019

Force iRule to update on existing connections?

Hi,

 

When we have a VIP that has an iRule associated with it, and we update the code of the iRule (or even disassociate the iRule from the VIP), existing connections keep the old iRule still as per its caching strategy. The trouble in our system is that most of our stuff is connection pooled everywhere, so every time we make a change, we end up having to restart our many applications to effectively clean up the pooled connections so we can test changes and such.

 

Is there a way to do any of the following instead? We couldn't find anything in the docs pointing out what can be done here. We are on 12.x

 

1) Issue a command to force every existing connection to re-read the config, whether it is a code change in the iRule or the list of iRule associated is different now, it will then apply it? We don't think this would be possible given it would be difficult to know when it is safe to update, but thought we'll throw this in the list.

2) Make the iRule so it can read some external thing for its "code" and have a variable we can use to control whether it should then refresh this or not?

3) Can we use either the LB::detach or OneConnect::detach command (we always have a OneConnect profile attached in our case)? We did a quick test but it doesn't seem to be working, and we *think* it's because the detach command doesn't actually drop the connections but just disassociate the clientside from the serverside. But maybe something similar can work?

4) Some way of telling the VIP to gracefully drop all existing connections (in our case these would be HTTP VIPs so perhaps after the current request/response is done) and establish new ones for subsequent requests?

 

We appreciate other ideas on this also if others have workaround for this.

 

Thanks!

 

Wilson

  • JG's avatar
    JG
    Icon for Cumulonimbus rankCumulonimbus

    If you really need this, you can try the following irule:

    when HTTP_RESPONSE {
        ....
        HTTP::close
        TCP::close
    }

    , but you lose performance. Also an irule is not meant for frequent changes to itself.