QuickFIX/J Documentation:
http://www.quickfixj.org/documentation/QuickFIX/J Support:
http://www.quickfixj.org/support/Hi Ivan,
I'm preparing a new QuickFixJ release containing a new feature called forceResync which seems exactly what you are trying to do.
I think that I will integrate most of the changes in the trunk soon (end of this week).
What are your time constraints?
Laurent DANESI
Chief Architect
Smart-Trade Technologies
-----Message d'origine-----
De : Ivan Voras [mailto:
[hidden email]]
Envoyé : mercredi 16 septembre 2009 16:05
À :
[hidden email]
Objet : Re: [Quickfixj-users] MsgSeqNum too low...
QuickFIX/J Documentation:
http://www.quickfixj.org/documentation/QuickFIX/J Support:
http://www.quickfixj.org/support/2009/9/9 Ivan Voras <
[hidden email]>:
> 2009/9/9 ofer yoshiahu <
[hidden email]>:
>
>>
>> In the logout message you should have the expected sequence number in tag 789 if you don't have it you can parse the error message.
>>
>> You can set the next sender/target sequence number (method of Session object) and then can session.login() or session.reset()
>>
>> Something like this:
>> int expectedSeqNum = message.getInt(789);
>> sessio.setNextSenderMsgSeqNum(expectedSeqNum);
>> session.logon();
Hi,
It looks like the problem will happen frequently and I need to create
at least an automatic, if not completely accurate, solution.
I've read the protocol logs and I don't receive field 789 in any of
the messages. What I do receive is a text message (58) saying
"MsgSeqNum too low, expecting 45 but received 2" in fromAdmin() for
message type LOGOUT (35=5). It is dirty but I can parse this message.
However, I cannot seem to find how should i call
setNextSenderMsgSeqNum() to have the desired effect. I can call
Session.lookupSession(sessionId).setNextSenderMsgSeqNum(expectedMessageId)
but if I call it from the fromAdmin() handler, it doesn't have any
effect (i.e. the next reconnect iteration again uses the low message
ID).
Another alternative would be to directly alter the sessions table (I
use JDBC for message logs, etc) but this looks even more dirty.
I'm looking for advice on how to proceed - which is the least ugly solution?
--
f+rEnSIBITAhITAhLR1nM9F4cIs5KJrhbcsVtUIt7K1MhWJy1A==
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users