Details

    • Type: Bug
    • Status: Resolved
    • Priority: Default
    • Resolution: Fixed
    • Affects Version/s: 1.4.0
    • Fix Version/s: 1.5.3
    • Component/s: Engine
    • Labels:
      None

      Description

      The problem happens when using QuickFIX as an Acceptor.

      Symptoms:
      A user logs in, waits 30 seconds and logout out.
      One minute after, the same user logs in and 2 seconds after the login, QuickFix initiates a logout.

      Why does QuickFIX initiate a log out? I've traced the problem to a Boolean in SessionState.logoutReceived that doesn't get reset to false.

      Let me explain exactly what happened:

      When the user initiates the logout (the fisrt time), at one time the method Session.nextLogout(Message logout) is executing.
      There you do state.setLogoutReceived(true); and call disconnect() that will set state.setLogoutSent(false);
      All this happens in the "QF/J Session dispatcher" thread.

      In my case, in the Session.nextLogout(Message logout) method, after we have generated the logout message and before we set state.setLogoutReceived(true) , the client closes the connection. Because of this, the "SocketAcceptorIoProcessor-1.0" thread calls Session.disconnect() from AbstractIoHandler.sessionClosed(), executes the disconnect() method fully and returns. Then the "QF/J Session dispatcher" thread continues to execute and sets state.setLogoutReceived(true). When the "QF/J Session dispatcher" thread calls disconnect, the responder has been set to null and the logic ends there. Therefore the thread never reached the code that sets state.setLogoutSent(false)

      The conclusion is that the Boolean logoutSent remains true in the SessionState and because of this, at the next login, the session will log out automatically after 2 seconds.

      To recap, the main problem is that the state machine that is the Session is not well controlled and because of the interaction of several threads, some unforeseen things can happen. This is not a synchronization problem but rather a logical problem.

      As I'm in a hurry, I've just synchronized all the methods of the Session so that only one thread at a time can access it and my problems went away, but there must be a better solution.

      A last word, there was another circumstance when things went wrong at the end, so the example above is just a symptom of a larger problem.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                chrjohn Christoph John
                Reporter:
                stephan Stephan
              • Votes:
                6 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: