Thanks for the reply.
Hmm, well, that’s a bummer. I was thinking that PF would take care of layer 3/4, and the stick tables that replicate would deal with layer 5, and then the two endpoints wouldn’t need 6/7 to be replicated anywhere, since the transport would appear to not change, since the MAC and IP address of the HAProxy machine would stay the same.
In case it helps, this is what I’m (trying) to build:
Our internal application opens the connection (via HAProx) to RabbitMQ, and it holds it open and keeps reusing it (for as long as it stays open, ie days/weeks/longer…). The majority of the time this connection is idle, so there’s no payload/traffic to deal with syncing/recovering, just the connection state (although Murphy dictates that the proxy would fail when the connection was not idle).
I guess it would make more sense to be opening and closing the connection between transfers, rather than holding it open, and then whichever proxy/broker was up and running at that instant would deal with that transaction, negating the requirement to attempt to relocate an existing connection.
Somewhat related, I have been looking at the (newish) functionality of a HAProxy master and workers, and was considering implementing this (as we will eventually be putting more microservices up), but I guess that with this persistent connection, it would just result in a worker hanging around forever to service it?