Quickfix, Is there a "catch-all" method OnMessage to handle incoming messages not handled by overloaded methods?

Question

I use MessageCracker Crack(message, sessionId); within FromAdmin and FromApp (I use version 1.4 of quickfix/n and message cracker seems to also handle admin messages, at least the overloaded OnMessage(Quickfix.Fix44.Longon message, SessionID sessionid){} is handled correctly).

My question is: In case I have not overloaded all OnMessage methods for all incoming messages that go through MessageCracker is there some sort of "catch-all-other" message method that will be called for incoming messages that cannot be forwarded to an overloaded OnMessage method? I do not want to have QuickFix send message rejects just because, for example a FIX server sends an unhandled message which, however, may not be essential to the process flow. I just want to handle it myself. I do not feel comfortable to handle it in try/catch because I do not feel that is the cleanest approach.

Any advice?

Thanks

Dickenson

Answer 1

No, there isn't.

Any respectable FIX counterparty will have a spec that tells you which messages types they will send to you (as well as which fields these messages might contain).

Therefore, you should know all the message types you need to support, and can provide an OnMessage call for each of them.

You could pre-test the message string's type field before calling crack(). That would work, but I think it's misguided.

Tisiphone

I am fully aware of which message types are expected but I don't want to be forced to have to implement all of them if the interface I write does not need to support them due to specific requirements. Plus I am writing a base class and hence cannot target specific message types which only the derived class knows – Dickenson

It sounds like you are using QF/n in a rather unorthodox fashion. I don't know your requirements, but I think that you may be doing something misguided. In my experience, most counterparties connections don't use more than 20 (non-admin) msg types; writing an empty or near-empty OnMessage() for each isn't really burdensome. – Tisiphone

I will think about it. Thanks for the critical comment I definitely appreciate it. – Dickenson

after more testing I am still confused about the right way to use MessageCracker then. Let's say I use Message Cracker in FromAdmin and ToAdmin. My OnMessage(Logon message, SessionID sessionid) is called twice, when sending a logon request and when receiving the logon reply. How can I differentiate between the two? I need to add my username and password in the logon request but obviously do not want to do so when receiving the logon acknowledged reply. – Dickenson

You should only call it inside FromApp, because it's meant to help you decode received Application messages. It makes no sense to crack an outgoing message. (You shouldn't crack in FromAdmin, because you normally don't want to define special handling for Admin messages. I mean, there's no reason to handle a Heartbeat, right?) – Tisiphone

After lots of complications I "dumped" MessageCracker altogether. It just does not fit the bill for me in terms of the required flexibility to handle custom message types. It is much simpler (and most likely faster) to identify messages by Tag35 and then decide how to handle them. Only some will in that case be parsed if needed, but in the case of MessageCracker as soon as its implemented ALL messages are parsed plus it obviously cannot handle unknown (to the library) message types. – Dickenson

Answer 2

You can consider the try/catch the cleanest approach.

Internally, the Crack() method simply searches for a method that can handle the received message type (using Reflection). If it can't be found, then a QuickFix.UnsupportedMessageType exception is thrown.

Important: QuickFix won't reject unsupported messages through the MessageCracker, you need to programatically reject it if you want.

When you have a scenario where you don't know all the messages that will be sent by your counterparty I can't see more than these two options:

1. To Catch the UnsupportedMessageType exception and handle the message string by yourself.
2. Not to catch the exception, ignoring it through the OnMessage event

Denote

Thanks, your comment, on cracker not rejecting messages automatically, helped. – Dickenson

after more testing I am still confused about the right way to use MessageCracker then. Let's say I use Message Cracker in FromAdmin and ToAdmin. My OnMessage(Logon message, SessionID sessionid) is called twice, when sending a logon request and when receiving the logon reply. How can I differentiate between the two? I need to add my username and password in the logon request but obviously do not want to do so when receiving the logon acknowledged reply. What is your take on that? – Dickenson

Maybe another idea, I didn't think deeply about it, complementing @Grant comment, is to implement your own MessageCracker, its actually very simple to split the Crack method in two methods and have OnMessageReceived and OnMessageSent handlers. The MessageCracker source code can be easily found here – Denote

Answer 3

I'm a bit late to the question, but there definitely is a way to catch all messages that doesn't imply manual parsing.

public void onMessage(quickfix.Message msg, SessionID session) {
  // catch all messages that are not caught by any invoker
}

So say you got an ExecutionReport and you hadn't overload the method public void onMessage(quickfix.fix44.ExecutionReport msg, SessionID sessionID) the message would be sent to that method instead.

Also documented in the JavaDoc.

Reft