Eddie,
I've done some investigation on this issue and there is something strange. The log file indicates the messages are FIX 4.2 but the MessageCracker is failing because the resent message BeginString is FIX.4.3 and the message being resent is not a subclass of quickfix.fix43.Message. I'd expect the latter because the messages are FIX 4.2 and I assume a FIX 4.2 message factory is being used. However, I'm not sure how the message would have a FIX 4.3 BeginString. Do you have any ideas? Did you switch the FIX version during the session so that some messages in the store had differing FIX versions in the BeginString?
Steve
Steve,
Hmm, how do you now the MessageCracker is failing because the resent message BeginString is FIX.4.3?
Both me and the coutnerparty are using FIX.4.2 and I just rechecked the message log from the day when the problem occurred and all messages in that log are FIX.4.2. However, I just checked the BugReport and it seems that the normal FIX field delimiter has been removed when I pasted the messages in the BugTracker. Hence, it appears that the start of the message is 8=FIX.4.29=7635... when it really should be 8=FIX.4.2|9=7635...
Other than that I have no clue as to why any messages would have a FIX 4.3 BeginString and I can't find any of those messages in my FIX logs either.
Cheers,
/Eddie
OK, the stack trace was confusing me. The line 48 doesn't correspond to a source code line that could raise class cast exceptions (it's between two lines that could raise it). After more looking, I think I see what's happening. I'm curious. Why are you using the message cracker in the toApp method? Normally, it's used in the fromApp method to delegate to a a type-safe method for processing an incoming message.
The session is creating a generic Message for the resend and that's what's causing the ClassCastException in the message cracker which is looking for a message subtype corresponding to the FIX version. I will modify the Session class to create a message of the correct subtype using the specified message factory but I'm still curious about your use of MessageCracker.
Steve
I'm using the message cracker in the toApp in the same way,
I'm using the message cracker in the toApp in the same way, to delegate to a type-safe method for further pro
Appologize for the multiple posts but apparently Ctrl+Enter submits the comment...
I'm using the message cracker in the toApp in the same way, to delegate to a type-safe method for further processing. For example, I use it to catch when QuickFIX is sending Heartbeats that may indicate a faulty connection.
Would it be easy for me to modify the Session class so I don't have to wait for a new release?
Thanks,
/Eddie
What I'm planning to do is modify the nextResendRequest method in Session.java. There is a line...
Message msg = new Message((String) messages.get
, dataDictionary);
in the loop where message are reconstructed from the strings in the message store. I intend to replace with something like...
String msgString = (String)messages.get;
Message msg = messageFactory.create(
MessageUtils.getStringField(msgString, 8), // BeginString
MessageUtils.getMessageType(msgString));
msg.fromString(msgString, dataDictionary, false);
It's a bit uglier and requires some preparsing of the message, which is why is wasn't done before. However, I
didn't anticipate users using the MessageCracker for type safe dispatching of outgoing messages (not that there
is anything wrong with it).
I'm going to modify my ATApplication (acceptance test) to use a MessageCracker in toApp. This should recreate the problem since several of the acceptance tests trigger message resends. I'll then make the changes above and ensure all the tests still pass. If you make the changes first and it seems to work (or not), please tell me. Thanks.
Steve,
I've done the modifications you suggested and done some initial testing. Unfortunately the problem didn't occur everytime a ResendRequest was initiated by the counterparty. However, the modified code seems to work fine so I'll keep testing and check if the ClassCastException reappear.
Thanks and keep up the good work!
/Eddie
The fix has been committed to the 1.0.x branch and to the trunk.