MsgSeqNum too low...

7 messages Options
Embed this post
Permalink
Ivan Voras

MsgSeqNum too low...

Reply Threaded More More options
Print post
Permalink
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi,

Without doing anything unusual (or at least nothing that we haven't
been doing all the time), I suddenly started getting this message in
my protocol logs:

WARNING: fromAdmin;
8=FIX.4.4 9=110 35=5 34=7117 49=HTFD 52=20090909-12:12:06.531
56=CLIENT 58=MsgSeqNum
too low, expecting 5716 but received 153 10=041

followed by logouts. The "received" message id (153 in the above
message) increases, but apparently only after reconnects.

Of course, we now cannot receive anything from upstream (we're
normally just receiving data). The only possibly "unusual" thing we do
is abruptly kill the application now and then for debugging during
development - I don't know if it can cause the issue above.

Any clues on what causes this and how to avoid it in the future?

--
f+rEnSIBITAhITAhLR1nM9F4cIs5KJrhbcsVtUIt7K1MhWJy1A==

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Mike Perik

Re: MsgSeqNum too low...

Reply Threaded More More options
Print post
Permalink
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Is your country party resetting sequence numbers?

--- On Wed, 9/9/09, Ivan Voras <[hidden email]> wrote:

> From: Ivan Voras <[hidden email]>
> Subject: [Quickfixj-users] MsgSeqNum too low...
> To: [hidden email]
> Date: Wednesday, September 9, 2009, 7:21 AM
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi,
>
> Without doing anything unusual (or at least nothing that we
> haven't
> been doing all the time), I suddenly started getting this
> message in
> my protocol logs:
>
> WARNING: fromAdmin;
> 8=FIX.4.4 9=110 35=5 34=7117 49=HTFD
> 52=20090909-12:12:06.531
> 56=CLIENT 58=MsgSeqNum
> too low, expecting 5716 but received 153 10=041
>
> followed by logouts. The "received" message id (153 in the
> above
> message) increases, but apparently only after reconnects.
>
> Of course, we now cannot receive anything from upstream
> (we're
> normally just receiving data). The only possibly "unusual"
> thing we do
> is abruptly kill the application now and then for debugging
> during
> development - I don't know if it can cause the issue
> above.
>
> Any clues on what causes this and how to avoid it in the
> future?
>
> --
> f+rEnSIBITAhITAhLR1nM9F4cIs5KJrhbcsVtUIt7K1MhWJy1A==
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal
> Reports 2008 30-Day
> trial. Simplify your report design, integration and
> deployment - and focus on
> what you do best, core application coding. Discover what's
> new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>


     

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
ofer yoshiahu

Re: MsgSeqNum too low...

Reply Threaded More More options
Print post
Permalink
In reply to this post by Ivan Voras
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



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();

On Wed, Sep 9, 2009 at 7:21 AM, Ivan Voras <[hidden email]> wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J
Support: http://www.quickfixj.org/support/


Hi,

Without doing anything unusual (or at least nothing that we haven't
been doing all the time), I suddenly started getting this message in
my protocol logs:

WARNING: fromAdmin;
8=FIX.4.4 9=110 35=5 34=7117 49=HTFD 52=20090909-12:12:06.531
56=CLIENT 58=MsgSeqNum
too low, expecting 5716 but received 153 10=041

followed by logouts. The "received" message id (153 in the above
message) increases, but apparently only after reconnects.

Of course, we now cannot receive anything from upstream (we're
normally just receiving data). The only possibly "unusual" thing we do
is abruptly kill the application now and then for debugging during
development - I don't know if it can cause the issue above.

Any clues on what causes this and how to avoid it in the future?

--
f+rEnSIBITAhITAhLR1nM9F4cIs5KJrhbcsVtUIt7K1MhWJy1A==

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Ivan Voras

Re: MsgSeqNum too low...

Reply Threaded More More options
Print post
Permalink
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


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();

Thanks!

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Ivan Voras

Re: MsgSeqNum too low...

Reply Threaded More More options
Print post
Permalink
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
Laurent DANESI

Re: MsgSeqNum too low...

Reply Threaded More More options
Print post
Permalink
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
Ivan Voras

Re: MsgSeqNum too low...

Reply Threaded More More options
Print post
Permalink
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


2009/9/16 Laurent Danesi <[hidden email]>:

> 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).

Hi,

Thank you for your response, but in parallel I've talked to the
counterparty people and they have suggested a different solution that,
while I don't really know enough to claim is perfectly correct, at
least appears to work. They've asked us to add ResetSeqNumFlag to the
login message (in toAdmin) and I'll see if the application survives
the next 24h of continuous operation. They've also asked us to reduce
the reconnect interval to 120s (was 1s).

I'm curious to learn if this approach has some nontrivial
consequences. We are concerned about not losing any potential data
records.

> What are your time constraints?

If that doesn't work, we would need to have an acceptable solution
within two weeks.

------------------------------------------------------------------------------
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