I "cloned" this issue, because I have the same issue, only when trying to have my initiator logon to CME. I get the following response from CME:
<20070611-14:16:03, FIX.4.2:P50187N->CME, incoming> (8=FIX.4.29=16735=534=76369=152=20070611-14:18:22.03049=CME50=G56=P50187N57=18758=Sequence number received lower than expected. Expected [2] Received 1. Logout forced.789=210=057)
Yet, my "fromAdmin(...)" method is never called. That is, I gave logging in all of my callback methods, but all I see is:
2007-06-11 14:14:14,626 DEBUG [sm_cme_dev100] [QFJ Timer] [CMEFIXConnection] - To-Admin, message (8=FIX.4.29=6535=A34=149=P50187N52=20070611-14:14:14.62656=CME98=0108=3010=117) received for session (quickfix.Session@eafb71)!
2007-06-11 14:14:15,538 DEBUG [sm_cme_dev100] [QFJ Message Processor] [CMEFIXConnection] - Logged-Out from session (quickfix.Session@eafb71)!
Any help is greatly appreciated. I am new to FIX in general, so apologies if I am missing something obvious.
Regeards,
- Stacey
To use FIX effectively, it's very important to understand the how the protocol uses sequence numbers. For some reason, your session is expecting a sequence number of 2 and you are receiving a message with sequence number of 1 (and it's not flagged as a possible duplicate). This is a serious problem. The most common cause is that your session state is inconsistent with the counterparty state. This often happens during debugging sessions. You may need to reset the sequence numbers to synchronize your state with the counterparty. There are various ways to do this depending on the type of message store implementation you are using and the session configuration you have defined (for example, reset on logout behavior). A "reset" means the sequence numbers are set back to 1 for incoming and outgoing messages and any stored messages are cleared (no error recovery will be possible for earlier messages).
In your case, the CME is telling you it expected a sequence number of 2 and you are giving a sequence of 1. This means that you may have done a reset and the reset itself is why you are out of sync with the CME. You must adjust those sequence numbers to get back in sync.
As far as I can tell, the CME may have done a "log out" by just closing the connection. This isn't recommended by the spec, but it's not uncommon. You will receive the onLogout callback but no fromAdmin callback if the logout was not sent or possibly because the connection was closed before the logout was received (if it was actually sent).
I have resolved this issue. I do understand everything commented on above (knock on wood 
and my concern was that the "fromAdmin(...)" method was not being invoked so that I could resolve the issue programmatically per the ECN's specs. However, the comments above regarding "reset(...)" made me realize that some recovery code was erroneously calling the "reset(...)" method which must have been clearing the event queues internally. Once I removed this erroneous code, I was able to recover from the condition just as the ECN specified.