Menu
▾
▴
quickfixj-users
|
From: Ivan V. <iv...@gm...> - 2009-09-09 12:53:22
|
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== |
|
From: Mike P. <mic...@ya...> - 2009-09-09 12:59:42
|
Is your country party resetting sequence numbers? --- On Wed, 9/9/09, Ivan Voras <iv...@gm...> wrote: > From: Ivan Voras <iv...@gm...> > Subject: [Quickfixj-users] MsgSeqNum too low... > To: qui...@li... > 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 > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > |
|
From: ofer y. <of...@gm...> - 2009-09-09 13:01:58
|
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 <iv...@gm...> wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J <http://www.quickfixj.org/documentation/%0AQuickFIX/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
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
|
|
From: Ivan V. <iv...@gm...> - 2009-09-09 13:29:37
|
2009/9/9 ofer yoshiahu <of...@gm...>: > > 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! |
|
From: Ivan V. <iv...@gm...> - 2009-09-16 14:05:58
|
2009/9/9 Ivan Voras <iv...@gm...>: > 2009/9/9 ofer yoshiahu <of...@gm...>: > >> >> 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== |
|
From: Laurent D. <ld...@Sm...> - 2009-09-16 18:13:44
|
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:iv...@gm...] Envoyé : mercredi 16 septembre 2009 16:05 À : qui...@li... 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 <iv...@gm...>: > 2009/9/9 ofer yoshiahu <of...@gm...>: > >> >> 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 Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
|
From: Ivan V. <iv...@gm...> - 2009-09-16 18:44:44
|
2009/9/16 Laurent Danesi <ld...@sm...>: > 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. |
|
From: yakulis <ros...@em...> - 2018-09-27 18:35:27
|
I found this worked.
public void toAdmin(Message message, SessionID sessionID) {
log.debug("Admin Message to FixEngine -> " +
getMessageTypeString(message));
logMessage(message);
MsgType messageType = getMessageType(message);
if (messageType.valueEquals(MsgType.LOGON)) {
log.debug("Logon, setting reset sequence flag");
message.setField(new ResetSeqNumFlag(true));
logMessage(message);
} else if (messageType.valueEquals(MsgType.HEARTBEAT)) {
--
Sent from: http://quickfix-j.364392.n2.nabble.com/
|
|
From: Colin D. <co...@ma...> - 2018-09-27 19:11:54
|
I'm not sure what you're responding to, but, you can accomplish this more easily through configuration: /ResetOnLogon/ Determines if sequence numbers should be reset before sending/receiving a logon request. Y N N /ResetOnLogout/ Determines if sequence numbers should be reset to 1 after a normal logout termination. Y N N /ResetOnDisconnect/ Determines if sequence numbers should be reset to 1 after an abnormal termination. Y N N /ResetOnError/ Session setting for doing an automatic reset when an error occurs. A reset means disconnect, sequence numbers reset, store cleaned and reconnect, as for a daily reset. Y N N On 09/27/2018 11:15 AM, yakulis wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > I found this worked. > > public void toAdmin(Message message, SessionID sessionID) { > log.debug("Admin Message to FixEngine -> " + > getMessageTypeString(message)); > logMessage(message); > MsgType messageType = getMessageType(message); > > if (messageType.valueEquals(MsgType.LOGON)) { > log.debug("Logon, setting reset sequence flag"); > message.setField(new ResetSeqNumFlag(true)); > logMessage(message); > } else if (messageType.valueEquals(MsgType.HEARTBEAT)) { > > > > > -- > Sent from: http://quickfix-j.364392.n2.nabble.com/ > > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users -- Colin DuPlantis Chief Architect, Marketcetera Download, Run, Trade 888.868.4884 +1.541.306.6556 http://www.marketcetera.org |
|
From: Ross Y. <ros...@em...> - 2018-09-28 02:31:31
|
Good point I will try that. I missed that. Just starting out on Fix and learning. > On Sep 27, 2018, at 11:40 AM, Colin DuPlantis <co...@ma...> wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > I'm not sure what you're responding to, but, you can accomplish this more easily through configuration: > > ResetOnLogon Determines if sequence numbers should be reset before sending/receiving a logon request. Y > N N > ResetOnLogout Determines if sequence numbers should be reset to 1 after a normal logout termination. Y > N N > ResetOnDisconnect Determines if sequence numbers should be reset to 1 after an abnormal termination. Y > N N > ResetOnError Session setting for doing an automatic reset when an error occurs. A reset means disconnect, sequence numbers reset, store cleaned and reconnect, as for a daily reset. Y > N N > > On 09/27/2018 11:15 AM, yakulis wrote: >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ <http://www.quickfixj.org/documentation/> >> QuickFIX/J Support: http://www.quickfixj.org/support/ <http://www.quickfixj.org/support/> >> >> >> I found this worked. >> >> public void toAdmin(Message message, SessionID sessionID) { >> log.debug("Admin Message to FixEngine -> " + >> getMessageTypeString(message)); >> logMessage(message); >> MsgType messageType = getMessageType(message); >> >> if (messageType.valueEquals(MsgType.LOGON)) { >> log.debug("Logon, setting reset sequence flag"); >> message.setField(new ResetSeqNumFlag(true)); >> logMessage(message); >> } else if (messageType.valueEquals(MsgType.HEARTBEAT)) { >> >> >> >> >> -- >> Sent from: http://quickfix-j.364392.n2.nabble.com/ <http://quickfix-j.364392.n2.nabble.com/> >> >> >> _______________________________________________ >> Quickfixj-users mailing list >> Qui...@li... <mailto:Qui...@li...> >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users <https://lists.sourceforge.net/lists/listinfo/quickfixj-users> > > -- > Colin DuPlantis > Chief Architect, Marketcetera > Download, Run, Trade > 888.868.4884 +1.541.306.6556 > http://www.marketcetera.org <http://www.marketcetera.org/>_______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users -- NOTICE: This communication may contain information that is privileged or confidential. It may be read and used solely by the intended recipient(s), and any review, use or distribution by others is STRICTLY PROHIBITED. If you are not the intended recipient, you are prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. No assurance is given that this e-mail or any attachments are free of viruses or other harmful code. |
|
From: Colin D. <co...@ma...> - 2018-09-28 12:55:49
|
Note that, usually, you'll arrange with the counter parties when to reset the session. QFJ will reset the sequence number automatically at the start of the session. I have rarely (ever?) had to explicitly set 141 on messages and usually the counters don't appreciate it and might not even respect it. On 09/27/2018 06:59 PM, Ross Yakulis wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > > > > > Good point I will try that. I missed that. Just starting out on Fix > and learning. > > >> On Sep 27, 2018, at 11:40 AM, Colin DuPlantis <co...@ma... >> <mailto:co...@ma...>> wrote: >> >> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ >> QuickFIX/J Support: http://www.quickfixj.org/support/ >> >> >> I'm not sure what you're responding to, but, you can accomplish this >> more easily through configuration: >> >> /ResetOnLogon/ Determines if sequence numbers should be reset before >> sending/receiving a logon request. Y >> N N >> /ResetOnLogout/ Determines if sequence numbers should be reset to 1 >> after a normal logout termination. Y >> N N >> /ResetOnDisconnect/ Determines if sequence numbers should be reset >> to 1 after an abnormal termination. Y >> N N >> /ResetOnError/ Session setting for doing an automatic reset when an >> error occurs. A reset means disconnect, sequence numbers reset, store >> cleaned and reconnect, as for a daily reset. Y >> N N >> >> >> On 09/27/2018 11:15 AM, yakulis wrote: >>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ >>> QuickFIX/J Support:http://www.quickfixj.org/support/ >>> >>> >>> I found this worked. >>> >>> public void toAdmin(Message message, SessionID sessionID) { >>> log.debug("Admin Message to FixEngine -> " + >>> getMessageTypeString(message)); >>> logMessage(message); >>> MsgType messageType = getMessageType(message); >>> >>> if (messageType.valueEquals(MsgType.LOGON)) { >>> log.debug("Logon, setting reset sequence flag"); >>> message.setField(new ResetSeqNumFlag(true)); >>> logMessage(message); >>> } else if (messageType.valueEquals(MsgType.HEARTBEAT)) { >>> >>> >>> >>> >>> -- >>> Sent from:http://quickfix-j.364392.n2.nabble.com/ >>> >>> >>> _______________________________________________ >>> Quickfixj-users mailing list >>> Qui...@li... >>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users >> >> -- >> Colin DuPlantis >> Chief Architect, Marketcetera >> Download, Run, Trade >> 888.868.4884 +1.541.306.6556 >> http://www.marketcetera.org >> _______________________________________________ >> Quickfixj-users mailing list >> Qui...@li... >> <mailto:Qui...@li...> >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users > > > NOTICE: This communication may contain information that is privileged > or confidential. It may be read and used solely by the intended > recipient(s), and any review, use or distribution by others is > STRICTLY PROHIBITED. If you are not the intended recipient, you are > prohibited from disclosing, copying, distributing or using any of this > information. If you received this communication in error, please > contact the sender immediately and destroy the material in its > entirety, whether electronic or hard copy. No assurance is given that > this e-mail or any attachments are free of viruses or other harmful code. > > > > > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
Thanks for helping keep SourceForge clean.
X