LB::reselect from SERVER_DATA doesn't work

LB::reselect only works in request context. Once you have gotten to HTTP_response you are outside the context where a reselect is allowed.

 

 

Please take a look at 9.4 passive health monitoring to see if you can craft an iRule around the response in that context. I do not know if you will get what you want, but you will get closer.

 

 

That's what I was afraid of. I'm not sure what you mean by passive health monitor. Is this something I can put in the iRule? If so, perfect. If not, i need something more. Here's the scenario. We have several thousand clients, all of varying degrees of weight, that connect to our services. Each server has a finite capacity of, let's say, 100. As clients come in, their weight gets decremented, by the server from this 100. Now let's say a particular server has capacity of 20 left but the LB attempts to direct a client with a weight of 30 to it. I want the server to basically deny my request, forcing the LB to select a new pool member. We own the server software source code, so we can make it behave however we want. What would happen if the server didn't respond at all? How would the 'pool' command deal with that internally? If it realizes the TCP session wasn't fully established and does it's own reselect, that would be good enough. I could definitely work with that.

 

 

Thanks.

 

 

Regards,

 

Dave

 

Robert,

 

Does passive monitoring only works with HTTP?

 

How about TCP?

 

If passive monitoring does not support TCP. Can a TCP monitor mark down a node and pass that node status to an iRule in a high concurrency connection (3000) environment?

 

thanks in advance.

 

 

Tamin

 

 

 

Take a look at LB::detach http://devcentral.f5.com/wiki/default.aspx/iRules/LB__detach.html . I think it will do what you need in that 'context.'

 

 

The documentation is a little sparse on exactly what events it's usable during...

Thanks. Will an LB::detach force a reselect to happen?

 

 

Dave