Hi Vernon.
I tried your suggestion of adding a
LB::deatch
after the
TCP::release
and before the
node
or
pool
command but the same issue occurred.
I added more logging to track down what events fire and when.
The server is chosen, that is LB_SELECTED fires, after
TCP::release
is executed.
LB::detach
and then
node
or
pool
didn't seem to have any effect on the LB server decision.
I then removed the
LB::detach
and both
node
or
pool
commands and added
LB::reselect node $dstaddr 2626
to the
LB_SELECTED event and everything now works correctly.
So my summary sequence of events / commands is:
- No server chosen
- No server chosen
TCP::release
- A server from pool chosen
LB::reselect node $dstaddr 2626
- Correct server is chosen. 192.168.2.104 in example above.
TCP data flow
Another thing I tried was
TCP::collect 5 0
in the
CLIENT_ACCEPTED event.
That caused the SERVER_CONNECTED event to fire in the CLIENT_ACCEPTED event and the
LB::detach
and then
node
or
pool
worked as expected.
However the client application expects a server banner to proceed and the SERVER_CONNECTED event doesn't fire for the new, correct server IP until data is received from the client. Therefore the connection stalls because the client never sends any more data while waiting for the server banner.
Thanks.