As first noted by Parwinder Sekhon in QFJ-433 and further elaborated (perhaps confusingly) in QFJ-484, the locking used in the following Session method causes threads to hang when SocketSynchronousWrites is enabled.

private boolean send(String messageString) {
getLog().onOutgoing(messageString);
synchronized (responderSync) {
if (!hasResponder())

return getResponder().send(messageString);
}
}

Slow consumers do exist in the real world. We therefore sometimes have to use SocketSynchronousWrites=Y in order to avoid memory leaks due to all the WriteFuture objects that are generated. The problem with the current locking is that the background thread that handles heartbeats and forces logouts etc can get stuck waiting for one of these slow consumers. This means that the Session will not be logged out even if it has missed many heartbeats. Even worse, the same background thread is used for other Sessions on the same Connector so they are also impacted even if they are not synchronous.

Changing the code as follows resolves these issues.

private boolean send(String messageString) {
getLog().onOutgoing(messageString);
Responder responder;
synchronized (responderSync)

if (responder == null)

return responder.send(messageString);
}

The message sequence number locking used in the sendRaw method seems sufficient to coordinate any multi-threaded message senders given that the above change otherwise opens a hole.

The use of a ReentrantLock as discussed in QFJ-484 is not required for this issue. As shown above, the existing responderSync String object is sufficient.