quickfix-developers Mailing List for QuickFIX (Page 261)
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-developers — QuickFIX developers forum
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
(5) |
Mar
(16) |
Apr
(15) |
May
(17) |
Jun
(33) |
Jul
(35) |
Aug
(34) |
Sep
(19) |
Oct
(40) |
Nov
(51) |
Dec
(43) |
| 2003 |
Jan
(45) |
Feb
(79) |
Mar
(124) |
Apr
(121) |
May
(132) |
Jun
(77) |
Jul
(110) |
Aug
(57) |
Sep
(48) |
Oct
(83) |
Nov
(60) |
Dec
(40) |
| 2004 |
Jan
(67) |
Feb
(72) |
Mar
(74) |
Apr
(87) |
May
(70) |
Jun
(96) |
Jul
(75) |
Aug
(147) |
Sep
(128) |
Oct
(83) |
Nov
(67) |
Dec
(42) |
| 2005 |
Jan
(110) |
Feb
(84) |
Mar
(68) |
Apr
(55) |
May
(51) |
Jun
(192) |
Jul
(111) |
Aug
(100) |
Sep
(79) |
Oct
(127) |
Nov
(73) |
Dec
(112) |
| 2006 |
Jan
(95) |
Feb
(120) |
Mar
(138) |
Apr
(127) |
May
(124) |
Jun
(97) |
Jul
(103) |
Aug
(88) |
Sep
(138) |
Oct
(91) |
Nov
(112) |
Dec
(57) |
| 2007 |
Jan
(55) |
Feb
(35) |
Mar
(56) |
Apr
(16) |
May
(20) |
Jun
(77) |
Jul
(43) |
Aug
(47) |
Sep
(29) |
Oct
(54) |
Nov
(39) |
Dec
(40) |
| 2008 |
Jan
(69) |
Feb
(79) |
Mar
(122) |
Apr
(106) |
May
(114) |
Jun
(76) |
Jul
(83) |
Aug
(71) |
Sep
(53) |
Oct
(75) |
Nov
(54) |
Dec
(43) |
| 2009 |
Jan
(32) |
Feb
(31) |
Mar
(64) |
Apr
(48) |
May
(38) |
Jun
(43) |
Jul
(35) |
Aug
(15) |
Sep
(52) |
Oct
(62) |
Nov
(62) |
Dec
(21) |
| 2010 |
Jan
(44) |
Feb
(10) |
Mar
(47) |
Apr
(22) |
May
(5) |
Jun
(54) |
Jul
(19) |
Aug
(54) |
Sep
(16) |
Oct
(15) |
Nov
(7) |
Dec
(8) |
| 2011 |
Jan
(18) |
Feb
(9) |
Mar
(5) |
Apr
(5) |
May
(41) |
Jun
(40) |
Jul
(29) |
Aug
(17) |
Sep
(12) |
Oct
(23) |
Nov
(22) |
Dec
(11) |
| 2012 |
Jan
(8) |
Feb
(24) |
Mar
(5) |
Apr
(5) |
May
(6) |
Jun
(5) |
Jul
(5) |
Aug
(5) |
Sep
(2) |
Oct
(9) |
Nov
(2) |
Dec
(18) |
| 2013 |
Jan
(25) |
Feb
(16) |
Mar
(8) |
Apr
(2) |
May
(16) |
Jun
(17) |
Jul
(2) |
Aug
(13) |
Sep
(3) |
Oct
(4) |
Nov
(1) |
Dec
|
| 2014 |
Jan
(2) |
Feb
|
Mar
(22) |
Apr
(9) |
May
(3) |
Jun
(1) |
Jul
(5) |
Aug
(11) |
Sep
(18) |
Oct
(4) |
Nov
(4) |
Dec
(3) |
| 2015 |
Jan
(2) |
Feb
|
Mar
|
Apr
(3) |
May
(4) |
Jun
(37) |
Jul
|
Aug
(4) |
Sep
(6) |
Oct
(1) |
Nov
(4) |
Dec
(2) |
| 2016 |
Jan
(9) |
Feb
(3) |
Mar
(7) |
Apr
(1) |
May
(8) |
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
(3) |
Nov
(16) |
Dec
|
| 2017 |
Jan
(1) |
Feb
(15) |
Mar
(2) |
Apr
(12) |
May
(4) |
Jun
(7) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
(23) |
Dec
(8) |
| 2018 |
Jan
(2) |
Feb
(4) |
Mar
(2) |
Apr
(8) |
May
(3) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(5) |
Nov
(3) |
Dec
|
| 2020 |
Jan
|
Feb
(4) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(12) |
Aug
(5) |
Sep
(3) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Oren M. <ore...@ya...> - 2003-11-03 16:03:23
|
Post you're fix to the developers list and someone
will check it in. It would be a good idea to update
the test case to reflect this problem. Do you have a
test case that will make the old code fail but is
succesfull with your code? Something like this will
allow us to get it into the codebase quicker. Thanks!
--- Brian Egge <Br...@ma...> wrote:
> I think I have found the problem that is causing
> this error. The error only
> surfaces when the 8=Fix is received, but the
> 9=length has not been.
>
> The problem is in Parser.cpp:
>
> bool Parser::extractLength( int& length,
> std::string::size_type& pos,
> const std::string&
> buffer )
> throw( MessageParseError& )
> { QF_STACK_PUSH(Parser::extractLength)
>
> if( !buffer.size() ) return false;
>
> std::string::size_type startPos = buffer.find(
> "\0019=", 0 );
> if( pos == std::string::npos ) return false;
> // This should be:
> // if( startPos == std::string::npos ) return
> false;
> //
> startPos += 3;
> std::string::size_type endPos = buffer.find(
> "\001", startPos );
> // This should be:
> // if( endPos == std::string::npos ) return false;
> //
> pos = endPos + 1;
>
> What happens with the current code is strLength gets
> set to 'FIX.4.x'. This
> raises and exception and throws a MessageParseError.
>
> I'd like to get this fix checked in to CVS. I
> haven't used CVS before, and
> I don't know who is given access to check in
> changes.
>
> Brian
>
>
> -----Original Message-----
> From: Miller, Oren
> [mailto:OM...@ri...]
> Sent: Tuesday, October 14, 2003 6:02 PM
> To: Br...@ma...;
> qui...@li...
> Subject: Re: [Quickfix-developers] BodyLength or
> CheckSum missing
>
>
> Do yo have an example of a message that causes this
> error?
>
> --------------------------
> Sent from my BlackBerry Wireless Handheld
>
>
> -----Original Message-----
> From: Brian Egge <Br...@ma...>
> To: qui...@li...
> <qui...@li...>
> Sent: Tue Oct 14 10:10:55 2003
> Subject: [Quickfix-developers] BodyLength or
> CheckSum missing
>
> I seem to be having a problem where I get an
> InvalidMessage("BodyLength or
> CheckSum missing") exception thrown from
> Message::validate(). When I look
> at my logs, or even re-parse the message, everything
> is in tact. I can't
> see any reason why this exception is being thrown.
> I only get this with one
> venue, and it only happens every couple of days or
> so. Has anyone else had
> this problem before?
>
> I've added some more logging to this area, and I
> think I will figure it out
> soon. The item that concerns me more is that this
> exception does not get
> handled, and the EH eventually calls terminate() or
> abort() and the program
> ends. I'm using version 1.6, and I have two
> suggestions.
>
> 1) "bool SocketConnection::read( SocketAcceptor& a,
> SocketServer& s )" has
> an exception handler, while bool
> "SocketConnection::read( SocketConnector& s
> )" does not. My exception occurs in the latter
> case. I copied the
> exception code from the one read to the other to
> make them consistent.
>
> 2) I added try {} catch(...) statement to the
> onStart() procedures, to trap
> any unhanded exceptions. I'd rather have the
> thread safely terminate than
> for my whole app to end.
>
> If these changes are worthwhile, I'll try to merge
> them in CVS.
>
> -Brian
>
>
>
-------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback
> Program.
> SourceForge.net hosts over 70,000 Open Source
> Projects.
> See the people who have HELPED US provide better
> services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
>
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
>
-------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback
> Program.
> Does SourceForge.net help you be more productive?
> Does it
> help you create better code? SHARE THE LOVE, and
> help us help
> YOU! Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
>
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/
|
|
From: Brian E. <Br...@ma...> - 2003-11-03 15:36:15
|
I think I have found the problem that is causing this error. The error only
surfaces when the 8=Fix is received, but the 9=length has not been.
The problem is in Parser.cpp:
bool Parser::extractLength( int& length, std::string::size_type& pos,
const std::string& buffer )
throw( MessageParseError& )
{ QF_STACK_PUSH(Parser::extractLength)
if( !buffer.size() ) return false;
std::string::size_type startPos = buffer.find( "\0019=", 0 );
if( pos == std::string::npos ) return false;
// This should be:
// if( startPos == std::string::npos ) return false;
//
startPos += 3;
std::string::size_type endPos = buffer.find( "\001", startPos );
// This should be:
// if( endPos == std::string::npos ) return false;
//
pos = endPos + 1;
What happens with the current code is strLength gets set to 'FIX.4.x'. This
raises and exception and throws a MessageParseError.
I'd like to get this fix checked in to CVS. I haven't used CVS before, and
I don't know who is given access to check in changes.
Brian
-----Original Message-----
From: Miller, Oren [mailto:OM...@ri...]
Sent: Tuesday, October 14, 2003 6:02 PM
To: Br...@ma...; qui...@li...
Subject: Re: [Quickfix-developers] BodyLength or CheckSum missing
Do yo have an example of a message that causes this error?
--------------------------
Sent from my BlackBerry Wireless Handheld
-----Original Message-----
From: Brian Egge <Br...@ma...>
To: qui...@li...
<qui...@li...>
Sent: Tue Oct 14 10:10:55 2003
Subject: [Quickfix-developers] BodyLength or CheckSum missing
I seem to be having a problem where I get an InvalidMessage("BodyLength or
CheckSum missing") exception thrown from Message::validate(). When I look
at my logs, or even re-parse the message, everything is in tact. I can't
see any reason why this exception is being thrown. I only get this with one
venue, and it only happens every couple of days or so. Has anyone else had
this problem before?
I've added some more logging to this area, and I think I will figure it out
soon. The item that concerns me more is that this exception does not get
handled, and the EH eventually calls terminate() or abort() and the program
ends. I'm using version 1.6, and I have two suggestions.
1) "bool SocketConnection::read( SocketAcceptor& a, SocketServer& s )" has
an exception handler, while bool "SocketConnection::read( SocketConnector& s
)" does not. My exception occurs in the latter case. I copied the
exception code from the one read to the other to make them consistent.
2) I added try {} catch(...) statement to the onStart() procedures, to trap
any unhanded exceptions. I'd rather have the thread safely terminate than
for my whole app to end.
If these changes are worthwhile, I'll try to merge them in CVS.
-Brian
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
|
|
From: Joerg T. <Joe...@ma...> - 2003-11-03 14:56:40
|
Hi all,
> does anybody know the CVS release tag for QF 1.6.0?
>
> cvs upd -rRELEASE_1_6_0
>
> did fails with
>
> cvs [server aborted]: no such tag RELEASE_1_6_0
>
> Thanks, Jörg
I just checked that all changes made since the release date (2003-08-28)
are the changes made by Alex Hornby
< 2003-10-01 11:37 alexhornby
<
< * src/java/org_quickfix/SocketInitiator.cpp: fix typo of
< doBlockingStart
<
So tagged the latest release by time:
cvs rtag -D 20030828 RELEASE_1_6_0 quickfix
Anybody who wants to check this release can now use
cvs upd -rRELEASE_1_6_0 quickfix
Cheers, Jörg
--
Joerg Thoennes
http://macd.com
Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH
Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen
|
|
From: <ili...@bn...> - 2003-11-03 11:41:13
|
Hello everyone, I noticed that tag 370 had been removed in the last release of Quickfix: it doesn't appear in Fields.h nor in FieldNumbers.h (see http://cvs.sourceforge.net/viewcvs.py/*checkout*/quickfix/quickfix/src/C%2B%2B/FieldNumbers.h ), resulting in a gap between tag 369 and tag 371. Is this a mistake, of has it been done on purpose, for a reason that I'm not aware of? Many thanks, Ilyas USAL This message and any attachments (the "message") is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. --------------------------------------------- Ce message et toutes les pieces jointes (ci-apres le "message") sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. |
|
From: murphypa <mur...@pe...> - 2003-11-03 10:35:00
|
qui...@li... wrote: >Send Quickfix-developers mailing list submissions to > qui...@li... > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/quickfix-developers >or, via email, send a message with subject or body 'help' to > qui...@li... > >You can reach the person managing the list at > qui...@li... > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of Quickfix-developers digest..." > > >Today's Topics: > > 1. Duplicate messages in incoming_log many times. (Andrew) > 2. FIX 4.1 repeating group examples in java? (Andrew) > >--__--__-- > >Message: 1 >From: "Andrew" <an...@nm...> >To: <qui...@li...> >Date: Wed, 29 Oct 2003 10:26:05 -0600 >Subject: [Quickfix-developers] Duplicate messages in incoming_log many times. > >I have found the same message inserted into my incoming_log many times in a >row. Only the ID and time fields change. These duplicate messages appear >about 450 times each second. Has anyone seen this or does anyone havea >solution? > > >Thanks, >Andrew Munn >an...@nm... > Hi Andrew, 1. Duplicate messages in incoming_log many times. (Andrew) Yes - just last week I saw exactly this same issue - does your session recover - because I stop receiving anything else - and this seems to be an endless loop - I am using the QF .NET assembly and can see that a SEH is being raised in the interop .NET layers. There seems to be no recovery from this other than to shutdown and restart - but I cannot guarantee that the system does recover. It does seem to be on the incoming link of the session as the outgoing is still validly dispatching. Also, for now I have only been able to show the error in incoming on the initiator side - but that could be due to the higher receive load on the initiator side. I have not run any tests to see if threading could be an issue - my collegue will probably be doing that and we will postback whatever we find. ciao MurphyPA |
|
From: Rich H. <rh...@st...> - 2003-10-30 20:14:33
|
I have a similar issue on the CME because of their week long session. Is=20 there a way to get at rejected messages? Has anyone added week long session support? =20 Cheers, Rich =20 -----Original Message----- From: Oren Miller [mailto:ore...@ya...]=20 Sent: Thursday, October 30, 2003 9:42 AM To: Peter Krause; qui...@li... Subject: Re: [Quickfix-developers] Sorting through the trash =20 I'm not sure there is a very convenient way to do this. Would you be able to look at the reject message QF is sending, pull out the sequence number of the rejected message, then pull the rejected message out of storage? Peter Krause <kra...@ho...> wrote:=20 Hi! Is there an override that I can use to see messages that are rejected by quickfix before they get to an application/session level? For example, if I log in to the CBOE with a too low sequence number (yes,=20 this means that there are severe problems, since I'm duping messages, and it=20 is the sort of thing that happens in testing, but is much rarer in=20 production), they tell me the sequence number they want in a text string appended to a logout message. The logout message is rejected by quickfix because I'm not officially logged in, and I can't figure out how to override=20 it so I can parse the text message and get their desired sequence number (the quick and dirty is to set the sequence # to a much higher number, since=20 fix is a lot happier with skipped messages than duped ones)... thanks, pk _________________________________________________________________ Fretting that your Hotmail account may expire because you forgot to sign in=20 enough? Get Hotmail Extra Storage today!=20 http://join.msn.com/?PAGE=3Dfeatures/es ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers _____ =20 Do you Yahoo!? Exclusive Video Premiere - Britney Spears <http://launch.yahoo.com/video/?1093432&fs=3D1&redirectURL=3Dhttp://launc= h.y ahoo.com/promos/britneyspears/>=20 |
|
From: Oren M. <ore...@ya...> - 2003-10-30 15:42:11
|
I'm not sure there is a very convenient way to do this. Would you be able to look at the reject message QF is sending, pull out the sequence number of the rejected message, then pull the rejected message out of storage? Peter Krause <kra...@ho...> wrote: Hi! Is there an override that I can use to see messages that are rejected by quickfix before they get to an application/session level? For example, if I log in to the CBOE with a too low sequence number (yes, this means that there are severe problems, since I'm duping messages, and it is the sort of thing that happens in testing, but is much rarer in production), they tell me the sequence number they want in a text string appended to a logout message. The logout message is rejected by quickfix because I'm not officially logged in, and I can't figure out how to override it so I can parse the text message and get their desired sequence number (the quick and dirty is to set the sequence # to a much higher number, since fix is a lot happier with skipped messages than duped ones)... thanks, pk _________________________________________________________________ Fretting that your Hotmail account may expire because you forgot to sign in enough? Get Hotmail Extra Storage today! http://join.msn.com/?PAGE=features/es ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers --------------------------------- Do you Yahoo!? Exclusive Video Premiere - Britney Spears |
|
From: Peter K. <kra...@ho...> - 2003-10-30 14:07:26
|
Hi! Is there an override that I can use to see messages that are rejected by quickfix before they get to an application/session level? For example, if I log in to the CBOE with a too low sequence number (yes, this means that there are severe problems, since I'm duping messages, and it is the sort of thing that happens in testing, but is much rarer in production), they tell me the sequence number they want in a text string appended to a logout message. The logout message is rejected by quickfix because I'm not officially logged in, and I can't figure out how to override it so I can parse the text message and get their desired sequence number (the quick and dirty is to set the sequence # to a much higher number, since fix is a lot happier with skipped messages than duped ones)... thanks, pk _________________________________________________________________ Fretting that your Hotmail account may expire because you forgot to sign in enough? Get Hotmail Extra Storage today! http://join.msn.com/?PAGE=features/es |
|
From: Daniel M. <Dan...@ma...> - 2003-10-30 11:23:18
|
I added the following member function to FIX::SessionID, in SessionID.h
std::string& toString( std::string& str ) const=20
{
return str =3D getBeginString().getValue() + ":" +
getSenderCompID().getValue() + "->" +
getTargetCompID().getValue();=20
}
Can this be added to the source code ? I have several other changes to
QuickFix that I would
like to contribute, but need developers access to CVS. How do I get
access or forward the
code changes to someone who can add them ?
Daniel May
|
|
From: Andrew <an...@nm...> - 2003-10-29 19:28:12
|
Does anyone have FIX 4.1 repeating group examples in java they could share?
I have no problems with 4.2 but with 4.1 it looks like NoTradingSessions is
missing from the Java API.
compile:
[javac] Compiling 1 source file to C:\oms\build
[javac] C:\oms\src\oms\OmsApplication.java:403: cannot resolve symbol
[javac] symbol : class NoTradingSessions
[javac] location: class org.quickfix.fix41.NewOrderSingle
[javac] org.quickfix.fix41.NewOrderSingle.NoTradingSessions group = new
org.quickfix.fix41.NewOrderSingle.NoTradingSessions();
[javac] ^
[javac] C:\oms\src\oms\OmsApplication.java:403: cannot resolve symbol
[javac] symbol : class NoTradingSessions
[javac] location: class org.quickfix.fix41.NewOrderSingle
[javac] org.quickfix.fix41.NewOrderSingle.NoTradingSessions group = new
org.quickfix.fix41.NewOrderSingle.NoTradingSessions();
[javac]
^
[javac] 2 errors
Thanks,
Andrew Munn
an...@nm...
|
|
From: Andrew <an...@nm...> - 2003-10-29 16:26:49
|
I have found the same message inserted into my incoming_log many times in a row. Only the ID and time fields change. These duplicate messages appear about 450 times each second. Has anyone seen this or does anyone havea solution? Thanks, Andrew Munn an...@nm... |
|
From: Joerg T. <Joe...@ma...> - 2003-10-28 15:48:11
|
Oren Miller wrote: > I'm not sure it is illegal, but I'm sure this behavior is not > recommended as it would cause the counterparty to send more resend > requests. My guess is that while the QF thread is resending messages, > you're app is sending messages blissfully unaware of this state. > > We made need to make QF a little smarter so this situation cannot occur. Oren, do you have any concrete plans or suggestions how to do that? IHMO, the most cleanest way would be to have threads to process incoming and outgoing messages and decouple them from the rest of the logic by some sort of concurrent queues (see my previous suggestion). But I do not know the internal architecture of QuickFIX good enough. Could you give me any clues? Cheers, Jörg > */Joerg Thoennes <Joe...@we...>/* wrote: > > Hi all, > > in our QF 1.5.0 application I noticed the following scenario: > > - Our application (acceptor) was sending unsolicited messages > (ExecutionReports) to the counterparty > > - The counterparty requested a ResendRequest FROM: nnn TO: 0 > > - Our application fulfilled the ResendRequest, but at one point near > the end of the resent messages unsolicited messages with newer > sequence numbers got mixed with the normal flow > > Is that compliant with the FIX spec or may this be a bug in QF? > > Cheers, Jörg > > > > ------------------------------------------------------- > This SF.net email is sponsored by OSDN developer relations > Here's your chance to show off your extensive product knowledge > We want to know what you know. Tell us and you have a chance to win $100 > http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > ------------------------------------------------------------------------ > Do you Yahoo!? > The New Yahoo! Shopping > <http://shopping.yahoo.com/?__yltc=s%3A150000443%2Cd%3A22708228%2Cslk%3Atext%2Csec%3Amail> > - with improved product search -- Joerg Thoennes http://macd.com Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen |
|
From: Brian E. <Br...@ma...> - 2003-10-28 14:58:38
|
This is along the same problem that I am having. The Parser searches for the first '8=' in the buffer. The problem if the beginning of the buffer is not 8=FIX.4.X, it picks up the next 8=, tag, which probably for you was 38=100. I've added an additional log in the parser code, that write to a file immediately after the 'recv'. I've read through the code a half dozen times, and I don't see where it could be getting out of sync. Hopefully the additional logging will give me some clues. -----Original Message----- From: Andrew [mailto:an...@nm...] Sent: Tuesday, October 28, 2003 12:10 AM To: qui...@li... Subject: [Quickfix-developers] 8=100 ??? Any idea how a message with 8=100 could have been created? I have it in my incoming_log. 8=10040=259=244=27.5300000032=031=0.0000000030=N14=06=0.000000001=8 H3C60=20031027-14:02:23150=0151=10010=1548=FIX.4.19=23435=849=SLK56 =SEND-334=51157=u78057852=20031027-14:02:2317=15062502620=039=037=JFZ 0072811=3_71454=155=FDO38=10040=259=244=40.2600000032=031=0.0000000 030=N14=06=0.000000001=8H3C60=20031027-14:02:23150=0151=10010=142 | ------------------------------------------------------- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Andrew <an...@nm...> - 2003-10-28 05:49:13
|
Any idea how a message with 8=3D100 could have been created? I have it = in my incoming_log. 8=3D100=0140=3D2=0159=3D2=0144=3D27.53000000=0132=3D0=0131=3D0.00000000=01= 30=3DN=0114=3D0=016=3D0.00000000=011=3D8 H3C=0160=3D20031027-14:02:23=01150=3D0=01151=3D100=0110=3D154=018=3DFIX.4= .1=019=3D234=0135=3D8=0149=3DSLK=0156 =3DSEND-3=0134=3D511=0157=3Du780578=0152=3D20031027-14:02:23=0117=3D15062= 5026=0120=3D0=0139=3D0=0137=3DJFZ 00728=0111=3D3_714=0154=3D1=0155=3DFDO=0138=3D100=0140=3D2=0159=3D2=0144=3D= 40.26000000=0132=3D0=0131=3D0.0000000 0=0130=3DN=0114=3D0=016=3D0.00000000=011=3D8H3C=0160=3D20031027-14:02:23=01= 150=3D0=01151=3D100=0110=3D142=01 | |
|
From: Andrew M. <an...@nm...> - 2003-10-27 21:46:52
|
Should I be able to do:
org.quickfix.fix41.NewOrderSingle.NoTradingSessions group =
new org.quickfix.fix41.NewOrderSingle.NoTradingSessions();
I can do it w/fix42 but I get unresolved symbol with fix41.
Thanks,
Andrew Munn
-----Original Message-----
From: Miller, Oren [mailto:OM...@ri...]
Sent: Wednesday, October 22, 2003 1:15 PM
To: an...@nm...
Subject: RE: [Quickfix-developers] Need java repeating group example...
Yes, in that case you would use:
org.quickfix.fix41.NewOrderSingle.NoTradingSessions group =
new org.quickfix.fix41.NewOrderSingle.NoTradingSessions();
-----Original Message-----
From: Andrew Munn [mailto:an...@nm...]
Sent: Wednesday, October 22, 2003 12:41 PM
To: Miller, Oren
Subject: RE: [Quickfix-developers] Need java repeating group example...
Oren,
I'm using 4.1. Can it be done in 4.1? (Arca requires it)
Thanks!
-----Original Message-----
From: Miller, Oren [mailto:OM...@ri...]
Sent: Wednesday, October 22, 2003 12:25 PM
To: Andrew; qui...@li...
Subject: RE: [Quickfix-developers] Need java repeating group example...
You should be using:
org.quickfix.fix42.NewOrderSingle.NoTradingSessions group =
new org.quickfix.fix42.NewOrderSingle.NoTradingSessions();
-----Original Message-----
From: Andrew [mailto:an...@nm...]
Sent: Tuesday, October 21, 2003 12:06 PM
To: qui...@li...
Subject: [Quickfix-developers] Need java repeating group example...
Can someone provide an example of java code for use of repeating groups?
I
have already looked at the example containing:
org.quickfix.fix42.MarketDataSnapshotFullRefresh.NoMDEntries group = new
org.quickfix.fix42.MarketDataSnapshotFullRefresh.NoMDEntries();
I need to do something like this:
NoTradingSessions 386 = 3
TradingSessionID 336 = P1
TradingSessionID 336 = P2
TradingSessionID 336 = P3
org.quickfix.field.NoTradingSessions group = new
org.quickfix.field.NoTradingSessions(3); //use this?
NoTradingSessions ts = new NoTradingSessions(3); // Group group = new
Group(386, 0x1); //or this??
org.quickfix.field.TradingSessionID ts =
org.quickfix.field.TradingSessionID( new String("1") );
group.setField( new TradingSessionID( "P1" ) );
newOrderSingle.addGroup(group); group.setField( new
TradingSessionID( "P2" ) );
newOrderSingle.addGroup(group); group.setField( new
TradingSessionID( "P3" ) );
newOrderSingle.addGroup(group);
Thanks for any help on this...
Andrew Munn
-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations Here's your
chance to show off your extensive product knowledge We want to know what you
know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
|
|
From: Andrew <an...@nm...> - 2003-10-27 21:02:32
|
Does anyone know the cause of this? My app crashed and this happens every
time I restart since. Apparently events took place which left the
logs/sequence numbers in a state the engine doesn't like. My counterparty
has sequence numbers of 846:891 but I show 366296:580. So I think there are
two problems, one being that QF was able to enter a state like this in the
first place and the second being that it keeps grabbing more memory until it
dies. My event log follows also. Thanks!
instantiating SocketInitiator 3
Application: onCreate FIX.4.1: SENDER3->SLK
starting initiator 3
initiator3: org.quickfix.ThreadedSocketInitiator@b8f82d
press <enter> to quit
FIX.4.1: SENDER3->SLK toAdmin:
8=FIX.4.1?9=66?35=A?34=366292?49=SENDER3?52=20031027-15:05:57?56=SLK?98=0?10
8=30
?10=026?
FIX.4.1: SENDER3->SLK fromAdmin:
8=FIX.4.1?9=68?35=A?34=879?43=N?49=SLK?52=20031027-15:05:56?56=SENDER3?98=0?
108=
20?10=121?
FIX.4.1: SENDER3->SLK toAdmin:
8=FIX.4.1?9=70?35=2?34=366293?49=SENDER3?52=20031027-15:05:57?56=SLK?7=580?1
6=99
9999?10=251?
Application: onLogon FIX.4.1: SENDER3->SLK
FIX.4.1: SENDER3->SLK fromAdmin:
8=FIX.4.1?9=72?35=2?34=880?43=N?49=SLK?52=20031027-15:05:56?56=SENDER3?7=846
?16=
999999?10=087?
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : unknown exception code (0xe06d7363) occurred at
PC=0x77E7388
7
Function=RaiseException+0x50
Library=C:\WINDOWS\system32\kernel32.dll
Current Java thread:
at org.quickfix.FileStore.get0(Native Method)
at org.quickfix.FileStore.get(Unknown Source)
Dynamic libraries:
0x00400000 - 0x00406000 C:\WINDOWS\system32\java.exe
0x77F50000 - 0x77FF7000 C:\WINDOWS\System32\ntdll.dll
0x77E60000 - 0x77F46000 C:\WINDOWS\system32\kernel32.dll
0x77DD0000 - 0x77E5D000 C:\WINDOWS\system32\ADVAPI32.dll
0x78000000 - 0x78086000 C:\WINDOWS\system32\RPCRT4.dll
0x77C10000 - 0x77C63000 C:\WINDOWS\system32\MSVCRT.dll
0x08000000 - 0x08136000 C:\Program
Files\Java\j2re1.4.2\bin\client\jvm.dll
0x77D40000 - 0x77DC6000 C:\WINDOWS\system32\USER32.dll
0x77C70000 - 0x77CB0000 C:\WINDOWS\system32\GDI32.dll
0x76B40000 - 0x76B6C000 C:\WINDOWS\system32\WINMM.dll
0x6BD00000 - 0x6BD0D000 C:\WINDOWS\system32\SYNCOR11.DLL
0x10000000 - 0x10007000 C:\Program Files\Java\j2re1.4.2\bin\hpi.dll
0x00390000 - 0x0039E000 C:\Program
Files\Java\j2re1.4.2\bin\verify.dll
0x003A0000 - 0x003B8000 C:\Program Files\Java\j2re1.4.2\bin\java.dll
0x003C0000 - 0x003CD000 C:\Program Files\Java\j2re1.4.2\bin\zip.dll
0x02C60000 - 0x02CE3000 C:\javaclasses\quickfix_jni.dll
0x71AB0000 - 0x71AC5000 C:\WINDOWS\system32\WS2_32.dll
0x71AA0000 - 0x71AA8000 C:\WINDOWS\system32\WS2HELP.dll
0x771B0000 - 0x772D1000 C:\WINDOWS\system32\ole32.dll
0x77120000 - 0x771AB000 C:\WINDOWS\system32\OLEAUT32.dll
0x7C3A0000 - 0x7C41B000 C:\WINDOWS\system32\MSVCP71.dll
0x7C340000 - 0x7C396000 C:\WINDOWS\system32\MSVCR71.dll
0x02CF0000 - 0x02D2F000 C:\WINDOWS\system32\LIBMYSQL.dll
0x71AD0000 - 0x71AD8000 C:\WINDOWS\system32\WSOCK32.dll
0x71A50000 - 0x71A8B000 C:\WINDOWS\System32\mswsock.dll
0x76F20000 - 0x76F45000 C:\WINDOWS\system32\DNSAPI.dll
0x76FB0000 - 0x76FB7000 C:\WINDOWS\System32\winrnr.dll
0x76F60000 - 0x76F8C000 C:\WINDOWS\system32\WLDAP32.dll
0x76FC0000 - 0x76FC5000 C:\WINDOWS\system32\rasadhlp.dll
0x71A90000 - 0x71A98000 C:\WINDOWS\System32\wshtcpip.dll
0x76C90000 - 0x76CB2000 C:\WINDOWS\system32\imagehlp.dll
0x6D510000 - 0x6D58D000 C:\WINDOWS\system32\DBGHELP.dll
0x77C00000 - 0x77C07000 C:\WINDOWS\system32\VERSION.dll
0x76BF0000 - 0x76BFB000 C:\WINDOWS\system32\PSAPI.DLL
Heap at VM Abort:
Heap
def new generation total 4544K, used 4543K [0x10010000, 0x104f0000,
0x104f000
0)
eden space 4096K, 99% used [0x10010000, 0x1040fff0, 0x10410000)
from space 448K, 99% used [0x10410000, 0x1047ffd0, 0x10480000)
to space 448K, 0% used [0x10480000, 0x10480000, 0x104f0000)
tenured generation total 60544K, used 60543K [0x104f0000, 0x14010000,
0x14010
000)
the space 60544K, 99% used [0x104f0000, 0x1400ffe0, 0x14010000,
0x14010000)
compacting perm gen total 6912K, used 6718K [0x14010000, 0x146d0000,
0x1801000
0)
the space 6912K, 97% used [0x14010000, 0x1469fa78, 0x1469fc00,
0x146d0000)
Local Time = Mon Oct 27 09:06:11 2003
Elapsed Time = 77
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2-b28 mixed mode)
#
# An error report file has been saved as hs_err_pid2520.log.
# Please refer to the file for further information.
#
<event log>
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1937 to server version: 4.0.14-nt
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> use multifix_out;
Database changed
mysql> select * from event_log where time>'2003-10-27' and
sendercompid='SENDER3';
+--------+---------------------+-------------+--------------+--------------+
---------------------------------------------------------+
| id | time | beginstring | sendercompid | targetcompid |
text |
+--------+---------------------+-------------+--------------+--------------+
---------------------------------------------------------+
| 80371 | 2003-10-27 12:31:01 | FIX.4.1 | SENDER3 | SLK |
Created session |
| 80372 | 2003-10-27 12:31:01 | FIX.4.1 | SENDER3 | SLK |
Connecting to 209.224.162.157 on port 15619 |
| 80373 | 2003-10-27 12:31:01 | FIX.4.1 | SENDER3 | SLK |
Connection succeeded |
| 80374 | 2003-10-27 12:31:01 | FIX.4.1 | SENDER3 | SLK |
Initiated logon request |
| 80375 | 2003-10-27 12:31:01 | FIX.4.1 | SENDER3 | SLK |
Received logon response |
| 80376 | 2003-10-27 14:02:23 | FIX.4.1 | SENDER3 | SLK |
Disconnecting |
| 80377 | 2003-10-27 14:02:23 | FIX.4.1 | SENDER3 | SLK |
Initiated logon request |
| 80378 | 2003-10-27 14:02:23 | FIX.4.1 | SENDER3 | SLK |
Invalid message |
| 80379 | 2003-10-27 14:02:53 | FIX.4.1 | SENDER3 | SLK |
Connecting to 209.224.162.157 on port 15619 |
| 80380 | 2003-10-27 14:02:53 | FIX.4.1 | SENDER3 | SLK |
Connection succeeded |
| 80381 | 2003-10-27 14:02:53 | FIX.4.1 | SENDER3 | SLK |
Initiated logon request |
| 80382 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Received logon response |
| 80383 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 519 EXPECTED: 510 |
| 80384 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 510 TO: 999999 |
| 80385 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Received ResendRequest FROM: 430 TO: 999999 |
| 80386 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Sent SequenceReset TO: 431 |
| 80387 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 431 |
| 80388 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 432 |
| 80389 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 433 |
| 80390 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 434 |
| 80391 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 435 |
| 80392 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 436 |
| 80393 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 437 |
| 80394 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 438 |
| 80395 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 439 |
| 80396 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 440 |
| 80397 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 441 |
| 80398 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 442 |
| 80399 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 443 |
| 80400 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 444 |
| 80401 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 445 |
| 80402 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 446 |
| 80403 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 447 |
| 80404 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 448 |
| 80405 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 449 |
| 80406 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 450 |
| 80407 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 451 |
| 80408 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 452 |
| 80409 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 453 |
| 80410 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 454 |
| 80411 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 455 |
| 80412 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 456 |
| 80413 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 457 |
| 80414 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 458 |
| 80415 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 459 |
| 80416 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 460 |
| 80417 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 461 |
| 80418 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 462 |
| 80419 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 463 |
| 80420 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 464 |
| 80421 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 465 |
| 80422 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 466 |
| 80423 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 467 |
| 80424 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 468 |
| 80425 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 469 |
| 80426 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 470 |
| 80427 | 2003-10-27 14:02:54 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 471 |
| 80428 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 472 |
| 80429 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 473 |
| 80430 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 474 |
| 80431 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 475 |
| 80432 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 476 |
| 80433 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 477 |
| 80434 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 478 |
| 80435 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 479 |
| 80436 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 480 |
| 80437 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 481 |
| 80438 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 482 |
| 80439 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 483 |
| 80440 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 484 |
| 80441 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 485 |
| 80442 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 486 |
| 80443 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 487 |
| 80444 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 488 |
| 80445 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 489 |
| 80446 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Resending Message: 490 |
| 80447 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Sent SequenceReset TO: 493 |
| 80448 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 519 |
| 80449 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 519 EXPECTED: 520 PosDup: Y |
| 80450 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 521 EXPECTED: 520 |
| 80451 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80452 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 522 EXPECTED: 520 |
| 80453 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80454 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 523 EXPECTED: 520 |
| 80455 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80456 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 524 EXPECTED: 520 |
| 80457 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80458 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 525 EXPECTED: 520 |
| 80459 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80460 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 526 EXPECTED: 520 |
| 80461 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80462 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 527 EXPECTED: 520 |
| 80463 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80464 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 528 EXPECTED: 520 |
| 80465 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80466 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 529 EXPECTED: 520 |
| 80467 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80468 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 530 EXPECTED: 520 |
| 80469 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80470 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 531 EXPECTED: 520 |
| 80471 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80472 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 532 EXPECTED: 520 |
| 80473 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80474 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 533 EXPECTED: 520 |
| 80475 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80476 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 534 EXPECTED: 520 |
| 80477 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80478 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 535 EXPECTED: 520 |
| 80479 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80480 | 2003-10-27 14:02:55 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 536 EXPECTED: 520 |
| 80481 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80482 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 537 EXPECTED: 520 |
| 80483 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80484 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 538 EXPECTED: 520 |
| 80485 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80486 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 539 EXPECTED: 520 |
| 80487 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80488 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 540 EXPECTED: 520 |
| 80489 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80490 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 541 EXPECTED: 520 |
| 80491 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80492 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 542 EXPECTED: 520 |
| 80493 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80494 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 543 EXPECTED: 520 |
| 80495 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80496 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 544 EXPECTED: 520 |
| 80497 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80498 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 545 EXPECTED: 520 |
| 80499 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80500 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 546 EXPECTED: 520 |
| 80501 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80502 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 547 EXPECTED: 520 |
| 80503 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80504 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 548 EXPECTED: 520 |
| 80505 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80506 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 549 EXPECTED: 520 |
| 80507 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80508 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 550 EXPECTED: 520 |
| 80509 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80510 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 551 EXPECTED: 520 |
| 80511 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80512 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 552 EXPECTED: 520 |
| 80513 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80514 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 553 EXPECTED: 520 |
| 80515 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80516 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 554 EXPECTED: 520 |
| 80517 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80518 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 555 EXPECTED: 520 |
| 80519 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80520 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 556 EXPECTED: 520 |
| 80521 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80522 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 557 EXPECTED: 520 |
| 80523 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80524 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 558 EXPECTED: 520 |
| 80525 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80526 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 559 EXPECTED: 520 |
| 80527 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80528 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 560 EXPECTED: 520 |
| 80529 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80530 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 561 EXPECTED: 520 |
| 80531 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80532 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 562 EXPECTED: 520 |
| 80533 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80534 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 563 EXPECTED: 520 |
| 80535 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80536 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 564 EXPECTED: 520 |
| 80537 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80538 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 565 EXPECTED: 520 |
| 80539 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80540 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 566 EXPECTED: 520 |
| 80541 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80542 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 567 EXPECTED: 520 |
| 80543 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80544 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 568 EXPECTED: 520 |
| 80545 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80546 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 569 EXPECTED: 520 |
| 80547 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80548 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 570 EXPECTED: 520 |
| 80549 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80550 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 571 EXPECTED: 520 |
| 80551 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80552 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 572 EXPECTED: 520 |
| 80553 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80554 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 573 EXPECTED: 520 |
| 80555 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80556 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 574 EXPECTED: 520 |
| 80557 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80558 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 575 EXPECTED: 520 |
| 80559 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80560 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 576 EXPECTED: 520 |
| 80561 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80562 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 577 EXPECTED: 520 |
| 80563 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80564 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 578 EXPECTED: 520 |
| 80565 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80566 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too high RECEIVED: 579 EXPECTED: 520 |
| 80567 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Sent ResendRequest FROM: 520 TO: 999999 |
| 80568 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Received SequenceReset FROM: 520 TO: 521 |
| 80569 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 521 |
| 80570 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 522 |
| 80571 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 523 |
| 80572 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 524 |
| 80573 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 525 |
| 80574 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 526 |
| 80575 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 527 |
| 80576 | 2003-10-27 14:02:56 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 528 |
| 80577 | 2003-10-27 14:02:57 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 529 |
| 80578 | 2003-10-27 14:02:57 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 530 |
| 80579 | 2003-10-27 14:02:57 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 531 |
| 80580 | 2003-10-27 14:02:57 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 532 |
| 80581 | 2003-10-27 14:02:57 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 533 |
| 80582 | 2003-10-27 14:02:57 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 534 |
| 80583 | 2003-10-27 14:02:57 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 535 |
| 80584 | 2003-10-27 14:02:57 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 536 |
| 80585 | 2003-10-27 14:02:57 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 537 |
| 80586 | 2003-10-27 14:02:57 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 538 |
| 80587 | 2003-10-27 14:02:57 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 539 |
| 80588 | 2003-10-27 14:02:57 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 540 |
| 80589 | 2003-10-27 14:02:57 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 541 |
| 80590 | 2003-10-27 14:02:57 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 542 |
| 80591 | 2003-10-27 14:02:57 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 543 |
| 80592 | 2003-10-27 14:02:57 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 544 |
| 80593 | 2003-10-27 14:02:57 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 545 |
| 80594 | 2003-10-27 14:02:57 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 546 |
| 80595 | 2003-10-27 14:02:57 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 547 |
| 80596 | 2003-10-27 14:02:57 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 548 |
| 80597 | 2003-10-27 14:02:57 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 549 |
| 80598 | 2003-10-27 14:02:57 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 550 |
| 80599 | 2003-10-27 14:02:57 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 551 |
| 80600 | 2003-10-27 14:02:58 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 552 |
| 80601 | 2003-10-27 14:02:58 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 553 |
| 80602 | 2003-10-27 14:02:58 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 554 |
| 80603 | 2003-10-27 14:02:58 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 555 |
| 80604 | 2003-10-27 14:02:58 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 556 |
| 80605 | 2003-10-27 14:02:58 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 557 |
| 80606 | 2003-10-27 14:02:58 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 558 |
| 80607 | 2003-10-27 14:02:58 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 559 |
| 80608 | 2003-10-27 14:02:58 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 560 |
| 80609 | 2003-10-27 14:02:58 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 561 |
| 80610 | 2003-10-27 14:02:58 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 562 |
| 80611 | 2003-10-27 14:02:58 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 563 |
| 80612 | 2003-10-27 14:02:58 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 564 |
| 80613 | 2003-10-27 14:02:58 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 565 |
| 80614 | 2003-10-27 14:02:58 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 566 |
| 80615 | 2003-10-27 14:02:58 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 567 |
| 80616 | 2003-10-27 14:02:58 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 568 |
| 80617 | 2003-10-27 14:02:58 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 569 |
| 80618 | 2003-10-27 14:02:58 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 570 |
| 80619 | 2003-10-27 14:02:58 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 571 |
| 80620 | 2003-10-27 14:02:58 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 572 |
| 80621 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 573 |
| 80622 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 574 |
| 80623 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 575 |
| 80624 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 576 |
| 80625 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 577 |
| 80626 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 578 |
| 80627 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
Processing QUEUED message: 579 |
| 80628 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 521 EXPECTED: 580 PosDup: Y |
| 80629 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 522 EXPECTED: 580 PosDup: Y |
| 80630 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 523 EXPECTED: 580 PosDup: Y |
| 80631 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 524 EXPECTED: 580 PosDup: Y |
| 80632 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 525 EXPECTED: 580 PosDup: Y |
| 80633 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 526 EXPECTED: 580 PosDup: Y |
| 80634 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 527 EXPECTED: 580 PosDup: Y |
| 80635 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 528 EXPECTED: 580 PosDup: Y |
| 80636 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 529 EXPECTED: 580 PosDup: Y |
| 80637 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 530 EXPECTED: 580 PosDup: Y |
| 80638 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 531 EXPECTED: 580 PosDup: Y |
| 80639 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 532 EXPECTED: 580 PosDup: Y |
| 80640 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 533 EXPECTED: 580 PosDup: Y |
| 80641 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 534 EXPECTED: 580 PosDup: Y |
| 80642 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 535 EXPECTED: 580 PosDup: Y |
| 80643 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 536 EXPECTED: 580 PosDup: Y |
| 80644 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 537 EXPECTED: 580 PosDup: Y |
| 80645 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 538 EXPECTED: 580 PosDup: Y |
| 80646 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 539 EXPECTED: 580 PosDup: Y |
| 80647 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 540 EXPECTED: 580 PosDup: Y |
| 80648 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 541 EXPECTED: 580 PosDup: Y |
| 80649 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 542 EXPECTED: 580 PosDup: Y |
| 80650 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 543 EXPECTED: 580 PosDup: Y |
| 80651 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 544 EXPECTED: 580 PosDup: Y |
| 80652 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 545 EXPECTED: 580 PosDup: Y |
| 80653 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 546 EXPECTED: 580 PosDup: Y |
| 80654 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 547 EXPECTED: 580 PosDup: Y |
| 80655 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 548 EXPECTED: 580 PosDup: Y |
| 80656 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 549 EXPECTED: 580 PosDup: Y |
| 80657 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 550 EXPECTED: 580 PosDup: Y |
| 80658 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 551 EXPECTED: 580 PosDup: Y |
| 80659 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 552 EXPECTED: 580 PosDup: Y |
| 80660 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 553 EXPECTED: 580 PosDup: Y |
| 80661 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 554 EXPECTED: 580 PosDup: Y |
| 80662 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 555 EXPECTED: 580 PosDup: Y |
| 80663 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 556 EXPECTED: 580 PosDup: Y |
| 80664 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 557 EXPECTED: 580 PosDup: Y |
| 80665 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 558 EXPECTED: 580 PosDup: Y |
| 80666 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 559 EXPECTED: 580 PosDup: Y |
| 80667 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 560 EXPECTED: 580 PosDup: Y |
| 80668 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 561 EXPECTED: 580 PosDup: Y |
| 80669 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 562 EXPECTED: 580 PosDup: Y |
| 80670 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 563 EXPECTED: 580 PosDup: Y |
| 80671 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 564 EXPECTED: 580 PosDup: Y |
| 80672 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 565 EXPECTED: 580 PosDup: Y |
| 80673 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 566 EXPECTED: 580 PosDup: Y |
| 80674 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 567 EXPECTED: 580 PosDup: Y |
| 80675 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 568 EXPECTED: 580 PosDup: Y |
| 80676 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 569 EXPECTED: 580 PosDup: Y |
| 80677 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 570 EXPECTED: 580 PosDup: Y |
| 80678 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 571 EXPECTED: 580 PosDup: Y |
| 80679 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 572 EXPECTED: 580 PosDup: Y |
| 80680 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 573 EXPECTED: 580 PosDup: Y |
| 80681 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 574 EXPECTED: 580 PosDup: Y |
| 80682 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 575 EXPECTED: 580 PosDup: Y |
| 80683 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 576 EXPECTED: 580 PosDup: Y |
| 80684 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 577 EXPECTED: 580 PosDup: Y |
| 80685 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 578 EXPECTED: 580 PosDup: Y |
| 80686 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 579 EXPECTED: 580 PosDup: Y |
| 80687 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
Received SequenceReset FROM: 580 TO: 580 |
| 80688 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 520 EXPECTED: 580 PosDup: Y |
| 80689 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 521 EXPECTED: 580 PosDup: Y |
| 80690 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 522 EXPECTED: 580 PosDup: Y |
| 80691 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 523 EXPECTED: 580 PosDup: Y |
| 80692 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 524 EXPECTED: 580 PosDup: Y |
| 80693 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 525 EXPECTED: 580 PosDup: Y |
| 80694 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 526 EXPECTED: 580 PosDup: Y |
| 80695 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 527 EXPECTED: 580 PosDup: Y |
| 80696 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 528 EXPECTED: 580 PosDup: Y |
| 80697 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 529 EXPECTED: 580 PosDup: Y |
| 80698 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 530 EXPECTED: 580 PosDup: Y |
| 80699 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 531 EXPECTED: 580 PosDup: Y |
| 80700 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 532 EXPECTED: 580 PosDup: Y |
| 80701 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 533 EXPECTED: 580 PosDup: Y |
| 80702 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 534 EXPECTED: 580 PosDup: Y |
| 80703 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 535 EXPECTED: 580 PosDup: Y |
| 80704 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 536 EXPECTED: 580 PosDup: Y |
| 80705 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 537 EXPECTED: 580 PosDup: Y |
| 80706 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 538 EXPECTED: 580 PosDup: Y |
| 80707 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 539 EXPECTED: 580 PosDup: Y |
| 80708 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 540 EXPECTED: 580 PosDup: Y |
| 80709 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 541 EXPECTED: 580 PosDup: Y |
| 80710 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 542 EXPECTED: 580 PosDup: Y |
| 80711 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 543 EXPECTED: 580 PosDup: Y |
| 80712 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 544 EXPECTED: 580 PosDup: Y |
| 80713 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 545 EXPECTED: 580 PosDup: Y |
| 80714 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 546 EXPECTED: 580 PosDup: Y |
| 80715 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 547 EXPECTED: 580 PosDup: Y |
| 80716 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 548 EXPECTED: 580 PosDup: Y |
| 80717 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 549 EXPECTED: 580 PosDup: Y |
| 80718 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 550 EXPECTED: 580 PosDup: Y |
| 80719 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 551 EXPECTED: 580 PosDup: Y |
| 80720 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 552 EXPECTED: 580 PosDup: Y |
| 80721 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 553 EXPECTED: 580 PosDup: Y |
| 80722 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 554 EXPECTED: 580 PosDup: Y |
| 80723 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 555 EXPECTED: 580 PosDup: Y |
| 80724 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 556 EXPECTED: 580 PosDup: Y |
| 80725 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 557 EXPECTED: 580 PosDup: Y |
| 80726 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 558 EXPECTED: 580 PosDup: Y |
| 80727 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 559 EXPECTED: 580 PosDup: Y |
| 80728 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 560 EXPECTED: 580 PosDup: Y |
| 80729 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 561 EXPECTED: 580 PosDup: Y |
| 80730 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 562 EXPECTED: 580 PosDup: Y |
| 80731 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 563 EXPECTED: 580 PosDup: Y |
| 80732 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 564 EXPECTED: 580 PosDup: Y |
| 80733 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 565 EXPECTED: 580 PosDup: Y |
| 80734 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 566 EXPECTED: 580 PosDup: Y |
| 80735 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 567 EXPECTED: 580 PosDup: Y |
| 80736 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 568 EXPECTED: 580 PosDup: Y |
| 80737 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 569 EXPECTED: 580 PosDup: Y |
| 80738 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 570 EXPECTED: 580 PosDup: Y |
| 80739 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 571 EXPECTED: 580 PosDup: Y |
| 80740 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 572 EXPECTED: 580 PosDup: Y |
| 80741 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 573 EXPECTED: 580 PosDup: Y |
| 80742 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 574 EXPECTED: 580 PosDup: Y |
| 80743 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 575 EXPECTED: 580 PosDup: Y |
| 80744 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 576 EXPECTED: 580 PosDup: Y |
| 80745 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 577 EXPECTED: 580 PosDup: Y |
| 80746 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 578 EXPECTED: 580 PosDup: Y |
| 80747 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 579 EXPECTED: 580 PosDup: Y |
| 80748 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
Received SequenceReset FROM: 580 TO: 580 |
| 80749 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 520 EXPECTED: 580 PosDup: Y |
| 80750 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 521 EXPECTED: 580 PosDup: Y |
| 80751 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 522 EXPECTED: 580 PosDup: Y |
| 80752 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 523 EXPECTED: 580 PosDup: Y |
| 80753 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 524 EXPECTED: 580 PosDup: Y |
| 80754 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 525 EXPECTED: 580 PosDup: Y |
| 80755 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 526 EXPECTED: 580 PosDup: Y |
| 80756 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 527 EXPECTED: 580 PosDup: Y |
| 80757 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 528 EXPECTED: 580 PosDup: Y |
| 80758 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 529 EXPECTED: 580 PosDup: Y |
| 80759 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 530 EXPECTED: 580 PosDup: Y |
| 80760 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 531 EXPECTED: 580 PosDup: Y |
| 80761 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 532 EXPECTED: 580 PosDup: Y |
| 80762 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 533 EXPECTED: 580 PosDup: Y |
| 80763 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 534 EXPECTED: 580 PosDup: Y |
| 80764 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 535 EXPECTED: 580 PosDup: Y |
| 80765 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 536 EXPECTED: 580 PosDup: Y |
| 80766 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 537 EXPECTED: 580 PosDup: Y |
| 80767 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 538 EXPECTED: 580 PosDup: Y |
| 80768 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 539 EXPECTED: 580 PosDup: Y |
| 80769 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 540 EXPECTED: 580 PosDup: Y |
| 80770 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 541 EXPECTED: 580 PosDup: Y |
| 80771 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 542 EXPECTED: 580 PosDup: Y |
| 80772 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 543 EXPECTED: 580 PosDup: Y |
| 80773 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 544 EXPECTED: 580 PosDup: Y |
| 80774 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 545 EXPECTED: 580 PosDup: Y |
| 80775 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 546 EXPECTED: 580 PosDup: Y |
| 80776 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 547 EXPECTED: 580 PosDup: Y |
| 80777 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 548 EXPECTED: 580 PosDup: Y |
| 80778 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 549 EXPECTED: 580 PosDup: Y |
| 80779 | 2003-10-27 14:02:59 | FIX.4.1 | SENDER3 | SLK |
MsgSeqNum too low RECEIVED: 550 EXPECTED: 580 PosDup: Y |
| 807...
[truncated message content] |
|
From: Brian E. <Br...@ma...> - 2003-10-27 19:16:12
|
Today I received some messages which raises a BodyLength/CheckSum error, and
I have some additional logging.
Here's a section of my log:
20031027-15:00:53 : BodyLength or CheckSum missing
20031027-15:00:53 : InvalidMessage caught in SocketConnection::read.
BodyLength or CheckSum missing The message is: ''
In SocketConnection::read I added this handler:
catch ( InvalidMessage& e)
{
std::string errmsg("InvalidMessage caught in
SocketConnection::read. ");
errmsg += e.what();
errmsg += " The message is: '";
errmsg += msg;
errmsg += "'";
m_pSession->getLog()->onEvent( errmsg );
std::cout << errmsg << std::endl;
if ( !m_pSession->isLoggedOn() )
s.getMonitor().drop( m_socket );
}
So, within SocketConnection::read, I am getting an empty message. I'm not
quite sure where this is coming from, but my message store shows several
areas of empty lines.
One possible cause might be in 'SocketConnection::readMessage'
try
{
return m_parser.readFixMessage( msg );
}
catch ( MessageParseError& ) {}
return true;
It would seem to me that this should return 'false' if an error is handled.
I seem to only get this error when there is high message volume occuring.
I'm not sure if this is related to QuickFix or the venue that I'm connecting
to.
-----Original Message-----
From: Miller, Oren [mailto:OM...@ri...]
Sent: Tuesday, October 14, 2003 6:02 PM
To: Br...@ma...; qui...@li...
Subject: Re: [Quickfix-developers] BodyLength or CheckSum missing
Do yo have an example of a message that causes this error?
--------------------------
Sent from my BlackBerry Wireless Handheld
-----Original Message-----
From: Brian Egge <Br...@ma...>
To: qui...@li...
<qui...@li...>
Sent: Tue Oct 14 10:10:55 2003
Subject: [Quickfix-developers] BodyLength or CheckSum missing
I seem to be having a problem where I get an InvalidMessage("BodyLength or
CheckSum missing") exception thrown from Message::validate(). When I look
at my logs, or even re-parse the message, everything is in tact. I can't
see any reason why this exception is being thrown. I only get this with one
venue, and it only happens every couple of days or so. Has anyone else had
this problem before?
I've added some more logging to this area, and I think I will figure it out
soon. The item that concerns me more is that this exception does not get
handled, and the EH eventually calls terminate() or abort() and the program
ends. I'm using version 1.6, and I have two suggestions.
1) "bool SocketConnection::read( SocketAcceptor& a, SocketServer& s )" has
an exception handler, while bool "SocketConnection::read( SocketConnector& s
)" does not. My exception occurs in the latter case. I copied the
exception code from the one read to the other to make them consistent.
2) I added try {} catch(...) statement to the onStart() procedures, to trap
any unhanded exceptions. I'd rather have the thread safely terminate than
for my whole app to end.
If these changes are worthwhile, I'll try to merge them in CVS.
-Brian
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
|
|
From: Oren M. <ore...@ya...> - 2003-10-27 15:34:10
|
Could you post the relevant section of your logs? This would help to show the sequence of events that could illuminate what is happening. pc....@ta... wrote:Hi, Im using QF 1.5.0, java version. During integration with my second client I'm noticing a logon problem. Basically I logon, get a logon reply from server, and a test message, I send market data requests, then start getting market data repsonses. However QF does not pass me the "market data responses" as it does not seem to have finished its logon process. Looking at the logs when I get subsequent "Heartbeat" messages it is expecting the heartbeat to be "sequence no=3" and sends a resend request, where as the heartbeat is something like 40 after the market data responses. Anyone have any ideas or has anyone had a similar problem? Many Thanks Phil. _________________________________ Email: pc....@ta... -------------------- talk21 your FREE portable and private address on the net at http://www.talk21.com ------------------------------------------------------- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers --------------------------------- Do you Yahoo!? Exclusive Video Premiere - Britney Spears |
|
From: <pc....@ta...> - 2003-10-27 15:13:43
|
Hi, Im=20using=20QF=201.5.0,=20java=20version.=20=20During=20integration=20with=20my=20second=20client=20I'm=20noticing=20a=20logon=20problem. Basically=20I=20logon,=20get=20a=20logon=20reply=20from=20server,=20and=20a=20test=20message,=20I=20send=20market=20data=20requests,=20then=20start=20getting=20market=20data=20repsonses. However=20QF=20does=20not=20pass=20me=20the=20"market=20data=20responses"=20as=20it=20does=20not=20seem=20to=20have=20finished=20its=20logon=20process.=20=20=20Looking=20at=20the=20logs=20when=20I=20get=20subsequent=20"Heartbeat"=20messages=20it=20is=20expecting=20the=20heartbeat=20to=20be=20"sequence=20no=3D3"=20and=20sends=20a=20resend=20request,=20where=20as=20the=20heartbeat=20is=20something=20like=2040=20after=20the=20market=20data=20responses. Anyone=20have=20any=20ideas=20or=20has=20anyone=20had=20a=20similar=20problem=3F Many=20Thanks Phil. _________________________________ Email:=20p...@ta... -------------------- talk21=20your=20FREE=20portable=20and=20private=20address=20on=20the=20net=20at=20http://www.talk21.com |
|
From: Miller, O. <OM...@ri...> - 2003-10-27 14:15:14
|
Well there really isn't much of an option here because fix doesn't allow = processing of new messages until all previous sequence numbers are = accounted for. Either by a message being sent or a gap fill. Sending a new message first would only cause the other party to send = another resend request doubling the resend traffic. -------------------------- Sent from my BlackBerry Wireless Handheld -----Original Message----- From: Peter Krause <kra...@ho...> To: qui...@li... = <qui...@li...> Sent: Thu Oct 23 07:50:49 2003 Subject: Re: [Quickfix-developers] Out-of-order sequence numbers I dunno -- there are all sorts of messages, order cancelations and = possibly=20 new orders, for example, that should trump recap messages (particularly = if a=20 large recap would then delay the cancelation or oder). This might be the sort of decision that each application would want to = make=20 for itself... What do the rest of you think? thanks, pk >From: Oren Miller <ore...@ya...> >To: Joe...@we..., developers QuickFIX=20 ><qui...@li...> >Subject: Re: [Quickfix-developers] Out-of-order sequence numbers >Date: Wed, 22 Oct 2003 09:45:03 -0700 (PDT) > >I'm not sure it is illegal, but I'm sure this behavior is not = recommended=20 >as it would cause the counterparty to send more resend requests. My = guess=20 >is that while the QF thread is resending messages, you're app is = sending=20 >messages blissfully unaware of this state. > >We made need to make QF a little smarter so this situation cannot = occur. > >Joerg Thoennes <Joe...@we...> wrote: >Hi all, > >in our QF 1.5.0 application I noticed the following scenario: > >- Our application (acceptor) was sending unsolicited messages >(ExecutionReports) to the counterparty > >- The counterparty requested a ResendRequest FROM: nnn TO: 0 > >- Our application fulfilled the ResendRequest, but at one point near >the end of the resent messages unsolicited messages with newer >sequence numbers got mixed with the normal flow > >Is that compliant with the FIX spec or may this be a bug in QF? > >Cheers, J=F6rg > > > >------------------------------------------------------- >This SF.net email is sponsored by OSDN developer relations >Here's your chance to show off your extensive product knowledge >We want to know what you know. Tell us and you have a chance to win = $100 >http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 >_______________________________________________ >Quickfix-developers mailing list >Qui...@li... >https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > >--------------------------------- >Do you Yahoo!? >The New Yahoo! Shopping - with improved product search >From: Oren Miller <ore...@ya...> >To: Joe...@we..., developers QuickFIX=20 ><qui...@li...> >Subject: Re: [Quickfix-developers] Out-of-order sequence numbers >Date: Wed, 22 Oct 2003 09:45:03 -0700 (PDT) > >I'm not sure it is illegal, but I'm sure this behavior is not = recommended=20 >as it would cause the counterparty to send more resend requests. My = guess=20 >is that while the QF thread is resending messages, you're app is = sending=20 >messages blissfully unaware of this state. > >We made need to make QF a little smarter so this situation cannot = occur. > >Joerg Thoennes <Joe...@we...> wrote: >Hi all, > >in our QF 1.5.0 application I noticed the following scenario: > >- Our application (acceptor) was sending unsolicited messages >(ExecutionReports) to the counterparty > >- The counterparty requested a ResendRequest FROM: nnn TO: 0 > >- Our application fulfilled the ResendRequest, but at one point near >the end of the resent messages unsolicited messages with newer >sequence numbers got mixed with the normal flow > >Is that compliant with the FIX spec or may this be a bug in QF? > >Cheers, J=F6rg > > > >------------------------------------------------------- >This SF.net email is sponsored by OSDN developer relations >Here's your chance to show off your extensive product knowledge >We want to know what you know. Tell us and you have a chance to win = $100 >http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 >_______________________________________________ >Quickfix-developers mailing list >Qui...@li... >https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > >--------------------------------- >Do you Yahoo!? >The New Yahoo! Shopping - with improved product search _________________________________________________________________ Want to check if your PC is virus-infected? Get a FREE computer virus = scan=20 online from McAfee. =20 http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3D3963 ------------------------------------------------------- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Peter K. <kra...@ho...> - 2003-10-25 06:44:03
|
I dunno -- there are all sorts of messages, order cancelations and possibly new orders, for example, that should trump recap messages (particularly if a large recap would then delay the cancelation or oder). This might be the sort of decision that each application would want to make for itself... What do the rest of you think? thanks, pk >From: Oren Miller <ore...@ya...> >To: Joe...@we..., developers QuickFIX ><qui...@li...> >Subject: Re: [Quickfix-developers] Out-of-order sequence numbers >Date: Wed, 22 Oct 2003 09:45:03 -0700 (PDT) > >I'm not sure it is illegal, but I'm sure this behavior is not recommended >as it would cause the counterparty to send more resend requests. My guess >is that while the QF thread is resending messages, you're app is sending >messages blissfully unaware of this state. > >We made need to make QF a little smarter so this situation cannot occur. > >Joerg Thoennes <Joe...@we...> wrote: >Hi all, > >in our QF 1.5.0 application I noticed the following scenario: > >- Our application (acceptor) was sending unsolicited messages >(ExecutionReports) to the counterparty > >- The counterparty requested a ResendRequest FROM: nnn TO: 0 > >- Our application fulfilled the ResendRequest, but at one point near >the end of the resent messages unsolicited messages with newer >sequence numbers got mixed with the normal flow > >Is that compliant with the FIX spec or may this be a bug in QF? > >Cheers, Jörg > > > >------------------------------------------------------- >This SF.net email is sponsored by OSDN developer relations >Here's your chance to show off your extensive product knowledge >We want to know what you know. Tell us and you have a chance to win $100 >http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 >_______________________________________________ >Quickfix-developers mailing list >Qui...@li... >https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > >--------------------------------- >Do you Yahoo!? >The New Yahoo! Shopping - with improved product search >From: Oren Miller <ore...@ya...> >To: Joe...@we..., developers QuickFIX ><qui...@li...> >Subject: Re: [Quickfix-developers] Out-of-order sequence numbers >Date: Wed, 22 Oct 2003 09:45:03 -0700 (PDT) > >I'm not sure it is illegal, but I'm sure this behavior is not recommended >as it would cause the counterparty to send more resend requests. My guess >is that while the QF thread is resending messages, you're app is sending >messages blissfully unaware of this state. > >We made need to make QF a little smarter so this situation cannot occur. > >Joerg Thoennes <Joe...@we...> wrote: >Hi all, > >in our QF 1.5.0 application I noticed the following scenario: > >- Our application (acceptor) was sending unsolicited messages >(ExecutionReports) to the counterparty > >- The counterparty requested a ResendRequest FROM: nnn TO: 0 > >- Our application fulfilled the ResendRequest, but at one point near >the end of the resent messages unsolicited messages with newer >sequence numbers got mixed with the normal flow > >Is that compliant with the FIX spec or may this be a bug in QF? > >Cheers, Jörg > > > >------------------------------------------------------- >This SF.net email is sponsored by OSDN developer relations >Here's your chance to show off your extensive product knowledge >We want to know what you know. Tell us and you have a chance to win $100 >http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 >_______________________________________________ >Quickfix-developers mailing list >Qui...@li... >https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > >--------------------------------- >Do you Yahoo!? >The New Yahoo! Shopping - with improved product search _________________________________________________________________ Want to check if your PC is virus-infected? Get a FREE computer virus scan online from McAfee. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 |
|
From: Joerg T. <Joe...@ma...> - 2003-10-24 10:46:54
|
Hi all,
does anybody know the CVS release tag for QF 1.6.0?
cvs upd -rRELEASE_1_6_0
did fails with
cvs [server aborted]: no such tag RELEASE_1_6_0
Thanks, Jörg
--
Joerg Thoennes
http://macd.com
Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH
Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen
|
|
From: Van G. E. (K. 2) <edd...@cr...> - 2003-10-24 00:35:51
|
Hi, has anyone managed to get the JAVA version of quickfix 1.6 ( compiled with the SUN 5.3 compiler and STLport 4.5.3 ) running on Solaris 2.8 ?? My C++ version is running fine, but the java version crashes with : An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0xF21051C0 Function=__1cE_STLGlocale2t5B6M_v_+0x28 Library=/usr/local/lib/lib/libstlport_sunpro.so.4.5 Any ideas ? Best Regards, Eddy Van Gelder |
|
From: Daniel M. <Dan...@ma...> - 2003-10-23 18:51:41
|
Oren, I have made several code changes to QuickFix for milliseconds in UTCTimeStamp. How do I go about checking these in ? Daniel May |
|
From: Conrad, T. <Co...@KF...> - 2003-10-23 17:43:59
|
This isn't specifically related to QuickFIX but does anyone have a technical explanation for the EUREX problem this morning? (I've heard that all non-unix houses were not able to connect to EUREX in the morning so they delayed the opening of the exchange). Thanks, Ted Conrad |
98 messages has been excluded from this view by a project administrator.
