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

No error message (Null pointer exception thrown) on unexpected message (SingleThreadedEventHandler) (easy to fix)

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 1.0.4
    • Fix Version/s: 1.1.0
    • Component/s: Engine
    • Labels:
      None
    • Environment:
      Windows (not hardware specific)

      Description

      (n.b. I only use the SingleThreadedEventHandler)

      The problem ...
      Basically if the QuickLib gets an unexpected message for a session it throws a null pointer exception (not sure if this has some more serious effects as it progates back up into the mina stuff), rather than display an error log message as the bit that catches the exception generated later then querys the (null) session for log detail but its null ! i.e. the bit that catches the exception causes a new one Changing this to an appropriate error is \would bea big help as initialy I thought this was the issue rather than a symptom of another problem. I've tested this on a Windows XP set.

      From SingleThreadEventHandler, the code calling it does not prevent QuickSession = null, this causes a null pointer exception which is caught and an attempt is made to print an error but the catch queries the null object which goes bang again.

      try {
      if (quickfixSession.getResponder() != null)

      { quickfixSession.next(message); }

      } catch (Throwable e)

      { LogUtil.logThrowable(quickfixSession.getSessionID(), e.getMessage(), e); }

      Real World Example ...
      This can happen in the real world if a test request / heart beat that's late , the session may have given up by the time the 'lost' message makes it, this message is now considered unexpected (which is ok) . Currently you get a null pointer exception later in the process from an exception handler thats hard to trace \ understand when the lost message arrives (it might cause other ill effects but i haven't had a chance to look and its so easy to fix its probably not worth it)

      In mina.acceptor.AcceptorioHandler, method processMessage change the last line from ....

      eventHandlingStrategy.onMessage(qfSession, message);

      to ....

      if (qfSession==null)
      {
      // [CH] this can happen if a late test request arrives after we gave up waiting and closed the session.
      log.error("Attempt to process message for non existant or closed session (only legal action for logon messages) this message type was :-"+message.getHeader().getString(MsgType.FIELD));
      }
      else
      {
      eventHandlingStrategy.onMessage(qfSession, message);
      }

        Attachments

          Activity

            People

            • Assignee:
              admin Steve Bate
              Reporter:
              chris hurst Christopher Hurst
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: