Is "Action on Service Down - Reselect" ever safe for HTTP virtual servers? E.g., stateless transactions

Well, The concept of "packet" ceases to exist at Layer-7. When you have a HTTP profile, then you're dealing with Requests and Responses, and all the details of packets are dealt with for you with the HTTP Profile. It gives you a persistent Request/Response interface as you would expect when working at Layer 7.

Therefore, I'm not quite sure where you got the idea of a race-condition. The concept doesn't apply in this context.

So, With HTTP Profile on a VIP, a Transaction is a HTTP Request.

When the system receives the first Request, it will call "LB_SELECT", whose job is to select a pool member to forward this request to. When you set Reselect Retries > 0, you are influencing how many times the system will attempt to choose a new pool member if the initial connection fails. The job of LB_SELECT is to choose a pool member, whether this pool member is chosen by extraction from Persistence information, or by applying the LB-Algorithm to the pool members is just an implementation detail (I'm abstracting here).

From an abstract point of view then, when you apply a one-connect profile, what you are essentially doing is: * Causing LB_SELECT to be called for every transaction (which for HTTP means every request) * Reuse existing connections to the selected pool member rather than create new ones.

The key thing is the fact that LB_SELECT is now called on every transaction.

I think that using this knowledge and the Reselect Retries > 0 should achieve the effect you are aiming for.

You will of course, have to test this out in a lab and confirm that it actually gives you what you desire.