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

Race condition between SocketAcceptorIoProcessor & QFJ Message Processor

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Default
    • Resolution: Fixed
    • Affects Version/s: 1.5.3
    • Fix Version/s: 1.6.4
    • Component/s: Build
    • Labels:
    • Environment:
      Linux

      Description

      We experienced a race condition where Application.onLogout() method was not called.

      On a Session, we issue a logout from another thread. The counterparty will then respond with a logout message and disconnect. When this happens, there are two threads in play, the "QFJ Message Processor" thread that processes the counterparty logout message, and another "SocketAcceptorIoProcessor" thread spawned by Mina when the socket disconnects. Both of these threads ultimately fall into the Session.disconnect(String,boolean) method. The sequence of events go like this in Session.disconnect():

      1. "SocketAcceptorIoProcessor" sets the responder to null
      2. "QFJ Message Processor" sees that the responder is null and returns from Session.disconnect(). The body of the Session.disconnect() method is wrapped in a try..finally block, so when "QFJ Message Processor" exits this method via the return, it sets logonReceived and logonSent flags to false.
      3. "SocketAcceptorIoProcessor" reaches if statement that checks logonReceived and logonSent, these flags were false because "QFJ Message Processor" cleared them when it exited previously. As a result, Application.onLogout() is never executed.

      I took a look at QFJ-803, QFJ-810 and QFJ-790 and they aren't quite the same issue as the one we experienced. I also pulled a latest copy of the QuickFix code from master, and it appears the current code could be potentially affected by this issue.

      Can you please confirm if this is a current bug in the code and/or if it has been fixed by another jira that I did not see ?

        Attachments

          Activity

            People

            • Assignee:
              paul.rowe@tradingscreen.com Paul Rowe
              Reporter:
              paul.rowe@tradingscreen.com Paul Rowe
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: