ZagTrader

QuickFIX onMessage Not Called: Message Cracking Problems

Written and maintained by ZagTrader. Last reviewed . How this page is sourced and checked

The MessageCracker turns the generic message QuickFIX passes to fromApp into a call to a typed handler such as onMessage(ExecutionReport). When the handler is never called, the counterparty usually receives a Business Message Reject, because the cracker's fallback throws an unsupported-message-type exception.

The wiring that must be in place

QuickFIX/J
public class App extends MessageCracker implements Application {
    @Override
    public void fromApp(Message message, SessionID sessionID)
            throws FieldNotFound, IncorrectDataFormat, IncorrectTagValue, UnsupportedMessageType {
        crack(message, sessionID);
    }

    @Handler
    public void onExecutionReport(quickfix.fix44.ExecutionReport report, SessionID sessionID) {
        // ...
    }
}
QuickFIX/n
public class App : MessageCracker, IApplication {
    public void FromApp(Message message, SessionID sessionID) {
        Crack(message, sessionID);
    }

    public void OnMessage(QuickFix.FIX44.ExecutionReport report, SessionID sessionID) {
        // ...
    }
}

Why the handler is not called

  1. fromApp does not call crack. Admin messages go to fromAdmin, which is not cracked unless you do it yourself.
  2. The handler is for another FIX version. The cracker matches the exact class: a quickfix.fix42.ExecutionReport handler is not called on a FIX 4.4 session, and on FIXT.1.1 the class follows the message's application version (fix50sp2 for FIX 5.0 SP2).
  3. The handler is not public, or has the wrong shape. QuickFIX/J looks for public methods named onMessage, or annotated with @Handler, that take the message and a SessionID. QuickFIX/n wants public void methods named OnMessage. QuickFIX C++ needs an override of the virtual onMessage for that type.
  4. The message classes are missing at runtime. QuickFIX/J 3.x needs the quickfixj-messages-fixNN artefact; QuickFIX/n needs the matching message package. Without them the engine cannot build the typed message.
  5. The message type is not in the dictionary, such as a custom MsgType. Add it to the dictionary and regenerate the classes, or handle it in fromApp before cracking.
  6. You built your own cracker instance with the wrong handler object. In QuickFIX/J, new MessageCracker(handler) registers the handler's methods, not the ones of the class that calls it.

What the counterparty sees

EngineAnswer to an unhandled application message (FIX 4.2 and later)
QuickFIX/JBusiness Message Reject (35=j) with 380=3 (Unsupported Message Type)
QuickFIX C++Business Message Reject (35=j) with 380=3
QuickFIX/nBusiness Message Reject (35=j) with 380=2 (Unknown message type)

Before FIX 4.2 the answer is a session Reject reading "Unsupported message type". In every case the message counts as processed and is not resent, so a missed Execution Report is a missed fill. Search the messages log for outgoing 35=j.

A different symptom: the handler throws a runtime exception. QuickFIX/J then does not advance the expected sequence number (unless RejectMessageOnUnhandledException=Y), so the next message triggers a resend and the same message is delivered again, and fails again.

Questions

Why does QuickFIX send "Unsupported Message Type"?
Your application did not handle that message type: crack found no onMessage handler for its class, or fromApp threw UnsupportedMessageType itself.
Do I need a MessageCracker?
No. You can read MsgType in fromApp and handle the message yourself. The cracker only saves the casting.
Why is my QuickFIX/J handler called for FIX 4.4 but not FIX 4.2?
Handlers are matched by class, and each FIX version has its own classes. Add a handler for the quickfix.fix42 class as well.

The FIX side of the problem

What the error means on any FIX engine, with example messages you can open in the parser:

Reference

Sources

  1. QuickFIX/J source: MessageCracker.java
  2. QuickFIX/J user manual: Receiving messages
  3. QuickFIX/J source: Session.java (setting names, defaults, logout and reject texts)
  4. QuickFIX/J README: runtime artefacts per FIX version
  5. QuickFIX/n source: MessageCracker.cs
  6. QuickFIX/n documentation: Receiving messages
  7. QuickFIX/n source: Session.cs (reject handling, sequence texts)
  8. QuickFIX C++ documentation: Receiving messages
  9. QuickFIX C++ source: Session.cpp (reject handling, sequence texts)

Setting names, defaults and message texts were checked against the projects' source code and documentation on the review date shown at the top of the page. Behaviour can change between releases; check the version you run. This guide is independent and not affiliated with the QuickFIX projects.

See also

More QuickFIX guides