We had exactly the same problem. In our case in a Groovy Class, which was a subclass of ApplicationAdapter, an exception has been thrown that resulted in the described behaviour. In our case it was not a RuntimeException but a CheckedException. Since Groovy does not distinguish between runtime and checked exceptions the exception was simply thrown up the call stack resulting in the described behaviour above. I.e. perhaps not only RuntimeExceptions but all Throwables have to be catched in 'quickfix.Session.next'

I think this would be a good enhancement. Basically, the behaviour is in-line with the spec which says:
"The receiving application should disregard any message that is garbled, cannot be parsed or fails a data integrity check. Processing of the next valid FIX message will cause detection of a sequence gap and a Resend Request will be generated. Logic should be included in the FIX engine to recognize the possible infinite resend loop, which may be encountered in this situation."

The tricky part here might be to discover an infinite resend loop. But as a first step it might be a good improvement to generate a Reject or BusinessMessageReject message if there is a problem inside Session.next(). This should be configurable (on/off).

Given Christoph's quote of the spec, it sounds like QF/J is only lacking the loop detection, correct? Aside from that, it's behaving appropriately.

An option to generate a reject seems like merely a workaround, and not an actual solution.

I'm more interested in the actual reject cause - why the hell would FromApp() be throwing an IllegalArgumentException? That sounds like a bug somewhere. Same for Thomas' report – why would message-parsing throw a CheckedException? These are exceptions that imply coding problems.

As described in my initial comment the ApplicationAdapter in our System can be extended by Groovy classes. We do this in order to be able to dynamically add code to patch incoming or outgoing FIX messages via Groovy scripts. In such a Groovy script it might happen that a Java method is called that throws a checked exception. Catching checked exceptions is verified by the Java compiler but since Groovy is a dynamic language there is no compilation that verifies that no such methods are called. This results in checked exceptions that are thrown but never caught.

I can understand Grant's point as well as Thomas's.

Maybe the configurable rejection can be a workaround for the time being and we will add the infinite-loop-detection in a later version (suggestions on how to dectect this are welcome ).

We have solved our problem using the following patch which simply adds another catch block in the method Session.next(Message). It is almost the same code as in the catch block for 'FieldNotFound' exceptions.

— core/src/main/java/quickfix/Session.java (revision 1052)
+++ core/src/main/java/quickfix/Session.java (working copy)
@@ -1023,6 +1023,23 @@
if (resetOrDisconnectIfRequired(message))

+ } catch(final QuickfixRuntimeException e) {
+ getLog().onErrorEvent("Rejecting message because of FrontFIX problem: " + e + ": " + message);
+ if (resetOrDisconnectIfRequired(message))

+ if (sessionID.getBeginString().compareTo(FixVersions.BEGINSTRING_FIX42) >= 0
+ && message.isApp())

else {
+ if (msgType.equals(MsgType.LOGON))

else

+ }········
}
·
nextQueued();
@@ -2478,4 +2495,9 @@
this.checkGapFieldOnAdminMessage = checkGapFieldOnAdminMessage;
}
·
-}
\ No newline at end of file
+ public static class QuickfixRuntimeException extends RuntimeException {
+ public QuickfixRuntimeException(String message, Throwable cause)

+ }
+}

Thanks for your input, but I was more referring to a suggestion for the loop-detection.
I have already prepared a similar patch which catches Throwables and is configurable.

Committed as rev #1101.

• Introduced session setting RejectMessageOnUnhandledException.
• If enabled, an uncaught Exception or Error in the application's message processing will lead to a (BusinessMessage)Reject being sent to the counterparty and the incoming message sequence number will be incremented.
• If disabled (default), a quickfix.RuntimeError is thrown, the problematic incoming message is discarded and the message sequence number is not incremented. Processing of the next valid message will cause detection of a sequence gap and a ResendRequest will be generated.