Uploaded image for project: 'QuickFIX/J'
  1. QuickFIX/J
  2. QFJ-638

SocketSynchronousWrites=Y Hangs Threads on Session responderSync

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Default
    • Resolution: Fixed
    • Affects Version/s: 1.5.1
    • Fix Version/s: 1.6.0
    • Component/s: Engine
    • Labels:
      None

      Description

      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())

      { getLog().onEvent("No responder, not sending message: " + messageString); return false; }

      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)

      { responder = this.responder; }

      if (responder == null)

      { getLog().onEvent("No responder, not sending message: " + messageString); return false; }

      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.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                chrjohn Christoph John
                Reporter:
                jim_b_o James Olsen
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: