Forum Discussion
Alan_Sha
Nov 02, 2005Nimbostratus
Thanks for the hints! Since I am dealing with a TCP socket connection instead of HTTP, I use TCP::respond instead and rerun my test.
When I just used the TCP::respond alone to send a blank message back to client, the client was able to receive the response message and start to send another one. However, the client connection was still closed immediately after the response was sent from Big IP. So, eventually, the second request never got to Big IP and the client failed.
Then, I added the TCP::notify response to trigger the USER_RESPONSE event to do some clean-up and detach the server connection (even it is never connected. See below). This time, the client connection stayed alive! However, the subsequent send from the client always got stuck, even it was going to a different pool that is up and running. I put some debug statement in the LB_SELECTED event, it never shows up in the log, which seems to prove that it never got fired after the previous connection got stuck. It appears to be me that somehow the LB was not cleaned up after the LB::detach, which is blocking the next LB select.
How could I clean up the LB when a connection attempt fails?
when USER_RESPONSE {
if {$debug} { log local0.debug "Receive USER response ... " }
LB::detach
if {$debug} { log local0.debug "Detach server connection." }
reset some of the flags
set responsePending 0
set initResponse 1
set connRetry 0
}
when LB_FAILED {
set connRetry [expr {$connRetry + 1}]
if { $connRetry < $maxAttempts } {
log local0.error "Conn. to [IP::server_addr] failed. Retrying..."
LB::reselect
} else {
log local0.error "Max. re-conn. attempts exhausted. Transaction dropped."
TCP::respond "$::STX$::ETX"
serverside {TCP::notify response}
}
}
Thx,
Alan