Active connections still directed to disabled pool node
We have an https pool where we use a custom health monitor with the receive disable string looking for a 503. The ideal action is that if the monitor gets a 503 from one of the pool members, that pool member will no longer be used. However, we are noticing that users with previously established connections to that pool member continue to be directed to it due to persistence (despite the node being disabled). We have the "action on service down" for the pool set to "reject" but any users with established connections continue to be directed to the disable pool member where they get 503 errors. Are we missing something? Is there some way to force the node offline instead of disabling it?
Does tcp wait recycle function on disabled pool nodes?
Hi, I have some app devs who are taking down their nodes automatically when deploying new code. The idea is they take a node down, verify no connections to the server, deploy code and bring the node up. Rinse and repeat for each node in the LTM pool. They're running into prolonged connections after disabling the pool node. We've tried setting action on service down to "Reselect", but that doesn't seem to work. No persistence is used on the VIP but connections continue to persist to the disabled node. The one thing I'm assuming but haven't been able to backup with credible confirmation is that the TCP profile using tcp wait recycle isn't a culprit. I'm assuming that the F5 won't recycle connections in a time-wait state if the node is in a disabled state, but I don't see any documentation stating this is the case. Am I correct in my assumption? Or can the tcp wait recycle need to be disabled for this to work properly so that the F5 is keeping a connection open allowing new connections to reuse a connection that was in time-wait? I'm assuming the client or server is keeping this connection open, but want to make sure this isn't the F5 somehow responsible for keeping the connection open.
Action on service Down : Reselect
we have configured Standard type Virtual server with HTTP profile and have enabled Persistence profile Source Add, Pool is load balanced by Least connection(member) we are facing issue regarding client was sending to the the partition with become down so to tackle this we selected Re-select Option on Active Service Down. With this Option we are receiving another complain of automatic logout and error message 500. Application is running on TCP.
Is "Action on Service Down - Reselect" ever safe for HTTP virtual servers? E.g., stateless transactions
I've been living the dream, learning about "Reselect Tries" and "Action on Service Down" ... We have web service interfaces that are stateless, from an HTTP perspective - no session is created on the web server side, etc. The goal is to have such calls never fail, as long as one web server (pool member) is up. Setting "Reselect Tries" > 0 accomplishes that for new connections - just looking to do the same for existing connections. Have been looking at "Action on Service Down" - but one thing I can't find clarified is, is a setting of "Reselect" ever safe for a Layer 7 HTTP virtual server? For example, if you know for a fact that your web servers are stateless (no user session involved on the server side, or all user state is written back to the client as cookies), then can reselect be safely used? I'm concerned about a race condition related to HTTP transactions that span multiple packets ... perhaps it's only safe if you know that all transactions will fit in a single packet? If it is safe under those constrained circumstances, is there any configuration guidance to be aware of? E.g., is it necessary to avoid use of a OneConnect or something? If it's not safe, can you explain why, where it breaks things? And, is there any approach that will accomplish what I've described? (maybe, some way to config so that every single transaction is treated like a completely new connection?) thx! We're on 11.5.2, if it's relevant.