I am using QuickFIX/J to implement a very simple application that keeps track of TradeCaptureReport messages. Basically the application only stores all messages received through public void fromApp(Message message, SessionID session) into a database.
Suppose that for some reason the database is temporarily down. What would be the best way to address such a situation?
Simply throw a RuntimeException from public void fromApp(Message message, SessionID session). This will prevent the message from being removed from the queue and fromApp will be called again and again with this message until the database is up again. Other messages arriving at my FIX engine will be piled up on our end.
As soon as we detect a database connection problem, we log out and throw a RuntimeException from fromApp. This makes sure the last message is not removed from the queue and any further messages will be piled up on the other side of the FIX session (at the counterparty). We continue polling the database until it comes up again. Once up again, we log on and continue from where we have left.
Are there any other options?
Your second option is somewhat OK: Log out when you detect that your database/OMS goes down. However you might only notice this when you just received a TradeCaptureReport.
Options:
Reply with a BusinessMessageReject with reject reason BusinessRejectReason.APPLICATION_NOT_AVAILABLE. Set the RefSeqNum to the MsgSeqNum of the message that you received, optionally set a reason in Text (58). Note that it depends on the implementation of the counterparty whether this will be handled correctly, or is even supported.
Provide an alternative message store that will never go down. Eg a store on disk that you maintain yourself, and from which you know it will never go down. Once the database/OMS is up again, forward the store to your database/OMS. AFAICT this is the most robust way to handle this.