How to keep the client connection when LB_FAILED?

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