Menu
▾
▴
quickfixj-users — General mailing list for QuickFIX/J topics.
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(13) |
Jun
(21) |
Jul
(14) |
Aug
(29) |
Sep
(39) |
Oct
(47) |
Nov
(70) |
Dec
(27) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(43) |
Feb
(50) |
Mar
(90) |
Apr
(96) |
May
(84) |
Jun
(40) |
Jul
(58) |
Aug
(55) |
Sep
(55) |
Oct
(52) |
Nov
(38) |
Dec
(75) |
| 2008 |
Jan
(49) |
Feb
(72) |
Mar
(49) |
Apr
(55) |
May
(21) |
Jun
(31) |
Jul
(47) |
Aug
(59) |
Sep
(59) |
Oct
(77) |
Nov
(51) |
Dec
(54) |
| 2009 |
Jan
(52) |
Feb
(57) |
Mar
(17) |
Apr
(27) |
May
(44) |
Jun
(46) |
Jul
(69) |
Aug
(38) |
Sep
(39) |
Oct
(45) |
Nov
(38) |
Dec
(37) |
| 2010 |
Jan
(49) |
Feb
(35) |
Mar
(21) |
Apr
(33) |
May
(52) |
Jun
(28) |
Jul
(39) |
Aug
(34) |
Sep
(21) |
Oct
(82) |
Nov
(36) |
Dec
(20) |
| 2011 |
Jan
(28) |
Feb
(64) |
Mar
(93) |
Apr
(75) |
May
(151) |
Jun
(77) |
Jul
(35) |
Aug
(53) |
Sep
(56) |
Oct
(36) |
Nov
(94) |
Dec
(59) |
| 2012 |
Jan
(105) |
Feb
(43) |
Mar
(68) |
Apr
(91) |
May
(45) |
Jun
(18) |
Jul
(103) |
Aug
(77) |
Sep
(45) |
Oct
(59) |
Nov
(58) |
Dec
(43) |
| 2013 |
Jan
(48) |
Feb
(65) |
Mar
(63) |
Apr
(22) |
May
(41) |
Jun
(60) |
Jul
(43) |
Aug
(17) |
Sep
(20) |
Oct
(20) |
Nov
(42) |
Dec
(43) |
| 2014 |
Jan
(54) |
Feb
(34) |
Mar
(34) |
Apr
(20) |
May
(31) |
Jun
(39) |
Jul
(66) |
Aug
(22) |
Sep
(52) |
Oct
(22) |
Nov
(67) |
Dec
(70) |
| 2015 |
Jan
(18) |
Feb
(5) |
Mar
(40) |
Apr
(32) |
May
(62) |
Jun
(28) |
Jul
(86) |
Aug
(44) |
Sep
(61) |
Oct
(65) |
Nov
(8) |
Dec
(19) |
| 2016 |
Jan
(50) |
Feb
(22) |
Mar
(38) |
Apr
(55) |
May
(30) |
Jun
(42) |
Jul
(11) |
Aug
(9) |
Sep
(4) |
Oct
(51) |
Nov
(38) |
Dec
(31) |
| 2017 |
Jan
(40) |
Feb
(40) |
Mar
(23) |
Apr
(35) |
May
(121) |
Jun
(55) |
Jul
(37) |
Aug
(16) |
Sep
(27) |
Oct
(109) |
Nov
(67) |
Dec
(23) |
| 2018 |
Jan
(52) |
Feb
(6) |
Mar
(23) |
Apr
(28) |
May
(32) |
Jun
(20) |
Jul
(20) |
Aug
(22) |
Sep
(8) |
Oct
(33) |
Nov
(32) |
Dec
(13) |
| 2019 |
Jan
(16) |
Feb
(29) |
Mar
(17) |
Apr
(16) |
May
(1) |
Jun
(2) |
Jul
(25) |
Aug
(50) |
Sep
(17) |
Oct
(29) |
Nov
(16) |
Dec
(7) |
| 2020 |
Jan
|
Feb
|
Mar
(29) |
Apr
(64) |
May
(25) |
Jun
(49) |
Jul
(15) |
Aug
(10) |
Sep
(37) |
Oct
(20) |
Nov
(19) |
Dec
(9) |
| 2021 |
Jan
(33) |
Feb
(10) |
Mar
(67) |
Apr
(40) |
May
(70) |
Jun
(33) |
Jul
(14) |
Aug
(10) |
Sep
|
Oct
(7) |
Nov
(6) |
Dec
(16) |
| 2022 |
Jan
(27) |
Feb
(2) |
Mar
(5) |
Apr
(3) |
May
|
Jun
(2) |
Jul
|
Aug
(1) |
Sep
(6) |
Oct
(2) |
Nov
|
Dec
(10) |
| 2023 |
Jan
(1) |
Feb
(2) |
Mar
(21) |
Apr
(3) |
May
(15) |
Jun
(3) |
Jul
(4) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
(1) |
| 2024 |
Jan
(7) |
Feb
(2) |
Mar
(8) |
Apr
(11) |
May
(6) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2025 |
Jan
(10) |
Feb
(4) |
Mar
(9) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Toli K. <to...@ma...> - 2006-09-29 01:58:20
|
Steve, I'm still working on this, but i got a work project that took priority. i'll come back to this next week and post a version. On 9/24/06, Steve Bate <st...@te...> wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > Hi Toli, > > I'm open to adding more configuration to the JdbcLogFactory. > If you'd like prototype the changes, that would be great. If > you had some related unit tests that would be > even better. ;-) In the longer term, I'd like to have a > general FIX message to relational table mapping capability > so that, for example, NewOrderSingle could be mapped to > an application-specific database structure with columns > for whichever fields are important to that specific > application. The database logger would be implemented as > a special case usage of this mapping framework. > > I'll be on the road on Monday, so I'll watch for other > comments when I return on Tuesday. > > Steve > > > -----Original Message----- > > From: qui...@li... > > [mailto:qui...@li...] On > > Behalf Of Toli Kuznets > > Sent: Saturday, September 23, 2006 2:49 AM > > To: qui...@li... > > Subject: [Quickfixj-users] RFE: Making LogFactories more confgurable > > > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > QuickFIX/J Support: http://www.quickfixj.org/support/ Hey everyone, > > > > We are thinking of using the JdbcLogFactory to save some of > > the FIX messages to the database. > > (side question: anybody ever tested throughput/efficiency of > > that logger?) > > > > However, compared to the ScreenLogFactory, the Jdbc and Mysql > > loggers are very bare-bones and not configurable. for > > example, the target table names where the messages are placed > > are hard-coded (see the rfe at > > http://www.quickfixj.org/jira/browse/QFJ-75 > > > > Does anybody have any thoughts on improving the other loggers? > > Currently, there are 4 vars for configuring ScreenLogFactory > > that turn on/off some printing. > > We'd like to have similar ones for the JDBC logger as well - > > which would mean 4 more similar variables. > > > > I'd be happy to prototype the new changes, and submit a patch > > for review. Any thoughts/considerations before i do that? > > > > In production, we'll most likely use a CompositeLogFactory, > > which will output to the screen and/or DB depending on which > > configs are specified. However, we may want to have different > > output going to each, hence the need for parallel config parameters. > > > > looking forward to hearing suggestions > > > > -- > > Toli Kuznets > > http://www.marketcetera.com: Open-Source Trading Platform > > download.run.trade. > > > > -------------------------------------------------------------- > > ----------- > > Take Surveys. Earn Cash. Influence the Future of IT Join > > SourceForge.net's Techsay panel and you'll get the chance to > > share your opinions on IT & business topics through brief > > surveys -- and earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge > &CID=DEVDEV > > _______________________________________________ > > Quickfixj-users mailing list > > Qui...@li... > > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > -- Toli Kuznets http://www.marketcetera.com: Open-Source Trading Platform download.run.trade. |
|
From: Alex M. <ale...@eu...> - 2006-09-26 14:28:12
|
Hi Steve, Thanks for the info. I am being passed a properties object by the framework I am developing to, however, I can access the settings file directly if necessary. Alex -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Steve Bate Sent: 26 September 2006 08:04 To: qui...@li... Subject: Re: [Quickfixj-users] Settings QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ Eurobase International Limited and its subsidiaries (Eurobase) are = unable to exercise control over the content of information in E-Mails. = Any views and opinions expressed may be personal to the sender and are = not necessarily those of Eurobase. Eurobase will not enter into any = contractual obligations in respect of any part of its business in any = E-mail.=20 Privileged / confidential information may be contained in this message = and /or any attachments. This E-mail is intended for the use of the = addressee(s) only and may contain confidential information. If you are = not the / an intended recipient, you are hereby notified that any use or = dissemination of this communication is strictly prohibited. If you = receive this transmission in error, please notify us immediately, and = then delete this E-mail.=20 Neither the sender nor Eurobase accepts any liability whatsoever for any = defects of any kind either in or arising from this E-mail transmission. = E-Mail transmission cannot be guaranteed to be secure or error-free, as = messages can be intercepted, lost, corrupted, destroyed, contain = viruses, or arrive late or incomplete. Eurobase does not accept any = responsibility for viruses and it is your responsibility to scan any = attachments. Registered Address: Essex House, 2 County Place, Chelmsford, Essex CM2 = 0RE, United Kingdom |
|
From: Steve B. <st...@te...> - 2006-09-26 07:04:09
|
Hi Alex,
The session settings format looks similar to a property file format but it
is different. Why are you
using properties to initialize the settings data? There's probably another
way to do it depending on
what you need to do.
Steve
_____
From: qui...@li...
[mailto:qui...@li...] On Behalf Of Alex
McGlashan
Sent: Monday, September 25, 2006 11:08 AM
To: qui...@li...
Subject: [Quickfixj-users] Settings
I have a problem reading the QFJ Settings file when it is passed to me as a
java.util.Properties object. I am using code like:
OutputStream out = new ByteArrayOutputStream();
getProperties().store(out, null);
InputStream inputStream = new
ByteArrayInputStream(((ByteArrayOutputStream) out).toByteArray());
SessionSettings settings = new SessionSettings(inputStream);
The load() method in SessionSettings requires that the tokens are read in a
particular order i.e. section headings followed by the settings for that
section. Unfortunately the order of the entries in the original file is not
maintained in the OutputStream above. Does anyone know a way round this or
should I not be accessing the settings file via a Properties object at all?
Thanks,
Alex
Eurobase International Limited and its subsidiaries (Eurobase) are unable to
exercise control over the content of information in E-Mails. Any views and
opinions expressed may be personal to the sender and are not necessarily
those of Eurobase. Eurobase will not enter into any contractual obligations
in respect of any part of its business in any E-mail.
Privileged / confidential information may be contained in this message and
/or any attachments. This E-mail is intended for the use of the addressee(s)
only and may contain confidential information. If you are not the / an
intended recipient, you are hereby notified that any use or dissemination of
this communication is strictly prohibited. If you receive this transmission
in error, please notify us immediately, and then delete this E-mail.
Neither the sender nor Eurobase accepts any liability whatsoever for any
defects of any kind either in or arising from this E-mail transmission.
E-Mail transmission cannot be guaranteed to be secure or error-free, as
messages can be intercepted, lost, corrupted, destroyed, contain viruses, or
arrive late or incomplete. Eurobase does not accept any responsibility for
viruses and it is your responsibility to scan any attachments.
Registered Address: Essex House, 2 County Place, Chelmsford, Essex CM2 0RE,
United Kingdom
|
|
From: Alex M. <ale...@eu...> - 2006-09-25 09:09:45
|
I have a problem reading the QFJ Settings file when it is passed to me
as a java.util.Properties object. I am using code like:
=20
OutputStream out =3D new ByteArrayOutputStream();
getProperties().store(out, null);
InputStream inputStream =3D new
ByteArrayInputStream(((ByteArrayOutputStream) out).toByteArray());
SessionSettings settings =3D new SessionSettings(inputStream);
=20
The load() method in SessionSettings requires that the tokens are read
in a particular order i.e. section headings followed by the settings for
that section. Unfortunately the order of the entries in the original
file is not maintained in the OutputStream above. Does anyone know a
way round this or should I not be accessing the settings file via a
Properties object at all?
=20
Thanks,
=20
Alex
Eurobase International Limited and its subsidiaries (Eurobase) are =
unable to exercise control over the content of information in E-Mails. =
Any views and opinions expressed may be personal to the sender and are =
not necessarily those of Eurobase. Eurobase will not enter into any =
contractual obligations in respect of any part of its business in any =
E-mail.=20
Privileged / confidential information may be contained in this message =
and /or any attachments. This E-mail is intended for the use of the =
addressee(s) only and may contain confidential information. If you are =
not the / an intended recipient, you are hereby notified that any use or =
dissemination of this communication is strictly prohibited. If you =
receive this transmission in error, please notify us immediately, and =
then delete this E-mail.=20
Neither the sender nor Eurobase accepts any liability whatsoever for any =
defects of any kind either in or arising from this E-mail transmission. =
E-Mail transmission cannot be guaranteed to be secure or error-free, as =
messages can be intercepted, lost, corrupted, destroyed, contain =
viruses, or arrive late or incomplete. Eurobase does not accept any =
responsibility for viruses and it is your responsibility to scan any =
attachments.
Registered Address: Essex House, 2 County Place, Chelmsford, Essex CM2 =
0RE, United Kingdom
|
|
From: Steve B. <st...@te...> - 2006-09-24 19:33:21
|
Hi Toli, I'm open to adding more configuration to the JdbcLogFactory. If you'd like prototype the changes, that would be great. If you had some related unit tests that would be even better. ;-) In the longer term, I'd like to have a general FIX message to relational table mapping capability so that, for example, NewOrderSingle could be mapped to an application-specific database structure with columns for whichever fields are important to that specific application. The database logger would be implemented as a special case usage of this mapping framework. I'll be on the road on Monday, so I'll watch for other comments when I return on Tuesday. Steve > -----Original Message----- > From: qui...@li... > [mailto:qui...@li...] On > Behalf Of Toli Kuznets > Sent: Saturday, September 23, 2006 2:49 AM > To: qui...@li... > Subject: [Quickfixj-users] RFE: Making LogFactories more confgurable > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ Hey everyone, > > We are thinking of using the JdbcLogFactory to save some of > the FIX messages to the database. > (side question: anybody ever tested throughput/efficiency of > that logger?) > > However, compared to the ScreenLogFactory, the Jdbc and Mysql > loggers are very bare-bones and not configurable. for > example, the target table names where the messages are placed > are hard-coded (see the rfe at > http://www.quickfixj.org/jira/browse/QFJ-75 > > Does anybody have any thoughts on improving the other loggers? > Currently, there are 4 vars for configuring ScreenLogFactory > that turn on/off some printing. > We'd like to have similar ones for the JDBC logger as well - > which would mean 4 more similar variables. > > I'd be happy to prototype the new changes, and submit a patch > for review. Any thoughts/considerations before i do that? > > In production, we'll most likely use a CompositeLogFactory, > which will output to the screen and/or DB depending on which > configs are specified. However, we may want to have different > output going to each, hence the need for parallel config parameters. > > looking forward to hearing suggestions > > -- > Toli Kuznets > http://www.marketcetera.com: Open-Source Trading Platform > download.run.trade. > > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT Join > SourceForge.net's Techsay panel and you'll get the chance to > share your opinions on IT & business topics through brief > surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge &CID=DEVDEV > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > |
|
From: Brad H. <Bra...@gb...> - 2006-09-23 09:26:25
|
> I wouldn't mind if manual intervention was required - how about a way
of
> telling the engine (without a logout) that a particular message number
> is never going to come? For example, would a method on session to
bump
> the expected sequence number up and forget about past resend requests
> sent work?=20
Ignoring possible synchronisation and error handling issues, this seems
to do the trick:
public void skipIncomingMessage() throws Exception {
state.incrNextTargetMsgSeqNum();
nextQueued();
}
|
|
From: Toli K. <to...@ma...> - 2006-09-23 00:49:24
|
Hey everyone, We are thinking of using the JdbcLogFactory to save some of the FIX messages to the database. (side question: anybody ever tested throughput/efficiency of that logger?) However, compared to the ScreenLogFactory, the Jdbc and Mysql loggers are very bare-bones and not configurable. for example, the target table names where the messages are placed are hard-coded (see the rfe at http://www.quickfixj.org/jira/browse/QFJ-75 Does anybody have any thoughts on improving the other loggers? Currently, there are 4 vars for configuring ScreenLogFactory that turn on/off some printing. We'd like to have similar ones for the JDBC logger as well - which would mean 4 more similar variables. I'd be happy to prototype the new changes, and submit a patch for review. Any thoughts/considerations before i do that? In production, we'll most likely use a CompositeLogFactory, which will output to the screen and/or DB depending on which configs are specified. However, we may want to have different output going to each, hence the need for parallel config parameters. looking forward to hearing suggestions -- Toli Kuznets http://www.marketcetera.com: Open-Source Trading Platform download.run.trade. |
|
From: Brad H. <Bra...@gb...> - 2006-09-22 22:25:10
|
Hi Steve, I think quickfix avoided an infinite resend loop nicely and adhered to the spec, but from a practical point of view the connection was unusable. I'd like to be able to recover gracefully from application errors involving checksum calculation (potentially other garbled message conditions?). I'm not concerned if the message causing the problem can't be processed, but I still want to receive subsequent messages coming in on the connection. I wouldn't mind if manual intervention was required - how about a way of telling the engine (without a logout) that a particular message number is never going to come? For example, would a method on session to bump the expected sequence number up and forget about past resend requests sent work? Thanks for your help. Regards, Brad. -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Steve Bate Sent: Friday, 22 September 2006 7:23 PM To: qui...@li... Subject: Re: [Quickfixj-users] Handling of checksum errors QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ Hi Brad, According to the FIX 4.4 spec... "Note: The receiving application should disregard any message=20 that is garbled, cannot be parsed or fails a data integrity check.=20 Processing of the next valid FIX message will cause detection of a=20 sequence gap and a Resend Request will be generated. Logic should be=20 included in the FIX engine to recognize the possible infinite resend=20 loop, which may be encountered in this situation." =20 This paragraph seems to be assuming a /network error/ that would cause garbled messages rather than an application error. If it were the network, you'd expect that the resent message might be correct. This isn't necessarily true for an application error. Your specific problem seems to be caused partially by the QFJ checksum calculation. There are several little issues here, most of which are related to Java's lack of unsigned types and the fact that QF JNI uses Strings to represent raw message data (rather than a byte array or a ByteBuffer). The use of Strings means that the data is stored as a Unicode character array rather than as a byte array and this can cause problems in the cases. On the other hand, it's a potential benefit for the Chinese users. :-) My challenge has been how to support the String-based messages while maintaining the best possible performance. Java Strings and performance are almost an oxymoron, especially for networking protocols. I'm going to do some more investigation, but assuming your=20 counterparty is calculating the checksum correctly for the garbled=20 data, I'd prefer to improve the checksum calculation in QFJ. I'm open to other suggestions, but I'd prefer to not support configurable disabling of message integrity checks. Steve > -----Original Message----- > From: qui...@li...=20 > [mailto:qui...@li...] On=20 > Behalf Of Brad Harvey > Sent: Friday, September 22, 2006 2:36 AM > To: qui...@li... > Subject: Re: [Quickfixj-users] Handling of checksum errors >=20 > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ Hi Toli, >=20 > Thanks. We do know the cause of the checksum errors - some=20 > extra data was being added into a string field (from an=20 > uninitialised buffer apparently so the characters could be=20 > anything). The two engines aren't calculating the checksum=20 > the same way for these non printable characters, but I=20 > haven't looked into exactly what they were or what the=20 > correct checksum should have been yet. I'm leaving further=20 > investigation of this for later - at the moment I just want=20 > to make sure a checksum error doesn't stop all subsequent=20 > incoming messages from being processed. >=20 > Cheers, > Brad. =20 >=20 > -----Original Message----- > From: qui...@li... > [mailto:qui...@li...] On=20 > Behalf Of Toli Kuznets > Sent: Friday, 22 September 2006 10:09 AM > To: qui...@li... > Subject: Re: [Quickfixj-users] Handling of checksum errors >=20 > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ Brad, >=20 > Not sure if this helps - but i came across checksum problems=20 > when my exchange simulator (modified exchange code) was=20 > inserting fields unknown to quickfixj when these vars were set: > DataDictionary=3DFIX42.xml > UseDataDictionary=3DY >=20 > Are you sure you are not inserting "unknown" fields? >=20 > hope this helps. If i remember the exact sequence of what=20 > caused checksum failures for me i'll post that >=20 > On 9/21/06, Brad Harvey <Bra...@gb...> wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > QuickFIX/J Support: http://www.quickfixj.org/support/ Hi All, > > > > I recently encountered a problem where the checksum validation of a=20 > > particular incoming message always failed. This has the side effect > of > > stopping fromApp being called for any future message because the > engine > > waits forever for the message to be resent. > > > > Ignoring the problem of why the checksum is failing for the moment > (non > > printable/possibly embedded null characters in a string field - > possibly > > the subject of a future mail), what would be a better way to handle=20 > > this? > > > > As a short term workaround I may disable checksum=20 > validation - we're=20 > > connecting to counterparty over a LAN and the risk of=20 > checksum being=20 > > incorrect on a message is higher than the risk of the message being=20 > > received incorrectly. > > > > Longer term I was thinking of doing something to make the=20 > engine go to=20 > > the next target sequence number if there are 2 checksums=20 > failures for=20 > > the same MsgSeqNum. > > > > Following is a log from Banzai showing the problem. It was=20 > connecting=20 > > to Executor which I modified to always make the checksum of=20 > execution=20 > > reports for security "CHK" incorrect. This test was done with > quickfixj > > trunk but problem was initially noticed with 1.0.2. > > > > Any suggestions are appreciated. > > Thanks, > > Brad. > > > > The test was: > > * submitted two orders that received execution reports ok. > > * submitted order for CHK. > > * executor mangled checksum on execution report for CHK, banzai > detected > > checksum failure (fromApp not called) > > * submit another order > > * banzai detects out of sequence message, sends resend request > > * executor resent execution report with managed checksum again. > > * banzai detects checksum failure > > * For any further incoming messages, banzai detects=20 > sequence too high=20 > > and does nothing because of pending resend request. > > > > <20060921-12:25:25, FIX.4.2:BANZAI->EXEC, outgoing> > > > = (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D2=0149=3DBANZAI=0152=3D20060921-12= :25:25.937=01 > 56=3DEXEC=0111 > > > = =3D1158841525860=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DABC= =0159=3D0=0160=3D200609 > 21-12:25:2 > > 5=0110=3D250=01) > > <20060921-12:25:26, FIX.4.2:BANZAI->EXEC, incoming> > > > = (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D2=0149=3DEXEC=0152=3D20060921-12:2= 5:26.062=0156 > =3DBANZAI=016=3D > > > = 10=0111=3D1158841525860=0114=3D5=0117=3D1=0120=3D0=0131=3D10=0132=3D5=013= 7=3D1=0138=3D5=0139=3D2=015 > 4=3D1=0155=3DABC > > =01150=3D2=01151=3D0=0110=3D057=01) > > <20060921-12:25:46, FIX.4.2:BANZAI->EXEC, outgoing> > > > = (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D3=0149=3DBANZAI=0152=3D20060921-12= :25:46.546=01 > 56=3DEXEC=0111 > > > = =3D1158841546548=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DCBA= =0159=3D0=0160=3D200609 > 21-12:25:4 > > 6=0110=3D003=01) > > <20060921-12:25:46, FIX.4.2:BANZAI->EXEC, incoming> > > > = (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D3=0149=3DEXEC=0152=3D20060921-12:2= 5:46.546=0156 > =3DBANZAI=016=3D > > > = 10=0111=3D1158841546548=0114=3D5=0117=3D2=0120=3D0=0131=3D10=0132=3D5=013= 7=3D2=0138=3D5=0139=3D2=015 > 4=3D1=0155=3DCBA > > =01150=3D2=01151=3D0=0110=3D075=01) > > <20060921-12:25:56, FIX.4.2:BANZAI->EXEC, outgoing> > > > = (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D4=0149=3DBANZAI=0152=3D20060921-12= :25:56.312=01 > 56=3DEXEC=0111 > > > = =3D1158841556315=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DCHK= =0159=3D0=0160=3D200609 > 21-12:25:5 > > 6=0110=3D006=01) > > <20060921-12:25:56, FIX.4.2:BANZAI->EXEC, incoming> > > > = (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D4=0149=3DEXEC=0152=3D20060921-12:2= 5:56.312=0156 > =3DBANZAI=016=3D > > > = 10=0111=3D1158841556315=0114=3D5=0117=3D3=0120=3D0=0131=3D10=0132=3D5=013= 7=3D3=0138=3D5=0139=3D2=015 > 4=3D1=0155=3DCHK > > =01150=3D2=01151=3D0=0110=3D179=01) > > 21/09/2006 22:25:56 quickfix.mina.AbstractIoHandler messageReceived > > SEVERE: Invalid message: Expected CheckSum=3D79, Received=20 > CheckSum=3D179=20 > > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, outgoing> > > > = (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D5=0149=3DBANZAI=0152=3D20060921-12= :26:26.468=01 > 56=3DEXEC=0111 > > > = =3D1158841586472=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DAAA= =0159=3D0=0160=3D200609 > 21-12:26:2 > > 6=0110=3D003=01) > > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, incoming> > > > = (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D5=0149=3DEXEC=0152=3D20060921-12:2= 6:26.468=0156 > =3DBANZAI=016=3D > > > = 10=0111=3D1158841586472=0114=3D5=0117=3D4=0120=3D0=0131=3D10=0132=3D5=013= 7=3D4=0138=3D5=0139=3D2=015 > 4=3D1=0155=3DAAA > > =01150=3D2=01151=3D0=0110=3D080=01) > > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum=20 > too high,=20 > > expecting 4 but received 5) <20060921-12:26:26,=20 > FIX.4.2:BANZAI->EXEC,=20 > > outgoing> > > > = (8=3DFIX.4.2=019=3D62=0135=3D2=0134=3D6=0149=3DBANZAI=0152=3D20060921-12:= 26:26.468=015 > 6=3DEXEC=017=3D4 > > =0116=3D0=0110=3D058=01) > > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, event> (Sent ResendRequest > > FROM: 4 TO: 0) > > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, incoming> > > > = (8=3DFIX.4.2=019=3D167=0135=3D8=0134=3D4=0143=3DY=0149=3DEXEC=0152=3D2006= 0921-12:26:26.4 > 84=0156=3DBANZ > > > = AI=01122=3D20060921-12:25:56=016=3D10=0111=3D1158841556315=0114=3D5=0117=3D= 3=0120=3D0=01 > 31=3D10=0132=3D5 > > = =0137=3D3=0138=3D5=0139=3D2=0154=3D1=0155=3DCHK=01150=3D2=01151=3D0=0110=3D= 255=01) > > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, incoming> > > > = (8=3DFIX.4.2=019=3D167=0135=3D8=0134=3D5=0143=3DY=0149=3DEXEC=0152=3D2006= 0921-12:26:26.5 > 00=0156=3DBANZ > > > = AI=01122=3D20060921-12:26:26=016=3D10=0111=3D1158841586472=0114=3D5=0117=3D= 4=0120=3D0=01 > 31=3D10=0132=3D5 > > = =0137=3D4=0138=3D5=0139=3D2=0154=3D1=0155=3DAAA=01150=3D2=01151=3D0=0110=3D= 133=01) > > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum=20 > too high,=20 > > expecting 4 but received 5) <20060921-12:26:26,=20 > FIX.4.2:BANZAI->EXEC,=20 > > event> (Already sent ResendRequest FROM: 4 TO: 4. Not sending=20 > > another.) > > 21/09/2006 22:26:26 quickfix.mina.AbstractIoHandler messageReceived > > SEVERE: Invalid message: Expected CheckSum=3D155, Received=20 > CheckSum=3D255=20 > > <20060921-12:26:34, FIX.4.2:BANZAI->EXEC, outgoing> > > > = (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D7=0149=3DBANZAI=0152=3D20060921-12= :26:34.421=01 > 56=3DEXEC=0111 > > > = =3D1158841594426=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DBBB= =0159=3D0=0160=3D200609 > 21-12:26:3 > > 4=0110=3D249=01) > > <20060921-12:26:34, FIX.4.2:BANZAI->EXEC, incoming> > > > = (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D6=0149=3DEXEC=0152=3D20060921-12:2= 6:34.437=0156 > =3DBANZAI=016=3D > > > = 10=0111=3D1158841594426=0114=3D5=0117=3D5=0120=3D0=0131=3D10=0132=3D5=013= 7=3D5=0138=3D5=0139=3D2=015 > 4=3D1=0155=3DBBB > > =01150=3D2=01151=3D0=0110=3D079=01) > > <20060921-12:26:34, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum=20 > too high,=20 > > expecting 4 but received 6) <20060921-12:26:34,=20 > FIX.4.2:BANZAI->EXEC,=20 > > event> (Already sent ResendRequest FROM: 4 TO: 4. Not sending=20 > > another.) <20060921-12:26:43, FIX.4.2:BANZAI->EXEC, outgoing> > > > = (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D8=0149=3DBANZAI=0152=3D20060921-12= :26:43.609=01 > 56=3DEXEC=0111 > > > = =3D1158841603615=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DCCC= =0159=3D0=0160=3D200609 > 21-12:26:4 > > 3=0110=3D252=01) > > <20060921-12:26:43, FIX.4.2:BANZAI->EXEC, incoming> > > > = (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D7=0149=3DEXEC=0152=3D20060921-12:2= 6:43.625=0156 > =3DBANZAI=016=3D > > > = 10=0111=3D1158841603615=0114=3D5=0117=3D6=0120=3D0=0131=3D10=0132=3D5=013= 7=3D6=0138=3D5=0139=3D2=015 > 4=3D1=0155=3DCCC > > =01150=3D2=01151=3D0=0110=3D075=01) > > <20060921-12:26:43, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum=20 > too high,=20 > > expecting 4 but received 7) <20060921-12:26:43,=20 > FIX.4.2:BANZAI->EXEC,=20 > > event> (Already sent ResendRequest FROM: 4 TO: 4. Not sending=20 > > another.) <20060921-12:26:54, FIX.4.2:BANZAI->EXEC, outgoing> > > > = (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D9=0149=3DBANZAI=0152=3D20060921-12= :26:54.390=01 > 56=3DEXEC=0111 > > > = =3D1158841614397=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DDDD= =0159=3D0=0160=3D200609 > 21-12:26:5 > > 4=0110=3D010=01) > > <20060921-12:26:54, FIX.4.2:BANZAI->EXEC, incoming> > > > = (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D8=0149=3DEXEC=0152=3D20060921-12:2= 6:54.406=0156 > =3DBANZAI=016=3D > > > = 10=0111=3D1158841614397=0114=3D5=0117=3D7=0120=3D0=0131=3D10=0132=3D5=013= 7=3D7=0138=3D5=0139=3D2=015 > 4=3D1=0155=3DDDD > > =01150=3D2=01151=3D0=0110=3D089=01) > > <20060921-12:26:54, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum=20 > too high,=20 > > expecting 4 but received 8) <20060921-12:26:54,=20 > FIX.4.2:BANZAI->EXEC,=20 > > event> (Already sent ResendRequest FROM: 4 TO: 4. Not sending=20 > > another.) > > > > > > > > > -------------------------------------------------------------- > ---------- > - > > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > > SourceForge.net's Techsay panel and you'll get the chance to > share your > > opinions on IT & business topics through brief surveys -- and earn > cash > > > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > &CID=3DDEVDE > V > > _______________________________________________ > > Quickfixj-users mailing list > > Qui...@li... > > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > > >=20 >=20 > -- > Toli Kuznets > http://www.marketcetera.com: Open-Source Trading Platform=20 > download.run.trade. >=20 > -------------------------------------------------------------- > ---------- > - > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys -- and earn cash=20 > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > &CID=3DDEVDE > V > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys -- and earn cash=20 > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > &CID=3DDEVDEV > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users >=20 ------------------------------------------------------------------------ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDE V _______________________________________________ Quickfixj-users mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
|
From: Brad H. <Bra...@gb...> - 2006-09-22 11:52:16
|
Hi Steve,
I was thinking something similar - perhaps a charset should be used for
encoding and decoding?
// completely untested, of course :)
private int checkSum(String s) {
int offset =3D s.lastIndexOf("\00110=3D");
int sum =3D 0; =20
Charset ascii =3D Charset.forName("ASCII");
ByteBuffer byteBuffer =3D ascii.encode(s.substring(0, offset));
while (byteBuffer.hasRemaining()) {
sum +=3D getUnsignedByte(byteBuffer.get());=20
}
return (sum + 1) % 256;
}
private static final int maxUnsignedByte =3D 0xFF;
/**
* @param byteValue
* a signed byte
* @return the unsigned representation of the byte value
*/
public static short getUnsignedByte(byte byteValue) {
return (short) (byteValue & maxUnsignedByte);
}
And presumably use decode when reading (probably the more important
bit?). =20
Yes, for the Banzai example I just changed the checksum field - I did
not attempt to emulate the cause of the checksum failures. Some might
argue about the "simply" part though - I used the filter below on the
executor to change it after the executor sent it out.
Regards,
Brad.
package quickfix.examples.filter;
import org.apache.mina.common.IoFilterAdapter;
import org.apache.mina.common.IoSession;
import quickfix.Message;
import quickfix.field.MsgType;
import quickfix.field.Symbol;
public class ChecksumFailureFilter extends IoFilterAdapter {
private String symbolToFail =3D "CHK";
public void filterWrite(NextFilter nextFilter, IoSession session,
WriteRequest writeRequest) throws Exception {
Object object =3D writeRequest.getMessage();
if (object instanceof String) {
String message =3D (String)object;
Message qfMessage =3D new Message();
qfMessage.fromString(message, null, false);
String messageType =3D
qfMessage.getHeader().getString(MsgType.FIELD);
if ("8".equals(messageType)) {
if
(symbolToFail.equalsIgnoreCase(qfMessage.getString(Symbol.FIELD))) {
String checksum =3D "\00110=3D";
int offset =3D message.lastIndexOf(checksum);
String newMessage =3D message.substring(0, offset) +
checksum + "1" + message.substring(offset + checksum.length() + 1);
if (newMessage.equals(message)) {
newMessage =3D message.substring(0, offset) +
checksum + "2" + message.substring(offset + checksum.length() + 1);
}
writeRequest =3D new WriteRequest(newMessage,
writeRequest.getFuture());
}
}
}
nextFilter.filterWrite(session, writeRequest);
}
public String getSymbolToFail() {
return symbolToFail;
}
public void setSymbolToFail(String symbolToFail) {
this.symbolToFail =3D symbolToFail;
}
=20
=20
}
-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Steve Bate
Sent: Friday, 22 September 2006 7:46 PM
To: qui...@li...
Subject: Re: [Quickfixj-users] Handling of checksum errors
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/
> Ignoring the problem of why the checksum is failing for the=20
> moment (non printable/possibly embedded null characters in a=20
> string field - possibly the subject of a future mail), what=20
> would be a better way to handle this? =20
Hi Brad,
I don't think the checksum calculation would have a problem=20
with null characters. I'm still investigating whether nonprintable
characters might be interpreted as Unicode and cause problems
with the checksum calculation.
In your Banzai example, you simply placed the wrong checksum
in the message, right?
Steve
------------------------------------------------------------------------
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDE
V
_______________________________________________
Quickfixj-users mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
|
|
From: Steve B. <st...@te...> - 2006-09-22 09:44:10
|
> Ignoring the problem of why the checksum is failing for the > moment (non printable/possibly embedded null characters in a > string field - possibly the subject of a future mail), what > would be a better way to handle this? Hi Brad, I don't think the checksum calculation would have a problem with null characters. I'm still investigating whether nonprintable characters might be interpreted as Unicode and cause problems with the checksum calculation. In your Banzai example, you simply placed the wrong checksum in the message, right? Steve |
|
From: Steve B. <st...@te...> - 2006-09-22 09:21:14
|
Hi Brad, According to the FIX 4.4 spec... "Note: The receiving application should disregard any message=20 that is garbled, cannot be parsed or fails a data integrity check.=20 Processing of the next valid FIX message will cause detection of a=20 sequence gap and a Resend Request will be generated. Logic should be=20 included in the FIX engine to recognize the possible infinite resend=20 loop, which may be encountered in this situation." =20 This paragraph seems to be assuming a /network error/ that would cause garbled messages rather than an application error. If it were the network, you'd expect that the resent message might be correct. This isn't necessarily true for an application error. Your specific problem seems to be caused partially by the QFJ checksum calculation. There are several little issues here, most of which are related to Java's lack of unsigned types and the fact that QF JNI uses Strings to represent raw message data (rather than a byte array or a ByteBuffer). The use of Strings means that the data is stored as a Unicode character array rather than as a byte array and this can cause problems in the cases. On the other hand, it's a potential benefit for the Chinese users. :-) My challenge has been how to support the String-based messages while maintaining the best possible performance. Java Strings and performance are almost an oxymoron, especially for networking protocols. I'm going to do some more investigation, but assuming your=20 counterparty is calculating the checksum correctly for the garbled=20 data, I'd prefer to improve the checksum calculation in QFJ. I'm open to other suggestions, but I'd prefer to not support configurable disabling of message integrity checks. Steve > -----Original Message----- > From: qui...@li...=20 > [mailto:qui...@li...] On=20 > Behalf Of Brad Harvey > Sent: Friday, September 22, 2006 2:36 AM > To: qui...@li... > Subject: Re: [Quickfixj-users] Handling of checksum errors >=20 > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ Hi Toli, >=20 > Thanks. We do know the cause of the checksum errors - some=20 > extra data was being added into a string field (from an=20 > uninitialised buffer apparently so the characters could be=20 > anything). The two engines aren't calculating the checksum=20 > the same way for these non printable characters, but I=20 > haven't looked into exactly what they were or what the=20 > correct checksum should have been yet. I'm leaving further=20 > investigation of this for later - at the moment I just want=20 > to make sure a checksum error doesn't stop all subsequent=20 > incoming messages from being processed. >=20 > Cheers, > Brad. =20 >=20 > -----Original Message----- > From: qui...@li... > [mailto:qui...@li...] On=20 > Behalf Of Toli Kuznets > Sent: Friday, 22 September 2006 10:09 AM > To: qui...@li... > Subject: Re: [Quickfixj-users] Handling of checksum errors >=20 > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ Brad, >=20 > Not sure if this helps - but i came across checksum problems=20 > when my exchange simulator (modified exchange code) was=20 > inserting fields unknown to quickfixj when these vars were set: > DataDictionary=3DFIX42.xml > UseDataDictionary=3DY >=20 > Are you sure you are not inserting "unknown" fields? >=20 > hope this helps. If i remember the exact sequence of what=20 > caused checksum failures for me i'll post that >=20 > On 9/21/06, Brad Harvey <Bra...@gb...> wrote: > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > QuickFIX/J Support: http://www.quickfixj.org/support/ Hi All, > > > > I recently encountered a problem where the checksum validation of a=20 > > particular incoming message always failed. This has the side effect > of > > stopping fromApp being called for any future message because the > engine > > waits forever for the message to be resent. > > > > Ignoring the problem of why the checksum is failing for the moment > (non > > printable/possibly embedded null characters in a string field - > possibly > > the subject of a future mail), what would be a better way to handle=20 > > this? > > > > As a short term workaround I may disable checksum=20 > validation - we're=20 > > connecting to counterparty over a LAN and the risk of=20 > checksum being=20 > > incorrect on a message is higher than the risk of the message being=20 > > received incorrectly. > > > > Longer term I was thinking of doing something to make the=20 > engine go to=20 > > the next target sequence number if there are 2 checksums=20 > failures for=20 > > the same MsgSeqNum. > > > > Following is a log from Banzai showing the problem. It was=20 > connecting=20 > > to Executor which I modified to always make the checksum of=20 > execution=20 > > reports for security "CHK" incorrect. This test was done with > quickfixj > > trunk but problem was initially noticed with 1.0.2. > > > > Any suggestions are appreciated. > > Thanks, > > Brad. > > > > The test was: > > * submitted two orders that received execution reports ok. > > * submitted order for CHK. > > * executor mangled checksum on execution report for CHK, banzai > detected > > checksum failure (fromApp not called) > > * submit another order > > * banzai detects out of sequence message, sends resend request > > * executor resent execution report with managed checksum again. > > * banzai detects checksum failure > > * For any further incoming messages, banzai detects=20 > sequence too high=20 > > and does nothing because of pending resend request. > > > > <20060921-12:25:25, FIX.4.2:BANZAI->EXEC, outgoing> > > > = (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D2=0149=3DBANZAI=0152=3D20060921-12= :25:25.937=01 > 56=3DEXEC=0111 > > > = =3D1158841525860=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DABC= =0159=3D0=0160=3D200609 > 21-12:25:2 > > 5=0110=3D250=01) > > <20060921-12:25:26, FIX.4.2:BANZAI->EXEC, incoming> > > > = (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D2=0149=3DEXEC=0152=3D20060921-12:2= 5:26.062=0156 > =3DBANZAI=016=3D > > > = 10=0111=3D1158841525860=0114=3D5=0117=3D1=0120=3D0=0131=3D10=0132=3D5=013= 7=3D1=0138=3D5=0139=3D2=015 > 4=3D1=0155=3DABC > > =01150=3D2=01151=3D0=0110=3D057=01) > > <20060921-12:25:46, FIX.4.2:BANZAI->EXEC, outgoing> > > > = (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D3=0149=3DBANZAI=0152=3D20060921-12= :25:46.546=01 > 56=3DEXEC=0111 > > > = =3D1158841546548=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DCBA= =0159=3D0=0160=3D200609 > 21-12:25:4 > > 6=0110=3D003=01) > > <20060921-12:25:46, FIX.4.2:BANZAI->EXEC, incoming> > > > = (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D3=0149=3DEXEC=0152=3D20060921-12:2= 5:46.546=0156 > =3DBANZAI=016=3D > > > = 10=0111=3D1158841546548=0114=3D5=0117=3D2=0120=3D0=0131=3D10=0132=3D5=013= 7=3D2=0138=3D5=0139=3D2=015 > 4=3D1=0155=3DCBA > > =01150=3D2=01151=3D0=0110=3D075=01) > > <20060921-12:25:56, FIX.4.2:BANZAI->EXEC, outgoing> > > > = (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D4=0149=3DBANZAI=0152=3D20060921-12= :25:56.312=01 > 56=3DEXEC=0111 > > > = =3D1158841556315=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DCHK= =0159=3D0=0160=3D200609 > 21-12:25:5 > > 6=0110=3D006=01) > > <20060921-12:25:56, FIX.4.2:BANZAI->EXEC, incoming> > > > = (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D4=0149=3DEXEC=0152=3D20060921-12:2= 5:56.312=0156 > =3DBANZAI=016=3D > > > = 10=0111=3D1158841556315=0114=3D5=0117=3D3=0120=3D0=0131=3D10=0132=3D5=013= 7=3D3=0138=3D5=0139=3D2=015 > 4=3D1=0155=3DCHK > > =01150=3D2=01151=3D0=0110=3D179=01) > > 21/09/2006 22:25:56 quickfix.mina.AbstractIoHandler messageReceived > > SEVERE: Invalid message: Expected CheckSum=3D79, Received=20 > CheckSum=3D179=20 > > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, outgoing> > > > = (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D5=0149=3DBANZAI=0152=3D20060921-12= :26:26.468=01 > 56=3DEXEC=0111 > > > = =3D1158841586472=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DAAA= =0159=3D0=0160=3D200609 > 21-12:26:2 > > 6=0110=3D003=01) > > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, incoming> > > > = (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D5=0149=3DEXEC=0152=3D20060921-12:2= 6:26.468=0156 > =3DBANZAI=016=3D > > > = 10=0111=3D1158841586472=0114=3D5=0117=3D4=0120=3D0=0131=3D10=0132=3D5=013= 7=3D4=0138=3D5=0139=3D2=015 > 4=3D1=0155=3DAAA > > =01150=3D2=01151=3D0=0110=3D080=01) > > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum=20 > too high,=20 > > expecting 4 but received 5) <20060921-12:26:26,=20 > FIX.4.2:BANZAI->EXEC,=20 > > outgoing> > > > = (8=3DFIX.4.2=019=3D62=0135=3D2=0134=3D6=0149=3DBANZAI=0152=3D20060921-12:= 26:26.468=015 > 6=3DEXEC=017=3D4 > > =0116=3D0=0110=3D058=01) > > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, event> (Sent ResendRequest > > FROM: 4 TO: 0) > > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, incoming> > > > = (8=3DFIX.4.2=019=3D167=0135=3D8=0134=3D4=0143=3DY=0149=3DEXEC=0152=3D2006= 0921-12:26:26.4 > 84=0156=3DBANZ > > > = AI=01122=3D20060921-12:25:56=016=3D10=0111=3D1158841556315=0114=3D5=0117=3D= 3=0120=3D0=01 > 31=3D10=0132=3D5 > > = =0137=3D3=0138=3D5=0139=3D2=0154=3D1=0155=3DCHK=01150=3D2=01151=3D0=0110=3D= 255=01) > > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, incoming> > > > = (8=3DFIX.4.2=019=3D167=0135=3D8=0134=3D5=0143=3DY=0149=3DEXEC=0152=3D2006= 0921-12:26:26.5 > 00=0156=3DBANZ > > > = AI=01122=3D20060921-12:26:26=016=3D10=0111=3D1158841586472=0114=3D5=0117=3D= 4=0120=3D0=01 > 31=3D10=0132=3D5 > > = =0137=3D4=0138=3D5=0139=3D2=0154=3D1=0155=3DAAA=01150=3D2=01151=3D0=0110=3D= 133=01) > > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum=20 > too high,=20 > > expecting 4 but received 5) <20060921-12:26:26,=20 > FIX.4.2:BANZAI->EXEC,=20 > > event> (Already sent ResendRequest FROM: 4 TO: 4. Not sending=20 > > another.) > > 21/09/2006 22:26:26 quickfix.mina.AbstractIoHandler messageReceived > > SEVERE: Invalid message: Expected CheckSum=3D155, Received=20 > CheckSum=3D255=20 > > <20060921-12:26:34, FIX.4.2:BANZAI->EXEC, outgoing> > > > = (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D7=0149=3DBANZAI=0152=3D20060921-12= :26:34.421=01 > 56=3DEXEC=0111 > > > = =3D1158841594426=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DBBB= =0159=3D0=0160=3D200609 > 21-12:26:3 > > 4=0110=3D249=01) > > <20060921-12:26:34, FIX.4.2:BANZAI->EXEC, incoming> > > > = (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D6=0149=3DEXEC=0152=3D20060921-12:2= 6:34.437=0156 > =3DBANZAI=016=3D > > > = 10=0111=3D1158841594426=0114=3D5=0117=3D5=0120=3D0=0131=3D10=0132=3D5=013= 7=3D5=0138=3D5=0139=3D2=015 > 4=3D1=0155=3DBBB > > =01150=3D2=01151=3D0=0110=3D079=01) > > <20060921-12:26:34, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum=20 > too high,=20 > > expecting 4 but received 6) <20060921-12:26:34,=20 > FIX.4.2:BANZAI->EXEC,=20 > > event> (Already sent ResendRequest FROM: 4 TO: 4. Not sending=20 > > another.) <20060921-12:26:43, FIX.4.2:BANZAI->EXEC, outgoing> > > > = (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D8=0149=3DBANZAI=0152=3D20060921-12= :26:43.609=01 > 56=3DEXEC=0111 > > > = =3D1158841603615=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DCCC= =0159=3D0=0160=3D200609 > 21-12:26:4 > > 3=0110=3D252=01) > > <20060921-12:26:43, FIX.4.2:BANZAI->EXEC, incoming> > > > = (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D7=0149=3DEXEC=0152=3D20060921-12:2= 6:43.625=0156 > =3DBANZAI=016=3D > > > = 10=0111=3D1158841603615=0114=3D5=0117=3D6=0120=3D0=0131=3D10=0132=3D5=013= 7=3D6=0138=3D5=0139=3D2=015 > 4=3D1=0155=3DCCC > > =01150=3D2=01151=3D0=0110=3D075=01) > > <20060921-12:26:43, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum=20 > too high,=20 > > expecting 4 but received 7) <20060921-12:26:43,=20 > FIX.4.2:BANZAI->EXEC,=20 > > event> (Already sent ResendRequest FROM: 4 TO: 4. Not sending=20 > > another.) <20060921-12:26:54, FIX.4.2:BANZAI->EXEC, outgoing> > > > = (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D9=0149=3DBANZAI=0152=3D20060921-12= :26:54.390=01 > 56=3DEXEC=0111 > > > = =3D1158841614397=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DDDD= =0159=3D0=0160=3D200609 > 21-12:26:5 > > 4=0110=3D010=01) > > <20060921-12:26:54, FIX.4.2:BANZAI->EXEC, incoming> > > > = (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D8=0149=3DEXEC=0152=3D20060921-12:2= 6:54.406=0156 > =3DBANZAI=016=3D > > > = 10=0111=3D1158841614397=0114=3D5=0117=3D7=0120=3D0=0131=3D10=0132=3D5=013= 7=3D7=0138=3D5=0139=3D2=015 > 4=3D1=0155=3DDDD > > =01150=3D2=01151=3D0=0110=3D089=01) > > <20060921-12:26:54, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum=20 > too high,=20 > > expecting 4 but received 8) <20060921-12:26:54,=20 > FIX.4.2:BANZAI->EXEC,=20 > > event> (Already sent ResendRequest FROM: 4 TO: 4. Not sending=20 > > another.) > > > > > > > > > -------------------------------------------------------------- > ---------- > - > > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > > SourceForge.net's Techsay panel and you'll get the chance to > share your > > opinions on IT & business topics through brief surveys -- and earn > cash > > > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > &CID=3DDEVDE > V > > _______________________________________________ > > Quickfixj-users mailing list > > Qui...@li... > > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > > >=20 >=20 > -- > Toli Kuznets > http://www.marketcetera.com: Open-Source Trading Platform=20 > download.run.trade. >=20 > -------------------------------------------------------------- > ---------- > - > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys -- and earn cash=20 > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > &CID=3DDEVDE > V > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys -- and earn cash=20 > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > &CID=3DDEVDEV > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users >=20 |
|
From: Brad H. <Bra...@gb...> - 2006-09-22 00:36:26
|
Hi Toli, Thanks. We do know the cause of the checksum errors - some extra data was being added into a string field (from an uninitialised buffer apparently so the characters could be anything). The two engines aren't calculating the checksum the same way for these non printable characters, but I haven't looked into exactly what they were or what the correct checksum should have been yet. I'm leaving further investigation of this for later - at the moment I just want to make sure a checksum error doesn't stop all subsequent incoming messages from being processed. Cheers, Brad. =20 -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Toli Kuznets Sent: Friday, 22 September 2006 10:09 AM To: qui...@li... Subject: Re: [Quickfixj-users] Handling of checksum errors QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ Brad, Not sure if this helps - but i came across checksum problems when my exchange simulator (modified exchange code) was inserting fields unknown to quickfixj when these vars were set: DataDictionary=3DFIX42.xml UseDataDictionary=3DY Are you sure you are not inserting "unknown" fields? hope this helps. If i remember the exact sequence of what caused checksum failures for me i'll post that On 9/21/06, Brad Harvey <Bra...@gb...> wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > Hi All, > > I recently encountered a problem where the checksum validation of a > particular incoming message always failed. This has the side effect of > stopping fromApp being called for any future message because the engine > waits forever for the message to be resent. > > Ignoring the problem of why the checksum is failing for the moment (non > printable/possibly embedded null characters in a string field - possibly > the subject of a future mail), what would be a better way to handle > this? > > As a short term workaround I may disable checksum validation - we're > connecting to counterparty over a LAN and the risk of checksum being > incorrect on a message is higher than the risk of the message being > received incorrectly. > > Longer term I was thinking of doing something to make the engine go to > the next target sequence number if there are 2 checksums failures for > the same MsgSeqNum. > > Following is a log from Banzai showing the problem. It was connecting > to Executor which I modified to always make the checksum of execution > reports for security "CHK" incorrect. This test was done with quickfixj > trunk but problem was initially noticed with 1.0.2. > > Any suggestions are appreciated. > Thanks, > Brad. > > The test was: > * submitted two orders that received execution reports ok. > * submitted order for CHK. > * executor mangled checksum on execution report for CHK, banzai detected > checksum failure (fromApp not called) > * submit another order > * banzai detects out of sequence message, sends resend request > * executor resent execution report with managed checksum again. > * banzai detects checksum failure > * For any further incoming messages, banzai detects sequence too high > and does nothing because of pending resend request. > > <20060921-12:25:25, FIX.4.2:BANZAI->EXEC, outgoing> > (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D2=0149=3DBANZAI=0152=3D20060921-12= :25:25.937=0156=3DEXEC=0111 > =3D1158841525860=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DABC= =0159=3D0=0160=3D20060921-12:25:2 > 5=0110=3D250=01) > <20060921-12:25:26, FIX.4.2:BANZAI->EXEC, incoming> > (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D2=0149=3DEXEC=0152=3D20060921-12:2= 5:26.062=0156=3DBANZAI=016=3D > 10=0111=3D1158841525860=0114=3D5=0117=3D1=0120=3D0=0131=3D10=0132=3D5=013= 7=3D1=0138=3D5=0139=3D2=0154=3D1=0155=3DABC > =01150=3D2=01151=3D0=0110=3D057=01) > <20060921-12:25:46, FIX.4.2:BANZAI->EXEC, outgoing> > (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D3=0149=3DBANZAI=0152=3D20060921-12= :25:46.546=0156=3DEXEC=0111 > =3D1158841546548=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DCBA= =0159=3D0=0160=3D20060921-12:25:4 > 6=0110=3D003=01) > <20060921-12:25:46, FIX.4.2:BANZAI->EXEC, incoming> > (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D3=0149=3DEXEC=0152=3D20060921-12:2= 5:46.546=0156=3DBANZAI=016=3D > 10=0111=3D1158841546548=0114=3D5=0117=3D2=0120=3D0=0131=3D10=0132=3D5=013= 7=3D2=0138=3D5=0139=3D2=0154=3D1=0155=3DCBA > =01150=3D2=01151=3D0=0110=3D075=01) > <20060921-12:25:56, FIX.4.2:BANZAI->EXEC, outgoing> > (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D4=0149=3DBANZAI=0152=3D20060921-12= :25:56.312=0156=3DEXEC=0111 > =3D1158841556315=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DCHK= =0159=3D0=0160=3D20060921-12:25:5 > 6=0110=3D006=01) > <20060921-12:25:56, FIX.4.2:BANZAI->EXEC, incoming> > (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D4=0149=3DEXEC=0152=3D20060921-12:2= 5:56.312=0156=3DBANZAI=016=3D > 10=0111=3D1158841556315=0114=3D5=0117=3D3=0120=3D0=0131=3D10=0132=3D5=013= 7=3D3=0138=3D5=0139=3D2=0154=3D1=0155=3DCHK > =01150=3D2=01151=3D0=0110=3D179=01) > 21/09/2006 22:25:56 quickfix.mina.AbstractIoHandler messageReceived > SEVERE: Invalid message: Expected CheckSum=3D79, Received = CheckSum=3D179 > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, outgoing> > (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D5=0149=3DBANZAI=0152=3D20060921-12= :26:26.468=0156=3DEXEC=0111 > =3D1158841586472=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DAAA= =0159=3D0=0160=3D20060921-12:26:2 > 6=0110=3D003=01) > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, incoming> > (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D5=0149=3DEXEC=0152=3D20060921-12:2= 6:26.468=0156=3DBANZAI=016=3D > 10=0111=3D1158841586472=0114=3D5=0117=3D4=0120=3D0=0131=3D10=0132=3D5=013= 7=3D4=0138=3D5=0139=3D2=0154=3D1=0155=3DAAA > =01150=3D2=01151=3D0=0110=3D080=01) > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum too high, > expecting 4 but received 5) > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, outgoing> > (8=3DFIX.4.2=019=3D62=0135=3D2=0134=3D6=0149=3DBANZAI=0152=3D20060921-12:= 26:26.468=0156=3DEXEC=017=3D4 > =0116=3D0=0110=3D058=01) > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, event> (Sent ResendRequest > FROM: 4 TO: 0) > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, incoming> > (8=3DFIX.4.2=019=3D167=0135=3D8=0134=3D4=0143=3DY=0149=3DEXEC=0152=3D2006= 0921-12:26:26.484=0156=3DBANZ > AI=01122=3D20060921-12:25:56=016=3D10=0111=3D1158841556315=0114=3D5=0117=3D= 3=0120=3D0=0131=3D10=0132=3D5 > = =0137=3D3=0138=3D5=0139=3D2=0154=3D1=0155=3DCHK=01150=3D2=01151=3D0=0110=3D= 255=01) > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, incoming> > (8=3DFIX.4.2=019=3D167=0135=3D8=0134=3D5=0143=3DY=0149=3DEXEC=0152=3D2006= 0921-12:26:26.500=0156=3DBANZ > AI=01122=3D20060921-12:26:26=016=3D10=0111=3D1158841586472=0114=3D5=0117=3D= 4=0120=3D0=0131=3D10=0132=3D5 > = =0137=3D4=0138=3D5=0139=3D2=0154=3D1=0155=3DAAA=01150=3D2=01151=3D0=0110=3D= 133=01) > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum too high, > expecting 4 but received 5) > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, event> (Already sent > ResendRequest FROM: 4 TO: 4. Not sending another.) > 21/09/2006 22:26:26 quickfix.mina.AbstractIoHandler messageReceived > SEVERE: Invalid message: Expected CheckSum=3D155, Received = CheckSum=3D255 > <20060921-12:26:34, FIX.4.2:BANZAI->EXEC, outgoing> > (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D7=0149=3DBANZAI=0152=3D20060921-12= :26:34.421=0156=3DEXEC=0111 > =3D1158841594426=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DBBB= =0159=3D0=0160=3D20060921-12:26:3 > 4=0110=3D249=01) > <20060921-12:26:34, FIX.4.2:BANZAI->EXEC, incoming> > (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D6=0149=3DEXEC=0152=3D20060921-12:2= 6:34.437=0156=3DBANZAI=016=3D > 10=0111=3D1158841594426=0114=3D5=0117=3D5=0120=3D0=0131=3D10=0132=3D5=013= 7=3D5=0138=3D5=0139=3D2=0154=3D1=0155=3DBBB > =01150=3D2=01151=3D0=0110=3D079=01) > <20060921-12:26:34, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum too high, > expecting 4 but received 6) > <20060921-12:26:34, FIX.4.2:BANZAI->EXEC, event> (Already sent > ResendRequest FROM: 4 TO: 4. Not sending another.) > <20060921-12:26:43, FIX.4.2:BANZAI->EXEC, outgoing> > (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D8=0149=3DBANZAI=0152=3D20060921-12= :26:43.609=0156=3DEXEC=0111 > =3D1158841603615=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DCCC= =0159=3D0=0160=3D20060921-12:26:4 > 3=0110=3D252=01) > <20060921-12:26:43, FIX.4.2:BANZAI->EXEC, incoming> > (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D7=0149=3DEXEC=0152=3D20060921-12:2= 6:43.625=0156=3DBANZAI=016=3D > 10=0111=3D1158841603615=0114=3D5=0117=3D6=0120=3D0=0131=3D10=0132=3D5=013= 7=3D6=0138=3D5=0139=3D2=0154=3D1=0155=3DCCC > =01150=3D2=01151=3D0=0110=3D075=01) > <20060921-12:26:43, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum too high, > expecting 4 but received 7) > <20060921-12:26:43, FIX.4.2:BANZAI->EXEC, event> (Already sent > ResendRequest FROM: 4 TO: 4. Not sending another.) > <20060921-12:26:54, FIX.4.2:BANZAI->EXEC, outgoing> > (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D9=0149=3DBANZAI=0152=3D20060921-12= :26:54.390=0156=3DEXEC=0111 > =3D1158841614397=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DDDD= =0159=3D0=0160=3D20060921-12:26:5 > 4=0110=3D010=01) > <20060921-12:26:54, FIX.4.2:BANZAI->EXEC, incoming> > (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D8=0149=3DEXEC=0152=3D20060921-12:2= 6:54.406=0156=3DBANZAI=016=3D > 10=0111=3D1158841614397=0114=3D5=0117=3D7=0120=3D0=0131=3D10=0132=3D5=013= 7=3D7=0138=3D5=0139=3D2=0154=3D1=0155=3DDDD > =01150=3D2=01151=3D0=0110=3D089=01) > <20060921-12:26:54, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum too high, > expecting 4 but received 8) > <20060921-12:26:54, FIX.4.2:BANZAI->EXEC, event> (Already sent > ResendRequest FROM: 4 TO: 4. Not sending another.) > > > > ------------------------------------------------------------------------ - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDE V > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > --=20 Toli Kuznets http://www.marketcetera.com: Open-Source Trading Platform download.run.trade. ------------------------------------------------------------------------ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDE V _______________________________________________ Quickfixj-users mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
|
From: Toli K. <to...@ma...> - 2006-09-22 00:09:03
|
Brad, Not sure if this helps - but i came across checksum problems when my exchange simulator (modified exchange code) was inserting fields unknown to quickfixj when these vars were set: DataDictionary=3DFIX42.xml UseDataDictionary=3DY Are you sure you are not inserting "unknown" fields? hope this helps. If i remember the exact sequence of what caused checksum failures for me i'll post that On 9/21/06, Brad Harvey <Bra...@gb...> wrote: > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ > Hi All, > > I recently encountered a problem where the checksum validation of a > particular incoming message always failed. This has the side effect of > stopping fromApp being called for any future message because the engine > waits forever for the message to be resent. > > Ignoring the problem of why the checksum is failing for the moment (non > printable/possibly embedded null characters in a string field - possibly > the subject of a future mail), what would be a better way to handle > this? > > As a short term workaround I may disable checksum validation - we're > connecting to counterparty over a LAN and the risk of checksum being > incorrect on a message is higher than the risk of the message being > received incorrectly. > > Longer term I was thinking of doing something to make the engine go to > the next target sequence number if there are 2 checksums failures for > the same MsgSeqNum. > > Following is a log from Banzai showing the problem. It was connecting > to Executor which I modified to always make the checksum of execution > reports for security "CHK" incorrect. This test was done with quickfixj > trunk but problem was initially noticed with 1.0.2. > > Any suggestions are appreciated. > Thanks, > Brad. > > The test was: > * submitted two orders that received execution reports ok. > * submitted order for CHK. > * executor mangled checksum on execution report for CHK, banzai detected > checksum failure (fromApp not called) > * submit another order > * banzai detects out of sequence message, sends resend request > * executor resent execution report with managed checksum again. > * banzai detects checksum failure > * For any further incoming messages, banzai detects sequence too high > and does nothing because of pending resend request. > > <20060921-12:25:25, FIX.4.2:BANZAI->EXEC, outgoing> > (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D2=0149=3DBANZAI=0152=3D20060921-12= :25:25.937=0156=3DEXEC=0111 > =3D1158841525860=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DABC= =0159=3D0=0160=3D20060921-12:25:2 > 5=0110=3D250=01) > <20060921-12:25:26, FIX.4.2:BANZAI->EXEC, incoming> > (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D2=0149=3DEXEC=0152=3D20060921-12:2= 5:26.062=0156=3DBANZAI=016=3D > 10=0111=3D1158841525860=0114=3D5=0117=3D1=0120=3D0=0131=3D10=0132=3D5=013= 7=3D1=0138=3D5=0139=3D2=0154=3D1=0155=3DABC > =01150=3D2=01151=3D0=0110=3D057=01) > <20060921-12:25:46, FIX.4.2:BANZAI->EXEC, outgoing> > (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D3=0149=3DBANZAI=0152=3D20060921-12= :25:46.546=0156=3DEXEC=0111 > =3D1158841546548=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DCBA= =0159=3D0=0160=3D20060921-12:25:4 > 6=0110=3D003=01) > <20060921-12:25:46, FIX.4.2:BANZAI->EXEC, incoming> > (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D3=0149=3DEXEC=0152=3D20060921-12:2= 5:46.546=0156=3DBANZAI=016=3D > 10=0111=3D1158841546548=0114=3D5=0117=3D2=0120=3D0=0131=3D10=0132=3D5=013= 7=3D2=0138=3D5=0139=3D2=0154=3D1=0155=3DCBA > =01150=3D2=01151=3D0=0110=3D075=01) > <20060921-12:25:56, FIX.4.2:BANZAI->EXEC, outgoing> > (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D4=0149=3DBANZAI=0152=3D20060921-12= :25:56.312=0156=3DEXEC=0111 > =3D1158841556315=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DCHK= =0159=3D0=0160=3D20060921-12:25:5 > 6=0110=3D006=01) > <20060921-12:25:56, FIX.4.2:BANZAI->EXEC, incoming> > (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D4=0149=3DEXEC=0152=3D20060921-12:2= 5:56.312=0156=3DBANZAI=016=3D > 10=0111=3D1158841556315=0114=3D5=0117=3D3=0120=3D0=0131=3D10=0132=3D5=013= 7=3D3=0138=3D5=0139=3D2=0154=3D1=0155=3DCHK > =01150=3D2=01151=3D0=0110=3D179=01) > 21/09/2006 22:25:56 quickfix.mina.AbstractIoHandler messageReceived > SEVERE: Invalid message: Expected CheckSum=3D79, Received CheckSum=3D179 > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, outgoing> > (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D5=0149=3DBANZAI=0152=3D20060921-12= :26:26.468=0156=3DEXEC=0111 > =3D1158841586472=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DAAA= =0159=3D0=0160=3D20060921-12:26:2 > 6=0110=3D003=01) > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, incoming> > (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D5=0149=3DEXEC=0152=3D20060921-12:2= 6:26.468=0156=3DBANZAI=016=3D > 10=0111=3D1158841586472=0114=3D5=0117=3D4=0120=3D0=0131=3D10=0132=3D5=013= 7=3D4=0138=3D5=0139=3D2=0154=3D1=0155=3DAAA > =01150=3D2=01151=3D0=0110=3D080=01) > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum too high, > expecting 4 but received 5) > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, outgoing> > (8=3DFIX.4.2=019=3D62=0135=3D2=0134=3D6=0149=3DBANZAI=0152=3D20060921-12:= 26:26.468=0156=3DEXEC=017=3D4 > =0116=3D0=0110=3D058=01) > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, event> (Sent ResendRequest > FROM: 4 TO: 0) > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, incoming> > (8=3DFIX.4.2=019=3D167=0135=3D8=0134=3D4=0143=3DY=0149=3DEXEC=0152=3D2006= 0921-12:26:26.484=0156=3DBANZ > AI=01122=3D20060921-12:25:56=016=3D10=0111=3D1158841556315=0114=3D5=0117= =3D3=0120=3D0=0131=3D10=0132=3D5 > =0137=3D3=0138=3D5=0139=3D2=0154=3D1=0155=3DCHK=01150=3D2=01151=3D0=0110= =3D255=01) > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, incoming> > (8=3DFIX.4.2=019=3D167=0135=3D8=0134=3D5=0143=3DY=0149=3DEXEC=0152=3D2006= 0921-12:26:26.500=0156=3DBANZ > AI=01122=3D20060921-12:26:26=016=3D10=0111=3D1158841586472=0114=3D5=0117= =3D4=0120=3D0=0131=3D10=0132=3D5 > =0137=3D4=0138=3D5=0139=3D2=0154=3D1=0155=3DAAA=01150=3D2=01151=3D0=0110= =3D133=01) > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum too high, > expecting 4 but received 5) > <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, event> (Already sent > ResendRequest FROM: 4 TO: 4. Not sending another.) > 21/09/2006 22:26:26 quickfix.mina.AbstractIoHandler messageReceived > SEVERE: Invalid message: Expected CheckSum=3D155, Received CheckSum=3D255 > <20060921-12:26:34, FIX.4.2:BANZAI->EXEC, outgoing> > (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D7=0149=3DBANZAI=0152=3D20060921-12= :26:34.421=0156=3DEXEC=0111 > =3D1158841594426=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DBBB= =0159=3D0=0160=3D20060921-12:26:3 > 4=0110=3D249=01) > <20060921-12:26:34, FIX.4.2:BANZAI->EXEC, incoming> > (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D6=0149=3DEXEC=0152=3D20060921-12:2= 6:34.437=0156=3DBANZAI=016=3D > 10=0111=3D1158841594426=0114=3D5=0117=3D5=0120=3D0=0131=3D10=0132=3D5=013= 7=3D5=0138=3D5=0139=3D2=0154=3D1=0155=3DBBB > =01150=3D2=01151=3D0=0110=3D079=01) > <20060921-12:26:34, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum too high, > expecting 4 but received 6) > <20060921-12:26:34, FIX.4.2:BANZAI->EXEC, event> (Already sent > ResendRequest FROM: 4 TO: 4. Not sending another.) > <20060921-12:26:43, FIX.4.2:BANZAI->EXEC, outgoing> > (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D8=0149=3DBANZAI=0152=3D20060921-12= :26:43.609=0156=3DEXEC=0111 > =3D1158841603615=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DCCC= =0159=3D0=0160=3D20060921-12:26:4 > 3=0110=3D252=01) > <20060921-12:26:43, FIX.4.2:BANZAI->EXEC, incoming> > (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D7=0149=3DEXEC=0152=3D20060921-12:2= 6:43.625=0156=3DBANZAI=016=3D > 10=0111=3D1158841603615=0114=3D5=0117=3D6=0120=3D0=0131=3D10=0132=3D5=013= 7=3D6=0138=3D5=0139=3D2=0154=3D1=0155=3DCCC > =01150=3D2=01151=3D0=0110=3D075=01) > <20060921-12:26:43, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum too high, > expecting 4 but received 7) > <20060921-12:26:43, FIX.4.2:BANZAI->EXEC, event> (Already sent > ResendRequest FROM: 4 TO: 4. Not sending another.) > <20060921-12:26:54, FIX.4.2:BANZAI->EXEC, outgoing> > (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D9=0149=3DBANZAI=0152=3D20060921-12= :26:54.390=0156=3DEXEC=0111 > =3D1158841614397=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DDDD= =0159=3D0=0160=3D20060921-12:26:5 > 4=0110=3D010=01) > <20060921-12:26:54, FIX.4.2:BANZAI->EXEC, incoming> > (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D8=0149=3DEXEC=0152=3D20060921-12:2= 6:54.406=0156=3DBANZAI=016=3D > 10=0111=3D1158841614397=0114=3D5=0117=3D7=0120=3D0=0131=3D10=0132=3D5=013= 7=3D7=0138=3D5=0139=3D2=0154=3D1=0155=3DDDD > =01150=3D2=01151=3D0=0110=3D089=01) > <20060921-12:26:54, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum too high, > expecting 4 but received 8) > <20060921-12:26:54, FIX.4.2:BANZAI->EXEC, event> (Already sent > ResendRequest FROM: 4 TO: 4. Not sending another.) > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share y= our > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > --=20 Toli Kuznets http://www.marketcetera.com: Open-Source Trading Platform download.run.trade. |
|
From: Brad H. <Bra...@gb...> - 2006-09-21 22:31:12
|
Hi All, I recently encountered a problem where the checksum validation of a particular incoming message always failed. This has the side effect of stopping fromApp being called for any future message because the engine waits forever for the message to be resent. =20 Ignoring the problem of why the checksum is failing for the moment (non printable/possibly embedded null characters in a string field - possibly the subject of a future mail), what would be a better way to handle this? =20 As a short term workaround I may disable checksum validation - we're connecting to counterparty over a LAN and the risk of checksum being incorrect on a message is higher than the risk of the message being received incorrectly. Longer term I was thinking of doing something to make the engine go to the next target sequence number if there are 2 checksums failures for the same MsgSeqNum. Following is a log from Banzai showing the problem. It was connecting to Executor which I modified to always make the checksum of execution reports for security "CHK" incorrect. This test was done with quickfixj trunk but problem was initially noticed with 1.0.2. Any suggestions are appreciated. Thanks, Brad. The test was: * submitted two orders that received execution reports ok. * submitted order for CHK. * executor mangled checksum on execution report for CHK, banzai detected checksum failure (fromApp not called) * submit another order * banzai detects out of sequence message, sends resend request * executor resent execution report with managed checksum again. * banzai detects checksum failure * For any further incoming messages, banzai detects sequence too high and does nothing because of pending resend request. <20060921-12:25:25, FIX.4.2:BANZAI->EXEC, outgoing> (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D2=0149=3DBANZAI=0152=3D20060921-12= :25:25.937=0156=3DEXEC=0111 =3D1158841525860=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DABC= =0159=3D0=0160=3D20060921-12:25:2 5=0110=3D250=01) <20060921-12:25:26, FIX.4.2:BANZAI->EXEC, incoming> (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D2=0149=3DEXEC=0152=3D20060921-12:2= 5:26.062=0156=3DBANZAI=016=3D 10=0111=3D1158841525860=0114=3D5=0117=3D1=0120=3D0=0131=3D10=0132=3D5=013= 7=3D1=0138=3D5=0139=3D2=0154=3D1=0155=3DABC =01150=3D2=01151=3D0=0110=3D057=01) <20060921-12:25:46, FIX.4.2:BANZAI->EXEC, outgoing> (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D3=0149=3DBANZAI=0152=3D20060921-12= :25:46.546=0156=3DEXEC=0111 =3D1158841546548=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DCBA= =0159=3D0=0160=3D20060921-12:25:4 6=0110=3D003=01) <20060921-12:25:46, FIX.4.2:BANZAI->EXEC, incoming> (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D3=0149=3DEXEC=0152=3D20060921-12:2= 5:46.546=0156=3DBANZAI=016=3D 10=0111=3D1158841546548=0114=3D5=0117=3D2=0120=3D0=0131=3D10=0132=3D5=013= 7=3D2=0138=3D5=0139=3D2=0154=3D1=0155=3DCBA =01150=3D2=01151=3D0=0110=3D075=01) <20060921-12:25:56, FIX.4.2:BANZAI->EXEC, outgoing> (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D4=0149=3DBANZAI=0152=3D20060921-12= :25:56.312=0156=3DEXEC=0111 =3D1158841556315=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DCHK= =0159=3D0=0160=3D20060921-12:25:5 6=0110=3D006=01) <20060921-12:25:56, FIX.4.2:BANZAI->EXEC, incoming> (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D4=0149=3DEXEC=0152=3D20060921-12:2= 5:56.312=0156=3DBANZAI=016=3D 10=0111=3D1158841556315=0114=3D5=0117=3D3=0120=3D0=0131=3D10=0132=3D5=013= 7=3D3=0138=3D5=0139=3D2=0154=3D1=0155=3DCHK =01150=3D2=01151=3D0=0110=3D179=01) 21/09/2006 22:25:56 quickfix.mina.AbstractIoHandler messageReceived SEVERE: Invalid message: Expected CheckSum=3D79, Received CheckSum=3D179 <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, outgoing> (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D5=0149=3DBANZAI=0152=3D20060921-12= :26:26.468=0156=3DEXEC=0111 =3D1158841586472=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DAAA= =0159=3D0=0160=3D20060921-12:26:2 6=0110=3D003=01) <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, incoming> (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D5=0149=3DEXEC=0152=3D20060921-12:2= 6:26.468=0156=3DBANZAI=016=3D 10=0111=3D1158841586472=0114=3D5=0117=3D4=0120=3D0=0131=3D10=0132=3D5=013= 7=3D4=0138=3D5=0139=3D2=0154=3D1=0155=3DAAA =01150=3D2=01151=3D0=0110=3D080=01) <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum too high, expecting 4 but received 5) <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, outgoing> (8=3DFIX.4.2=019=3D62=0135=3D2=0134=3D6=0149=3DBANZAI=0152=3D20060921-12:= 26:26.468=0156=3DEXEC=017=3D4 =0116=3D0=0110=3D058=01) <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, event> (Sent ResendRequest FROM: 4 TO: 0) <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, incoming> (8=3DFIX.4.2=019=3D167=0135=3D8=0134=3D4=0143=3DY=0149=3DEXEC=0152=3D2006= 0921-12:26:26.484=0156=3DBANZ AI=01122=3D20060921-12:25:56=016=3D10=0111=3D1158841556315=0114=3D5=0117=3D= 3=0120=3D0=0131=3D10=0132=3D5 =0137=3D3=0138=3D5=0139=3D2=0154=3D1=0155=3DCHK=01150=3D2=01151=3D0=0110=3D= 255=01) <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, incoming> (8=3DFIX.4.2=019=3D167=0135=3D8=0134=3D5=0143=3DY=0149=3DEXEC=0152=3D2006= 0921-12:26:26.500=0156=3DBANZ AI=01122=3D20060921-12:26:26=016=3D10=0111=3D1158841586472=0114=3D5=0117=3D= 4=0120=3D0=0131=3D10=0132=3D5 =0137=3D4=0138=3D5=0139=3D2=0154=3D1=0155=3DAAA=01150=3D2=01151=3D0=0110=3D= 133=01) <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum too high, expecting 4 but received 5) <20060921-12:26:26, FIX.4.2:BANZAI->EXEC, event> (Already sent ResendRequest FROM: 4 TO: 4. Not sending another.) 21/09/2006 22:26:26 quickfix.mina.AbstractIoHandler messageReceived SEVERE: Invalid message: Expected CheckSum=3D155, Received = CheckSum=3D255 <20060921-12:26:34, FIX.4.2:BANZAI->EXEC, outgoing> (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D7=0149=3DBANZAI=0152=3D20060921-12= :26:34.421=0156=3DEXEC=0111 =3D1158841594426=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DBBB= =0159=3D0=0160=3D20060921-12:26:3 4=0110=3D249=01) <20060921-12:26:34, FIX.4.2:BANZAI->EXEC, incoming> (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D6=0149=3DEXEC=0152=3D20060921-12:2= 6:34.437=0156=3DBANZAI=016=3D 10=0111=3D1158841594426=0114=3D5=0117=3D5=0120=3D0=0131=3D10=0132=3D5=013= 7=3D5=0138=3D5=0139=3D2=0154=3D1=0155=3DBBB =01150=3D2=01151=3D0=0110=3D079=01) <20060921-12:26:34, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum too high, expecting 4 but received 6) <20060921-12:26:34, FIX.4.2:BANZAI->EXEC, event> (Already sent ResendRequest FROM: 4 TO: 4. Not sending another.) <20060921-12:26:43, FIX.4.2:BANZAI->EXEC, outgoing> (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D8=0149=3DBANZAI=0152=3D20060921-12= :26:43.609=0156=3DEXEC=0111 =3D1158841603615=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DCCC= =0159=3D0=0160=3D20060921-12:26:4 3=0110=3D252=01) <20060921-12:26:43, FIX.4.2:BANZAI->EXEC, incoming> (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D7=0149=3DEXEC=0152=3D20060921-12:2= 6:43.625=0156=3DBANZAI=016=3D 10=0111=3D1158841603615=0114=3D5=0117=3D6=0120=3D0=0131=3D10=0132=3D5=013= 7=3D6=0138=3D5=0139=3D2=0154=3D1=0155=3DCCC =01150=3D2=01151=3D0=0110=3D075=01) <20060921-12:26:43, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum too high, expecting 4 but received 7) <20060921-12:26:43, FIX.4.2:BANZAI->EXEC, event> (Already sent ResendRequest FROM: 4 TO: 4. Not sending another.) <20060921-12:26:54, FIX.4.2:BANZAI->EXEC, outgoing> (8=3DFIX.4.2=019=3D129=0135=3DD=0134=3D9=0149=3DBANZAI=0152=3D20060921-12= :26:54.390=0156=3DEXEC=0111 =3D1158841614397=0121=3D1=0138=3D5=0140=3D2=0144=3D10=0154=3D1=0155=3DDDD= =0159=3D0=0160=3D20060921-12:26:5 4=0110=3D010=01) <20060921-12:26:54, FIX.4.2:BANZAI->EXEC, incoming> (8=3DFIX.4.2=019=3D140=0135=3D8=0134=3D8=0149=3DEXEC=0152=3D20060921-12:2= 6:54.406=0156=3DBANZAI=016=3D 10=0111=3D1158841614397=0114=3D5=0117=3D7=0120=3D0=0131=3D10=0132=3D5=013= 7=3D7=0138=3D5=0139=3D2=0154=3D1=0155=3DDDD =01150=3D2=01151=3D0=0110=3D089=01) <20060921-12:26:54, FIX.4.2:BANZAI->EXEC, event> (MsgSeqNum too high, expecting 4 but received 8) <20060921-12:26:54, FIX.4.2:BANZAI->EXEC, event> (Already sent ResendRequest FROM: 4 TO: 4. Not sending another.) =20 |
|
From: Alex M. <ale...@eu...> - 2006-09-20 14:39:26
|
Hi Steve, Here's the appropriate extract from the event.log: 20060920-12:56:02: Session FIX.4.2:scbbanku2fixmaker->CNX schedule is daily, 00:00:00 UTC - 00:00:00 UTC 20060920-12:56:02: Created session: FIX.4.2:scbbanku2fixmaker->CNX 20060920-12:56:03: Initiated logon request 20060920-12:56:03: Received logon response 20060920-12:56:03: Received ResendRequest FROM: 259 TO: 259 20060920-12:56:03: Sent SequenceReset TO: 260 20060920-12:57:18: Disconnecting Alex -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Steve Bate Sent: 20 September 2006 15:29 To: qui...@li... Subject: Re: [Quickfixj-users] Resend Request message QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ It depends on the LogFactory you are using. If you are using the FileLogFactory, there should be a file ending with "event.log" in the location specified by your configuration. Steve=20 > -----Original Message----- > From: qui...@li...=20 > [mailto:qui...@li...] On=20 > Behalf Of Alex McGlashan > Sent: Wednesday, September 20, 2006 4:18 PM > To: qui...@li... > Subject: Re: [Quickfixj-users] Resend Request message >=20 > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ Hi Steve, >=20 > Possibly not - how should I do that? >=20 > Alex >=20 > -----Original Message----- > From: qui...@li... > [mailto:qui...@li...] On=20 > Behalf Of Steve Bate > Sent: 20 September 2006 15:13 > To: qui...@li... > Subject: Re: [Quickfixj-users] Resend Request message >=20 > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ Hi Alex, >=20 > Are you logging QFJ events in addition to messages? The log=20 > you provided appears to include your application log=20 > messages and the QFJ FIX messages but I don't see any QFJ events. >=20 > Steve >=20 > > -----Original Message----- > > From: qui...@li... > > [mailto:qui...@li...] On Behalf Of=20 > > Alex McGlashan > > Sent: Wednesday, September 20, 2006 3:48 PM > > To: qui...@li... > > Subject: Re: [Quickfixj-users] Resend Request message > >=20 > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > QuickFIX/J Support: http://www.quickfixj.org/support/ Hi Steve, > >=20 > > There are no exceptions in the system out - here is the output from=20 > > another shutdown: > >=20 > > [20/09/06 13:57:18 BST] Service stopping > > [20/09/06 13:57:18 BST] : ESPMessageManager: entering close > > [20/09/06 13:57:18 BST] Alex: : ESPConnector: entering disconnect > > [20/09/06 13:57:18 BST] Alex: : ESPConnector: entering sendLogout > > [20/09/06 13:57:18 BST] TwistManager: timeout closedown now running > > [20/09/06 13:57:18 BST] Alex: : ESPConnector: entering send > > - message =3D 8=3DFIX.4.2=019=3D5=0135=3D5=0110=3D166=01 > > [20/09/06 13:57:18 BST] Alex: : ESPConnector: FIXHandler toAdmin -=20 > > message type =3D 5 message =3D > > = 8=3DFIX.4.2=019=3D65=0135=3D5=0134=3D299=0149=3Dscbbanku2fixmaker=0152=3D= 20060920-12 > > :57:18.266 > > =0156=3DCNX=0110=3D017=01 > > [20/09/06 13:57:18 BST] Alex: : ESPConnector: waiting for=20 > connection=20 > > status > > [20/09/06 13:57:18 BST] Alex: : ESPConnector: FIXHandler onLogout > > [20/09/06 13:57:18 BST] Alex: : ESPCOnnector: notifying=20 > > connectionWaiter listeners > > [20/09/06 13:57:18 BST] Alex debug: entering setConnected > > [20/09/06 13:57:18 BST] Alex debug: setConnected - got lock > > [20/09/06 13:57:18 BST] Alex debug: setConnected - set=20 > connected to=20 > > false > > [20/09/06 13:57:18 BST] Alex debug: exiting setConnected > > [20/09/06 13:57:18 BST] Alex: : ESPConnector: exiting disconnect > > [20/09/06 13:57:18 BST] Service stopped > >=20 > > And the message log for the same time (the server is 1 hour behind): > >=20 > > = 8=3DFIX.4.2=019=3D65=0135=3D5=0134=3D299=0149=3Dscbbanku2fixmaker=0152=3D= 20060920-12 > > :57:18.266 > > =0156=3DCNX=0110=3D017=01 > > = 8=3DFIX.4.2=019=3D62=0135=3D5=0149=3DCNX=0156=3Dscbbanku2fixmaker=0134=3D= 1739=0152=3D200 > > 60920-12:5 > > 8:31=0110=3D110=01 > >=20 > > And the seqnums file after shutdown: > >=20 > > 300:1739 > >=20 > > Are there any other diagnostics that could shed more light on this? > >=20 > > Thanks, > >=20 > > Alex > >=20 > >=20 > >=20 > >=20 > > -----Original Message----- > > From: qui...@li... > > [mailto:qui...@li...] On Behalf Of=20 > > Steve Bate > > Sent: 20 September 2006 14:30 > > To: qui...@li... > > Subject: Re: [Quickfixj-users] Resend Request message > >=20 > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > QuickFIX/J Support: http://www.quickfixj.org/support/ Hi Alex, > >=20 > > Does the log indicate any validation errors or exceptions when=20 > > processing the logout acknowledgement? For example, if there is an=20 > > exception while verifying the logout ack, the fromAdmin=20 > callback will=20 > > not be called although the onLogout callback will be called=20 > during the=20 > > subsequent disconnect. > >=20 > > Steve > >=20 > > > -----Original Message----- > > > From: qui...@li... > > > [mailto:qui...@li...] On=20 > Behalf Of=20 > > > Alex McGlashan > > > Sent: Wednesday, September 20, 2006 2:00 PM > > > To: qui...@li... > > > Subject: Re: [Quickfixj-users] Resend Request message > > >=20 > > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > > QuickFIX/J Support: http://www.quickfixj.org/support/ Hi Toby, > > >=20 > > > Thanks for the info and links - very helpful. > > >=20 > > > I now know why the sequence numbers are getting out of sync. =20 > > > What is happening is that when I initiate a logout, I wait for my=20 > > > onLogout callback method to be called and then shut down my > > adaptor. =20 > > > The message log indicates that I do indeed receive a logout > > response > > > message: > > >=20 > > > = 8=3DFIX.4.2=019=3D65=0135=3D5=0134=3D189=0149=3Dscbbanku2fixmaker=0152=3D= 20060920-11 > > > :40:39.501 > > > =0156=3DCNX=0110=3D001=01 > > > = 8=3DFIX.4.2=019=3D62=0135=3D5=0149=3DCNX=0156=3Dscbbanku2fixmaker=0134=3D= 1481=0152=3D200 > > > 60920-11:4 > > > 1:52=0110=3D098=01 > > >=20 > > > However, the sequence number for the incoming message=20 > stream is not > > > incremented: > > >=20 > > > 190:1481 > > >=20 > > > I notice, also, that my fromAdmin method is not called with the=20 > > > incoming logout message. > > >=20 > > > How do I ensure that my seqnums file is incremented correctly? > > >=20 > > > Thanks in advance, > > >=20 > > > Alex > > >=20 > > >=20 > > >=20 > > > -----Original Message----- > > > From: qui...@li... > > > [mailto:qui...@li...] On=20 > Behalf Of=20 > > > Shepheard, Toby (London) > > > Sent: 15 September 2006 16:34 > > > To: qui...@li... > > > Subject: Re: [Quickfixj-users] Resend Request message > > >=20 > > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > > QuickFIX/J Support: http://www.quickfixj.org/support/ You=20 > have some=20 > > > control over what QuickFIX will do, but it does depend on you to=20 > > > configure it appropriately. See=20 > > > http://www.quickfixj.org/quickfixj/usermanual/usage/configurat > > > ion.html#M > > > iscellaneous - in particular it sounds like you need to=20 > be setting=20 > > > SendResetSeqNumFlag=3DY. If the counterparty expects you to > > start at 0 > > > for each session and you're continuing with the last > > session's seqNum, > > > then that will be causing problems. Setting this flag to Y > > will make > > > QFJ automatically reset to 0 when it initiates a login. > > >=20 > > > As mentioned before, without seeing logs and your config > > I'm playing a > > > bit of a guessing game; if you continue to have problems > > then it would > > > really help to see these. > > >=20 > > >=20 > > > I also recommend reading the FIX spec on session > > management, available > > > from > > >=20 > >=20 > http://www.fixprotocol.org/documents/347/fix-44_w_Errata_20030618.zip > > > (you may need to login first). I think it's the 2nd document that=20 > > > covers session behaviour, sequence number usage etc. > > >=20 > > >=20 > > >=20 > > > -----Original Message----- > > > From: qui...@li... > > > [mailto:qui...@li...] On=20 > Behalf Of=20 > > > Alex McGlashan > > > Sent: 15 September 2006 15:16 > > > To: qui...@li... > > > Subject: Re: [Quickfixj-users] Resend Request message > > >=20 > > >=20 > > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > > QuickFIX/J Support: http://www.quickfixj.org/support/ > > Thanks Toby, I > > > think you're correct about the first sequence number being > > out. What > > > seems to be happening is that the counterparty is sending me a=20 > > > ResendRequest message in the expectation that my seqnums > > file will be > > > updated to match the NewSeqNo value. My question now is: > > > should QuickFIX update the seqnums file automatically or is this=20 > > > functionality I need to code for. If the former, it > > doesn't seem to > > > be working, if the latter, how? > > >=20 > > > Regards, > > >=20 > > > Alex > > >=20 > > >=20 > > > -----Original Message----- > > > From: qui...@li... > > > [mailto:qui...@li...] On=20 > Behalf Of=20 > > > Shepheard, Toby (London) > > > Sent: 14 September 2006 09:19 > > > To: qui...@li... > > > Subject: Re: [Quickfixj-users] Resend Request message > > >=20 > > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > > QuickFIX/J Support: http://www.quickfixj.org/support/ 1. Is > > it sending > > > the ResendRequest near the start of the session? > > > If so, it may be that although the messages are in > > sequence, the first > > > sequence number received is not as expected. There are > > various config > > > settings for resetting the sequence number, and you have to > > make sure > > > you configure it to match what the counterparty is doing.=20 > The fact=20 > > > that deleting your seqnums file resolved the issue temporarily=20 > > > suggests that this might well be the problem. > > >=20 > > > 2. Strange, it should handle this ok. Is your message=20 > store working=20 > > > properly? I'm not very familiar with gap-fills I'm afraid. > > >=20 > > > I think some logs files and your config file may be needed > > to really > > > work out what's going on - either that or someone else's > > expertise who > > > knows more about it than I do :) > > >=20 > > > Rgds > > > Toby > > >=20 > > >=20 > > > -----Original Message----- > > > From: qui...@li... > > > [mailto:qui...@li...] On=20 > Behalf Of=20 > > > Alex McGlashan > > > Sent: 13 September 2006 18:25 > > > To: qui...@li... > > > Subject: Re: [Quickfixj-users] Resend Request message > > >=20 > > >=20 > > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > > QuickFIX/J Support: http://www.quickfixj.org/support/=20 > Unfortunately=20 > > > that was a temporary fix - I do have an issue with=20 > sequence numbers=20 > > > after all. > > >=20 > > > As described earlier, my QuickFIX is sending a > > ResendRequest and the > > > counterparty is responding with a SequenceReset with > > GapFillFlag =3D Y, > > > at which point my QuickFIX stops handling QuoteRequests. > > >=20 > > > My questions are: > > >=20 > > > 1. The logs indicate that the incoming messages are in > > sequence i.e. > > > there are no gaps, so why is QuickFIX is sending the > > ResendRequest in > > > the first place? > > >=20 > > > 2. Why is QuickFIX not handling the gap fill message correctly? > > > Shouldn't it just carry on receiving messages? > > >=20 > > > I have lots of logs and diagnostics and am running out of > > ideas so any > > > help would be very much appreciated. > > >=20 > > > Alex > > > -------------------------------------------------------- > > >=20 > > > If you are not an intended recipient of this e-mail, please > > notify the > > > sender, delete it and do not read, act upon, print,=20 > disclose, copy,=20 > > > retain or redistribute it. Click here for important=20 > additional terms > > > relating to this e-mail. http://www.ml.com/email_terms/ > > > -------------------------------------------------------- > > >=20 > > > -------------------------------------------------------------- > > > ---------- > > > - > > > Using Tomcat but need to do more? Need to support web services,=20 > > > security? > > > Get stuff done quickly with pre-integrated technology to > > make your job > > > easier Download IBM WebSphere Application Server > > > v.1.0.1 based on Apache Geronimo > > > = http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057& > > > dat=3D121642 > > > _______________________________________________ > > > Quickfixj-users mailing list > > > Qui...@li... > > > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > > >=20 > > > Eurobase International Limited and its subsidiaries > > > (Eurobase) are unable to exercise control over the content of=20 > > > information in E-Mails. Any views and opinions expressed may be=20 > > > personal to the sender and are not necessarily those of Eurobase. > > > Eurobase will not enter into any contractual obligations in > > respect of > > > any part of its business in any E-mail. > > >=20 > > > Privileged / confidential information may be contained in > > this message > > > and /or any attachments. This E-mail is intended for the=20 > use of the > > > addressee(s) only and may contain confidential information.=20 > > If you are > > > not the / an intended recipient, you are hereby notified > > that any use > > > or dissemination of this communication is strictly prohibited. > > > If you receive this transmission in error, please notify us=20 > > > immediately, and then delete this E-mail. > > >=20 > > > Neither the sender nor Eurobase accepts any liability > > whatsoever for > > > any defects of any kind either in or arising from this E-mail=20 > > > transmission. E-Mail transmission cannot be guaranteed to > > be secure or > > > error-free, as messages can be intercepted, lost, corrupted,=20 > > > destroyed, contain viruses, or arrive late or incomplete.=20 > Eurobase=20 > > > does not accept any responsibility for viruses and it is your=20 > > > responsibility to scan any attachments. > > >=20 > > > Registered Address: Essex House, 2 County Place,=20 > Chelmsford, Essex > > > CM2 0RE, United Kingdom > > >=20 > > >=20 > > > -------------------------------------------------------------- > > > ----------- > > > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > > > SourceForge.net's Techsay panel and you'll get the chance=20 > to share=20 > > > your opinions on IT & business topics through brief=20 > surveys -- and=20 > > > earn cash=20 > > > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > > > &CID=3DDEVDEV > > > _______________________________________________ > > > Quickfixj-users mailing list > > > Qui...@li... > > > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > > >=20 > >=20 > >=20 > > -------------------------------------------------------------- > > ---------- > > - > > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > > SourceForge.net's Techsay panel and you'll get the chance to share=20 > > your opinions on IT & business topics through brief surveys -- and=20 > > earn cash=20 > > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > > &CID=3DDEVDE > > V > > _______________________________________________ > > Quickfixj-users mailing list > > Qui...@li... > > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > >=20 > > -------------------------------------------------------------- > > ----------- > > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > > SourceForge.net's Techsay panel and you'll get the chance to share=20 > > your opinions on IT & business topics through brief surveys -- and=20 > > earn cash=20 > > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > > &CID=3DDEVDEV > > _______________________________________________ > > Quickfixj-users mailing list > > Qui...@li... > > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > >=20 >=20 >=20 > -------------------------------------------------------------- > ---------- > - > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys -- and earn cash=20 > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > &CID=3DDEVDE > V > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys -- and earn cash=20 > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > &CID=3DDEVDEV > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users >=20 ------------------------------------------------------------------------ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDE V _______________________________________________ Quickfixj-users mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
|
From: Steve B. <st...@te...> - 2006-09-20 14:27:17
|
It depends on the LogFactory you are using. If you are using the FileLogFactory, there should be a file ending with "event.log" in the location specified by your configuration. Steve=20 > -----Original Message----- > From: qui...@li...=20 > [mailto:qui...@li...] On=20 > Behalf Of Alex McGlashan > Sent: Wednesday, September 20, 2006 4:18 PM > To: qui...@li... > Subject: Re: [Quickfixj-users] Resend Request message >=20 > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ Hi Steve, >=20 > Possibly not - how should I do that? >=20 > Alex >=20 > -----Original Message----- > From: qui...@li... > [mailto:qui...@li...] On=20 > Behalf Of Steve Bate > Sent: 20 September 2006 15:13 > To: qui...@li... > Subject: Re: [Quickfixj-users] Resend Request message >=20 > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ Hi Alex, >=20 > Are you logging QFJ events in addition to messages? The log=20 > you provided appears to include your application log=20 > messages and the QFJ FIX messages but I don't see any QFJ events. >=20 > Steve >=20 > > -----Original Message----- > > From: qui...@li... > > [mailto:qui...@li...] On Behalf Of=20 > > Alex McGlashan > > Sent: Wednesday, September 20, 2006 3:48 PM > > To: qui...@li... > > Subject: Re: [Quickfixj-users] Resend Request message > >=20 > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > QuickFIX/J Support: http://www.quickfixj.org/support/ Hi Steve, > >=20 > > There are no exceptions in the system out - here is the output from=20 > > another shutdown: > >=20 > > [20/09/06 13:57:18 BST] Service stopping > > [20/09/06 13:57:18 BST] : ESPMessageManager: entering close > > [20/09/06 13:57:18 BST] Alex: : ESPConnector: entering disconnect > > [20/09/06 13:57:18 BST] Alex: : ESPConnector: entering sendLogout > > [20/09/06 13:57:18 BST] TwistManager: timeout closedown now running > > [20/09/06 13:57:18 BST] Alex: : ESPConnector: entering send > > - message =3D 8=3DFIX.4.2=019=3D5=0135=3D5=0110=3D166=01 > > [20/09/06 13:57:18 BST] Alex: : ESPConnector: FIXHandler toAdmin -=20 > > message type =3D 5 message =3D > > = 8=3DFIX.4.2=019=3D65=0135=3D5=0134=3D299=0149=3Dscbbanku2fixmaker=0152=3D= 20060920-12 > > :57:18.266 > > =0156=3DCNX=0110=3D017=01 > > [20/09/06 13:57:18 BST] Alex: : ESPConnector: waiting for=20 > connection=20 > > status > > [20/09/06 13:57:18 BST] Alex: : ESPConnector: FIXHandler onLogout > > [20/09/06 13:57:18 BST] Alex: : ESPCOnnector: notifying=20 > > connectionWaiter listeners > > [20/09/06 13:57:18 BST] Alex debug: entering setConnected > > [20/09/06 13:57:18 BST] Alex debug: setConnected - got lock > > [20/09/06 13:57:18 BST] Alex debug: setConnected - set=20 > connected to=20 > > false > > [20/09/06 13:57:18 BST] Alex debug: exiting setConnected > > [20/09/06 13:57:18 BST] Alex: : ESPConnector: exiting disconnect > > [20/09/06 13:57:18 BST] Service stopped > >=20 > > And the message log for the same time (the server is 1 hour behind): > >=20 > > = 8=3DFIX.4.2=019=3D65=0135=3D5=0134=3D299=0149=3Dscbbanku2fixmaker=0152=3D= 20060920-12 > > :57:18.266 > > =0156=3DCNX=0110=3D017=01 > > = 8=3DFIX.4.2=019=3D62=0135=3D5=0149=3DCNX=0156=3Dscbbanku2fixmaker=0134=3D= 1739=0152=3D200 > > 60920-12:5 > > 8:31=0110=3D110=01 > >=20 > > And the seqnums file after shutdown: > >=20 > > 300:1739 > >=20 > > Are there any other diagnostics that could shed more light on this? > >=20 > > Thanks, > >=20 > > Alex > >=20 > >=20 > >=20 > >=20 > > -----Original Message----- > > From: qui...@li... > > [mailto:qui...@li...] On Behalf Of=20 > > Steve Bate > > Sent: 20 September 2006 14:30 > > To: qui...@li... > > Subject: Re: [Quickfixj-users] Resend Request message > >=20 > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > QuickFIX/J Support: http://www.quickfixj.org/support/ Hi Alex, > >=20 > > Does the log indicate any validation errors or exceptions when=20 > > processing the logout acknowledgement? For example, if there is an=20 > > exception while verifying the logout ack, the fromAdmin=20 > callback will=20 > > not be called although the onLogout callback will be called=20 > during the=20 > > subsequent disconnect. > >=20 > > Steve > >=20 > > > -----Original Message----- > > > From: qui...@li... > > > [mailto:qui...@li...] On=20 > Behalf Of=20 > > > Alex McGlashan > > > Sent: Wednesday, September 20, 2006 2:00 PM > > > To: qui...@li... > > > Subject: Re: [Quickfixj-users] Resend Request message > > >=20 > > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > > QuickFIX/J Support: http://www.quickfixj.org/support/ Hi Toby, > > >=20 > > > Thanks for the info and links - very helpful. > > >=20 > > > I now know why the sequence numbers are getting out of sync. =20 > > > What is happening is that when I initiate a logout, I wait for my=20 > > > onLogout callback method to be called and then shut down my > > adaptor. =20 > > > The message log indicates that I do indeed receive a logout > > response > > > message: > > >=20 > > > = 8=3DFIX.4.2=019=3D65=0135=3D5=0134=3D189=0149=3Dscbbanku2fixmaker=0152=3D= 20060920-11 > > > :40:39.501 > > > =0156=3DCNX=0110=3D001=01 > > > = 8=3DFIX.4.2=019=3D62=0135=3D5=0149=3DCNX=0156=3Dscbbanku2fixmaker=0134=3D= 1481=0152=3D200 > > > 60920-11:4 > > > 1:52=0110=3D098=01 > > >=20 > > > However, the sequence number for the incoming message=20 > stream is not > > > incremented: > > >=20 > > > 190:1481 > > >=20 > > > I notice, also, that my fromAdmin method is not called with the=20 > > > incoming logout message. > > >=20 > > > How do I ensure that my seqnums file is incremented correctly? > > >=20 > > > Thanks in advance, > > >=20 > > > Alex > > >=20 > > >=20 > > >=20 > > > -----Original Message----- > > > From: qui...@li... > > > [mailto:qui...@li...] On=20 > Behalf Of=20 > > > Shepheard, Toby (London) > > > Sent: 15 September 2006 16:34 > > > To: qui...@li... > > > Subject: Re: [Quickfixj-users] Resend Request message > > >=20 > > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > > QuickFIX/J Support: http://www.quickfixj.org/support/ You=20 > have some=20 > > > control over what QuickFIX will do, but it does depend on you to=20 > > > configure it appropriately. See=20 > > > http://www.quickfixj.org/quickfixj/usermanual/usage/configurat > > > ion.html#M > > > iscellaneous - in particular it sounds like you need to=20 > be setting=20 > > > SendResetSeqNumFlag=3DY. If the counterparty expects you to > > start at 0 > > > for each session and you're continuing with the last > > session's seqNum, > > > then that will be causing problems. Setting this flag to Y > > will make > > > QFJ automatically reset to 0 when it initiates a login. > > >=20 > > > As mentioned before, without seeing logs and your config > > I'm playing a > > > bit of a guessing game; if you continue to have problems > > then it would > > > really help to see these. > > >=20 > > >=20 > > > I also recommend reading the FIX spec on session > > management, available > > > from > > >=20 > >=20 > http://www.fixprotocol.org/documents/347/fix-44_w_Errata_20030618.zip > > > (you may need to login first). I think it's the 2nd document that=20 > > > covers session behaviour, sequence number usage etc. > > >=20 > > >=20 > > >=20 > > > -----Original Message----- > > > From: qui...@li... > > > [mailto:qui...@li...] On=20 > Behalf Of=20 > > > Alex McGlashan > > > Sent: 15 September 2006 15:16 > > > To: qui...@li... > > > Subject: Re: [Quickfixj-users] Resend Request message > > >=20 > > >=20 > > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > > QuickFIX/J Support: http://www.quickfixj.org/support/ > > Thanks Toby, I > > > think you're correct about the first sequence number being > > out. What > > > seems to be happening is that the counterparty is sending me a=20 > > > ResendRequest message in the expectation that my seqnums > > file will be > > > updated to match the NewSeqNo value. My question now is: > > > should QuickFIX update the seqnums file automatically or is this=20 > > > functionality I need to code for. If the former, it > > doesn't seem to > > > be working, if the latter, how? > > >=20 > > > Regards, > > >=20 > > > Alex > > >=20 > > >=20 > > > -----Original Message----- > > > From: qui...@li... > > > [mailto:qui...@li...] On=20 > Behalf Of=20 > > > Shepheard, Toby (London) > > > Sent: 14 September 2006 09:19 > > > To: qui...@li... > > > Subject: Re: [Quickfixj-users] Resend Request message > > >=20 > > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > > QuickFIX/J Support: http://www.quickfixj.org/support/ 1. Is > > it sending > > > the ResendRequest near the start of the session? > > > If so, it may be that although the messages are in > > sequence, the first > > > sequence number received is not as expected. There are > > various config > > > settings for resetting the sequence number, and you have to > > make sure > > > you configure it to match what the counterparty is doing.=20 > The fact=20 > > > that deleting your seqnums file resolved the issue temporarily=20 > > > suggests that this might well be the problem. > > >=20 > > > 2. Strange, it should handle this ok. Is your message=20 > store working=20 > > > properly? I'm not very familiar with gap-fills I'm afraid. > > >=20 > > > I think some logs files and your config file may be needed > > to really > > > work out what's going on - either that or someone else's > > expertise who > > > knows more about it than I do :) > > >=20 > > > Rgds > > > Toby > > >=20 > > >=20 > > > -----Original Message----- > > > From: qui...@li... > > > [mailto:qui...@li...] On=20 > Behalf Of=20 > > > Alex McGlashan > > > Sent: 13 September 2006 18:25 > > > To: qui...@li... > > > Subject: Re: [Quickfixj-users] Resend Request message > > >=20 > > >=20 > > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > > QuickFIX/J Support: http://www.quickfixj.org/support/=20 > Unfortunately=20 > > > that was a temporary fix - I do have an issue with=20 > sequence numbers=20 > > > after all. > > >=20 > > > As described earlier, my QuickFIX is sending a > > ResendRequest and the > > > counterparty is responding with a SequenceReset with > > GapFillFlag =3D Y, > > > at which point my QuickFIX stops handling QuoteRequests. > > >=20 > > > My questions are: > > >=20 > > > 1. The logs indicate that the incoming messages are in > > sequence i.e. > > > there are no gaps, so why is QuickFIX is sending the > > ResendRequest in > > > the first place? > > >=20 > > > 2. Why is QuickFIX not handling the gap fill message correctly? > > > Shouldn't it just carry on receiving messages? > > >=20 > > > I have lots of logs and diagnostics and am running out of > > ideas so any > > > help would be very much appreciated. > > >=20 > > > Alex > > > -------------------------------------------------------- > > >=20 > > > If you are not an intended recipient of this e-mail, please > > notify the > > > sender, delete it and do not read, act upon, print,=20 > disclose, copy,=20 > > > retain or redistribute it. Click here for important=20 > additional terms > > > relating to this e-mail. http://www.ml.com/email_terms/ > > > -------------------------------------------------------- > > >=20 > > > -------------------------------------------------------------- > > > ---------- > > > - > > > Using Tomcat but need to do more? Need to support web services,=20 > > > security? > > > Get stuff done quickly with pre-integrated technology to > > make your job > > > easier Download IBM WebSphere Application Server > > > v.1.0.1 based on Apache Geronimo > > > = http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057& > > > dat=3D121642 > > > _______________________________________________ > > > Quickfixj-users mailing list > > > Qui...@li... > > > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > > >=20 > > > Eurobase International Limited and its subsidiaries > > > (Eurobase) are unable to exercise control over the content of=20 > > > information in E-Mails. Any views and opinions expressed may be=20 > > > personal to the sender and are not necessarily those of Eurobase. > > > Eurobase will not enter into any contractual obligations in > > respect of > > > any part of its business in any E-mail. > > >=20 > > > Privileged / confidential information may be contained in > > this message > > > and /or any attachments. This E-mail is intended for the=20 > use of the > > > addressee(s) only and may contain confidential information.=20 > > If you are > > > not the / an intended recipient, you are hereby notified > > that any use > > > or dissemination of this communication is strictly prohibited. > > > If you receive this transmission in error, please notify us=20 > > > immediately, and then delete this E-mail. > > >=20 > > > Neither the sender nor Eurobase accepts any liability > > whatsoever for > > > any defects of any kind either in or arising from this E-mail=20 > > > transmission. E-Mail transmission cannot be guaranteed to > > be secure or > > > error-free, as messages can be intercepted, lost, corrupted,=20 > > > destroyed, contain viruses, or arrive late or incomplete.=20 > Eurobase=20 > > > does not accept any responsibility for viruses and it is your=20 > > > responsibility to scan any attachments. > > >=20 > > > Registered Address: Essex House, 2 County Place,=20 > Chelmsford, Essex > > > CM2 0RE, United Kingdom > > >=20 > > >=20 > > > -------------------------------------------------------------- > > > ----------- > > > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > > > SourceForge.net's Techsay panel and you'll get the chance=20 > to share=20 > > > your opinions on IT & business topics through brief=20 > surveys -- and=20 > > > earn cash=20 > > > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > > > &CID=3DDEVDEV > > > _______________________________________________ > > > Quickfixj-users mailing list > > > Qui...@li... > > > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > > >=20 > >=20 > >=20 > > -------------------------------------------------------------- > > ---------- > > - > > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > > SourceForge.net's Techsay panel and you'll get the chance to share=20 > > your opinions on IT & business topics through brief surveys -- and=20 > > earn cash=20 > > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > > &CID=3DDEVDE > > V > > _______________________________________________ > > Quickfixj-users mailing list > > Qui...@li... > > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > >=20 > > -------------------------------------------------------------- > > ----------- > > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > > SourceForge.net's Techsay panel and you'll get the chance to share=20 > > your opinions on IT & business topics through brief surveys -- and=20 > > earn cash=20 > > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > > &CID=3DDEVDEV > > _______________________________________________ > > Quickfixj-users mailing list > > Qui...@li... > > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > >=20 >=20 >=20 > -------------------------------------------------------------- > ---------- > - > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys -- and earn cash=20 > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > &CID=3DDEVDE > V > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys -- and earn cash=20 > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > &CID=3DDEVDEV > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users >=20 |
|
From: Alex M. <ale...@eu...> - 2006-09-20 14:19:37
|
Hi Steve, Possibly not - how should I do that? Alex -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Steve Bate Sent: 20 September 2006 15:13 To: qui...@li... Subject: Re: [Quickfixj-users] Resend Request message QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ Hi Alex, Are you logging QFJ events in addition to messages? The log you=20 provided appears to include your application log messages and=20 the QFJ FIX messages but I don't see any QFJ events. Steve > -----Original Message----- > From: qui...@li...=20 > [mailto:qui...@li...] On=20 > Behalf Of Alex McGlashan > Sent: Wednesday, September 20, 2006 3:48 PM > To: qui...@li... > Subject: Re: [Quickfixj-users] Resend Request message >=20 > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ Hi Steve, >=20 > There are no exceptions in the system out - here is the=20 > output from another shutdown: >=20 > [20/09/06 13:57:18 BST] Service stopping > [20/09/06 13:57:18 BST] : ESPMessageManager: entering close > [20/09/06 13:57:18 BST] Alex: : ESPConnector: entering disconnect > [20/09/06 13:57:18 BST] Alex: : ESPConnector: entering sendLogout > [20/09/06 13:57:18 BST] TwistManager: timeout closedown now running > [20/09/06 13:57:18 BST] Alex: : ESPConnector: entering send=20 > - message =3D 8=3DFIX.4.2=019=3D5=0135=3D5=0110=3D166=01 > [20/09/06 13:57:18 BST] Alex: : ESPConnector: FIXHandler=20 > toAdmin - message type =3D 5 message =3D > = 8=3DFIX.4.2=019=3D65=0135=3D5=0134=3D299=0149=3Dscbbanku2fixmaker=0152=3D= 20060920-12 > :57:18.266 > =0156=3DCNX=0110=3D017=01 > [20/09/06 13:57:18 BST] Alex: : ESPConnector: waiting for=20 > connection status > [20/09/06 13:57:18 BST] Alex: : ESPConnector: FIXHandler onLogout > [20/09/06 13:57:18 BST] Alex: : ESPCOnnector: notifying=20 > connectionWaiter listeners > [20/09/06 13:57:18 BST] Alex debug: entering setConnected > [20/09/06 13:57:18 BST] Alex debug: setConnected - got lock > [20/09/06 13:57:18 BST] Alex debug: setConnected - set=20 > connected to false > [20/09/06 13:57:18 BST] Alex debug: exiting setConnected > [20/09/06 13:57:18 BST] Alex: : ESPConnector: exiting disconnect > [20/09/06 13:57:18 BST] Service stopped >=20 > And the message log for the same time (the server is 1 hour behind): >=20 > = 8=3DFIX.4.2=019=3D65=0135=3D5=0134=3D299=0149=3Dscbbanku2fixmaker=0152=3D= 20060920-12 > :57:18.266 > =0156=3DCNX=0110=3D017=01 > = 8=3DFIX.4.2=019=3D62=0135=3D5=0149=3DCNX=0156=3Dscbbanku2fixmaker=0134=3D= 1739=0152=3D200 > 60920-12:5 > 8:31=0110=3D110=01 >=20 > And the seqnums file after shutdown: >=20 > 300:1739 >=20 > Are there any other diagnostics that could shed more light on this? >=20 > Thanks, >=20 > Alex >=20 >=20 >=20 >=20 > -----Original Message----- > From: qui...@li... > [mailto:qui...@li...] On=20 > Behalf Of Steve Bate > Sent: 20 September 2006 14:30 > To: qui...@li... > Subject: Re: [Quickfixj-users] Resend Request message >=20 > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ Hi Alex, >=20 > Does the log indicate any validation errors or exceptions=20 > when processing the logout acknowledgement? For example, if=20 > there is an exception while verifying the logout ack, the=20 > fromAdmin callback will not be called although the onLogout=20 > callback will be called during the subsequent disconnect. >=20 > Steve >=20 > > -----Original Message----- > > From: qui...@li... > > [mailto:qui...@li...] On Behalf Of=20 > > Alex McGlashan > > Sent: Wednesday, September 20, 2006 2:00 PM > > To: qui...@li... > > Subject: Re: [Quickfixj-users] Resend Request message > >=20 > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > QuickFIX/J Support: http://www.quickfixj.org/support/ Hi Toby, > >=20 > > Thanks for the info and links - very helpful. > >=20 > > I now know why the sequence numbers are getting out of sync. =20 > > What is happening is that when I initiate a logout, I wait for my=20 > > onLogout callback method to be called and then shut down my=20 > adaptor. =20 > > The message log indicates that I do indeed receive a logout=20 > response=20 > > message: > >=20 > > = 8=3DFIX.4.2=019=3D65=0135=3D5=0134=3D189=0149=3Dscbbanku2fixmaker=0152=3D= 20060920-11 > > :40:39.501 > > =0156=3DCNX=0110=3D001=01 > > = 8=3DFIX.4.2=019=3D62=0135=3D5=0149=3DCNX=0156=3Dscbbanku2fixmaker=0134=3D= 1481=0152=3D200 > > 60920-11:4 > > 1:52=0110=3D098=01 > >=20 > > However, the sequence number for the incoming message stream is not > > incremented: > >=20 > > 190:1481 > >=20 > > I notice, also, that my fromAdmin method is not called with the=20 > > incoming logout message. > >=20 > > How do I ensure that my seqnums file is incremented correctly? > >=20 > > Thanks in advance, > >=20 > > Alex > >=20 > >=20 > >=20 > > -----Original Message----- > > From: qui...@li... > > [mailto:qui...@li...] On Behalf Of=20 > > Shepheard, Toby (London) > > Sent: 15 September 2006 16:34 > > To: qui...@li... > > Subject: Re: [Quickfixj-users] Resend Request message > >=20 > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > QuickFIX/J Support: http://www.quickfixj.org/support/ You have some=20 > > control over what QuickFIX will do, but it does depend on you to=20 > > configure it appropriately. See=20 > > http://www.quickfixj.org/quickfixj/usermanual/usage/configurat > > ion.html#M > > iscellaneous - in particular it sounds like you need to be setting=20 > > SendResetSeqNumFlag=3DY. If the counterparty expects you to=20 > start at 0=20 > > for each session and you're continuing with the last=20 > session's seqNum,=20 > > then that will be causing problems. Setting this flag to Y=20 > will make=20 > > QFJ automatically reset to 0 when it initiates a login. > >=20 > > As mentioned before, without seeing logs and your config=20 > I'm playing a=20 > > bit of a guessing game; if you continue to have problems=20 > then it would=20 > > really help to see these. > >=20 > >=20 > > I also recommend reading the FIX spec on session=20 > management, available=20 > > from=20 > >=20 > http://www.fixprotocol.org/documents/347/fix-44_w_Errata_20030618.zip > > (you may need to login first). I think it's the 2nd document that=20 > > covers session behaviour, sequence number usage etc. > >=20 > >=20 > >=20 > > -----Original Message----- > > From: qui...@li... > > [mailto:qui...@li...] On Behalf Of=20 > > Alex McGlashan > > Sent: 15 September 2006 15:16 > > To: qui...@li... > > Subject: Re: [Quickfixj-users] Resend Request message > >=20 > >=20 > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > QuickFIX/J Support: http://www.quickfixj.org/support/=20 > Thanks Toby, I=20 > > think you're correct about the first sequence number being=20 > out. What=20 > > seems to be happening is that the counterparty is sending me a=20 > > ResendRequest message in the expectation that my seqnums=20 > file will be=20 > > updated to match the NewSeqNo value. My question now is: > > should QuickFIX update the seqnums file automatically or is this=20 > > functionality I need to code for. If the former, it=20 > doesn't seem to=20 > > be working, if the latter, how? > >=20 > > Regards, > >=20 > > Alex > >=20 > >=20 > > -----Original Message----- > > From: qui...@li... > > [mailto:qui...@li...] On Behalf Of=20 > > Shepheard, Toby (London) > > Sent: 14 September 2006 09:19 > > To: qui...@li... > > Subject: Re: [Quickfixj-users] Resend Request message > >=20 > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > QuickFIX/J Support: http://www.quickfixj.org/support/ 1. Is=20 > it sending=20 > > the ResendRequest near the start of the session? > > If so, it may be that although the messages are in=20 > sequence, the first=20 > > sequence number received is not as expected. There are=20 > various config=20 > > settings for resetting the sequence number, and you have to=20 > make sure=20 > > you configure it to match what the counterparty is doing. The fact=20 > > that deleting your seqnums file resolved the issue temporarily=20 > > suggests that this might well be the problem. > >=20 > > 2. Strange, it should handle this ok. Is your message store working=20 > > properly? I'm not very familiar with gap-fills I'm afraid. > >=20 > > I think some logs files and your config file may be needed=20 > to really=20 > > work out what's going on - either that or someone else's=20 > expertise who=20 > > knows more about it than I do :) > >=20 > > Rgds > > Toby > >=20 > >=20 > > -----Original Message----- > > From: qui...@li... > > [mailto:qui...@li...] On Behalf Of=20 > > Alex McGlashan > > Sent: 13 September 2006 18:25 > > To: qui...@li... > > Subject: Re: [Quickfixj-users] Resend Request message > >=20 > >=20 > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > QuickFIX/J Support: http://www.quickfixj.org/support/ Unfortunately=20 > > that was a temporary fix - I do have an issue with sequence numbers=20 > > after all. > >=20 > > As described earlier, my QuickFIX is sending a=20 > ResendRequest and the=20 > > counterparty is responding with a SequenceReset with=20 > GapFillFlag =3D Y,=20 > > at which point my QuickFIX stops handling QuoteRequests. > >=20 > > My questions are: > >=20 > > 1. The logs indicate that the incoming messages are in=20 > sequence i.e. > > there are no gaps, so why is QuickFIX is sending the=20 > ResendRequest in=20 > > the first place? > >=20 > > 2. Why is QuickFIX not handling the gap fill message correctly? > > Shouldn't it just carry on receiving messages? > >=20 > > I have lots of logs and diagnostics and am running out of=20 > ideas so any=20 > > help would be very much appreciated. > >=20 > > Alex > > -------------------------------------------------------- > >=20 > > If you are not an intended recipient of this e-mail, please=20 > notify the=20 > > sender, delete it and do not read, act upon, print, disclose, copy,=20 > > retain or redistribute it. Click here for important additional terms > > relating to this e-mail. http://www.ml.com/email_terms/ > > -------------------------------------------------------- > >=20 > > -------------------------------------------------------------- > > ---------- > > - > > Using Tomcat but need to do more? Need to support web services,=20 > > security? > > Get stuff done quickly with pre-integrated technology to=20 > make your job=20 > > easier Download IBM WebSphere Application Server > > v.1.0.1 based on Apache Geronimo > > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057& > > dat=3D121642 > > _______________________________________________ > > Quickfixj-users mailing list > > Qui...@li... > > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > >=20 > > Eurobase International Limited and its subsidiaries > > (Eurobase) are unable to exercise control over the content of=20 > > information in E-Mails. Any views and opinions expressed may be=20 > > personal to the sender and are not necessarily those of Eurobase.=20 > > Eurobase will not enter into any contractual obligations in=20 > respect of=20 > > any part of its business in any E-mail. > >=20 > > Privileged / confidential information may be contained in=20 > this message=20 > > and /or any attachments. This E-mail is intended for the use of the=20 > > addressee(s) only and may contain confidential information.=20 > If you are=20 > > not the / an intended recipient, you are hereby notified=20 > that any use=20 > > or dissemination of this communication is strictly prohibited. > > If you receive this transmission in error, please notify us=20 > > immediately, and then delete this E-mail. > >=20 > > Neither the sender nor Eurobase accepts any liability=20 > whatsoever for=20 > > any defects of any kind either in or arising from this E-mail=20 > > transmission. E-Mail transmission cannot be guaranteed to=20 > be secure or=20 > > error-free, as messages can be intercepted, lost, corrupted,=20 > > destroyed, contain viruses, or arrive late or incomplete. Eurobase=20 > > does not accept any responsibility for viruses and it is your=20 > > responsibility to scan any attachments. > >=20 > > Registered Address: Essex House, 2 County Place, Chelmsford, Essex=20 > > CM2 0RE, United Kingdom > >=20 > >=20 > > -------------------------------------------------------------- > > ----------- > > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > > SourceForge.net's Techsay panel and you'll get the chance to share=20 > > your opinions on IT & business topics through brief surveys -- and=20 > > earn cash=20 > > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > > &CID=3DDEVDEV > > _______________________________________________ > > Quickfixj-users mailing list > > Qui...@li... > > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > >=20 >=20 >=20 > -------------------------------------------------------------- > ---------- > - > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys -- and earn cash=20 > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > &CID=3DDEVDE > V > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys -- and earn cash=20 > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > &CID=3DDEVDEV > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users >=20 ------------------------------------------------------------------------ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDE V _______________________________________________ Quickfixj-users mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
|
From: Steve B. <st...@te...> - 2006-09-20 14:11:31
|
Hi Alex, Are you logging QFJ events in addition to messages? The log you=20 provided appears to include your application log messages and=20 the QFJ FIX messages but I don't see any QFJ events. Steve > -----Original Message----- > From: qui...@li...=20 > [mailto:qui...@li...] On=20 > Behalf Of Alex McGlashan > Sent: Wednesday, September 20, 2006 3:48 PM > To: qui...@li... > Subject: Re: [Quickfixj-users] Resend Request message >=20 > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ Hi Steve, >=20 > There are no exceptions in the system out - here is the=20 > output from another shutdown: >=20 > [20/09/06 13:57:18 BST] Service stopping > [20/09/06 13:57:18 BST] : ESPMessageManager: entering close > [20/09/06 13:57:18 BST] Alex: : ESPConnector: entering disconnect > [20/09/06 13:57:18 BST] Alex: : ESPConnector: entering sendLogout > [20/09/06 13:57:18 BST] TwistManager: timeout closedown now running > [20/09/06 13:57:18 BST] Alex: : ESPConnector: entering send=20 > - message =3D 8=3DFIX.4.2=019=3D5=0135=3D5=0110=3D166=01 > [20/09/06 13:57:18 BST] Alex: : ESPConnector: FIXHandler=20 > toAdmin - message type =3D 5 message =3D > = 8=3DFIX.4.2=019=3D65=0135=3D5=0134=3D299=0149=3Dscbbanku2fixmaker=0152=3D= 20060920-12 > :57:18.266 > =0156=3DCNX=0110=3D017=01 > [20/09/06 13:57:18 BST] Alex: : ESPConnector: waiting for=20 > connection status > [20/09/06 13:57:18 BST] Alex: : ESPConnector: FIXHandler onLogout > [20/09/06 13:57:18 BST] Alex: : ESPCOnnector: notifying=20 > connectionWaiter listeners > [20/09/06 13:57:18 BST] Alex debug: entering setConnected > [20/09/06 13:57:18 BST] Alex debug: setConnected - got lock > [20/09/06 13:57:18 BST] Alex debug: setConnected - set=20 > connected to false > [20/09/06 13:57:18 BST] Alex debug: exiting setConnected > [20/09/06 13:57:18 BST] Alex: : ESPConnector: exiting disconnect > [20/09/06 13:57:18 BST] Service stopped >=20 > And the message log for the same time (the server is 1 hour behind): >=20 > = 8=3DFIX.4.2=019=3D65=0135=3D5=0134=3D299=0149=3Dscbbanku2fixmaker=0152=3D= 20060920-12 > :57:18.266 > =0156=3DCNX=0110=3D017=01 > = 8=3DFIX.4.2=019=3D62=0135=3D5=0149=3DCNX=0156=3Dscbbanku2fixmaker=0134=3D= 1739=0152=3D200 > 60920-12:5 > 8:31=0110=3D110=01 >=20 > And the seqnums file after shutdown: >=20 > 300:1739 >=20 > Are there any other diagnostics that could shed more light on this? >=20 > Thanks, >=20 > Alex >=20 >=20 >=20 >=20 > -----Original Message----- > From: qui...@li... > [mailto:qui...@li...] On=20 > Behalf Of Steve Bate > Sent: 20 September 2006 14:30 > To: qui...@li... > Subject: Re: [Quickfixj-users] Resend Request message >=20 > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ Hi Alex, >=20 > Does the log indicate any validation errors or exceptions=20 > when processing the logout acknowledgement? For example, if=20 > there is an exception while verifying the logout ack, the=20 > fromAdmin callback will not be called although the onLogout=20 > callback will be called during the subsequent disconnect. >=20 > Steve >=20 > > -----Original Message----- > > From: qui...@li... > > [mailto:qui...@li...] On Behalf Of=20 > > Alex McGlashan > > Sent: Wednesday, September 20, 2006 2:00 PM > > To: qui...@li... > > Subject: Re: [Quickfixj-users] Resend Request message > >=20 > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > QuickFIX/J Support: http://www.quickfixj.org/support/ Hi Toby, > >=20 > > Thanks for the info and links - very helpful. > >=20 > > I now know why the sequence numbers are getting out of sync. =20 > > What is happening is that when I initiate a logout, I wait for my=20 > > onLogout callback method to be called and then shut down my=20 > adaptor. =20 > > The message log indicates that I do indeed receive a logout=20 > response=20 > > message: > >=20 > > = 8=3DFIX.4.2=019=3D65=0135=3D5=0134=3D189=0149=3Dscbbanku2fixmaker=0152=3D= 20060920-11 > > :40:39.501 > > =0156=3DCNX=0110=3D001=01 > > = 8=3DFIX.4.2=019=3D62=0135=3D5=0149=3DCNX=0156=3Dscbbanku2fixmaker=0134=3D= 1481=0152=3D200 > > 60920-11:4 > > 1:52=0110=3D098=01 > >=20 > > However, the sequence number for the incoming message stream is not > > incremented: > >=20 > > 190:1481 > >=20 > > I notice, also, that my fromAdmin method is not called with the=20 > > incoming logout message. > >=20 > > How do I ensure that my seqnums file is incremented correctly? > >=20 > > Thanks in advance, > >=20 > > Alex > >=20 > >=20 > >=20 > > -----Original Message----- > > From: qui...@li... > > [mailto:qui...@li...] On Behalf Of=20 > > Shepheard, Toby (London) > > Sent: 15 September 2006 16:34 > > To: qui...@li... > > Subject: Re: [Quickfixj-users] Resend Request message > >=20 > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > QuickFIX/J Support: http://www.quickfixj.org/support/ You have some=20 > > control over what QuickFIX will do, but it does depend on you to=20 > > configure it appropriately. See=20 > > http://www.quickfixj.org/quickfixj/usermanual/usage/configurat > > ion.html#M > > iscellaneous - in particular it sounds like you need to be setting=20 > > SendResetSeqNumFlag=3DY. If the counterparty expects you to=20 > start at 0=20 > > for each session and you're continuing with the last=20 > session's seqNum,=20 > > then that will be causing problems. Setting this flag to Y=20 > will make=20 > > QFJ automatically reset to 0 when it initiates a login. > >=20 > > As mentioned before, without seeing logs and your config=20 > I'm playing a=20 > > bit of a guessing game; if you continue to have problems=20 > then it would=20 > > really help to see these. > >=20 > >=20 > > I also recommend reading the FIX spec on session=20 > management, available=20 > > from=20 > >=20 > http://www.fixprotocol.org/documents/347/fix-44_w_Errata_20030618.zip > > (you may need to login first). I think it's the 2nd document that=20 > > covers session behaviour, sequence number usage etc. > >=20 > >=20 > >=20 > > -----Original Message----- > > From: qui...@li... > > [mailto:qui...@li...] On Behalf Of=20 > > Alex McGlashan > > Sent: 15 September 2006 15:16 > > To: qui...@li... > > Subject: Re: [Quickfixj-users] Resend Request message > >=20 > >=20 > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > QuickFIX/J Support: http://www.quickfixj.org/support/=20 > Thanks Toby, I=20 > > think you're correct about the first sequence number being=20 > out. What=20 > > seems to be happening is that the counterparty is sending me a=20 > > ResendRequest message in the expectation that my seqnums=20 > file will be=20 > > updated to match the NewSeqNo value. My question now is: > > should QuickFIX update the seqnums file automatically or is this=20 > > functionality I need to code for. If the former, it=20 > doesn't seem to=20 > > be working, if the latter, how? > >=20 > > Regards, > >=20 > > Alex > >=20 > >=20 > > -----Original Message----- > > From: qui...@li... > > [mailto:qui...@li...] On Behalf Of=20 > > Shepheard, Toby (London) > > Sent: 14 September 2006 09:19 > > To: qui...@li... > > Subject: Re: [Quickfixj-users] Resend Request message > >=20 > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > QuickFIX/J Support: http://www.quickfixj.org/support/ 1. Is=20 > it sending=20 > > the ResendRequest near the start of the session? > > If so, it may be that although the messages are in=20 > sequence, the first=20 > > sequence number received is not as expected. There are=20 > various config=20 > > settings for resetting the sequence number, and you have to=20 > make sure=20 > > you configure it to match what the counterparty is doing. The fact=20 > > that deleting your seqnums file resolved the issue temporarily=20 > > suggests that this might well be the problem. > >=20 > > 2. Strange, it should handle this ok. Is your message store working=20 > > properly? I'm not very familiar with gap-fills I'm afraid. > >=20 > > I think some logs files and your config file may be needed=20 > to really=20 > > work out what's going on - either that or someone else's=20 > expertise who=20 > > knows more about it than I do :) > >=20 > > Rgds > > Toby > >=20 > >=20 > > -----Original Message----- > > From: qui...@li... > > [mailto:qui...@li...] On Behalf Of=20 > > Alex McGlashan > > Sent: 13 September 2006 18:25 > > To: qui...@li... > > Subject: Re: [Quickfixj-users] Resend Request message > >=20 > >=20 > > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > > QuickFIX/J Support: http://www.quickfixj.org/support/ Unfortunately=20 > > that was a temporary fix - I do have an issue with sequence numbers=20 > > after all. > >=20 > > As described earlier, my QuickFIX is sending a=20 > ResendRequest and the=20 > > counterparty is responding with a SequenceReset with=20 > GapFillFlag =3D Y,=20 > > at which point my QuickFIX stops handling QuoteRequests. > >=20 > > My questions are: > >=20 > > 1. The logs indicate that the incoming messages are in=20 > sequence i.e. > > there are no gaps, so why is QuickFIX is sending the=20 > ResendRequest in=20 > > the first place? > >=20 > > 2. Why is QuickFIX not handling the gap fill message correctly? > > Shouldn't it just carry on receiving messages? > >=20 > > I have lots of logs and diagnostics and am running out of=20 > ideas so any=20 > > help would be very much appreciated. > >=20 > > Alex > > -------------------------------------------------------- > >=20 > > If you are not an intended recipient of this e-mail, please=20 > notify the=20 > > sender, delete it and do not read, act upon, print, disclose, copy,=20 > > retain or redistribute it. Click here for important additional terms > > relating to this e-mail. http://www.ml.com/email_terms/ > > -------------------------------------------------------- > >=20 > > -------------------------------------------------------------- > > ---------- > > - > > Using Tomcat but need to do more? Need to support web services,=20 > > security? > > Get stuff done quickly with pre-integrated technology to=20 > make your job=20 > > easier Download IBM WebSphere Application Server > > v.1.0.1 based on Apache Geronimo > > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057& > > dat=3D121642 > > _______________________________________________ > > Quickfixj-users mailing list > > Qui...@li... > > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > >=20 > > Eurobase International Limited and its subsidiaries > > (Eurobase) are unable to exercise control over the content of=20 > > information in E-Mails. Any views and opinions expressed may be=20 > > personal to the sender and are not necessarily those of Eurobase.=20 > > Eurobase will not enter into any contractual obligations in=20 > respect of=20 > > any part of its business in any E-mail. > >=20 > > Privileged / confidential information may be contained in=20 > this message=20 > > and /or any attachments. This E-mail is intended for the use of the=20 > > addressee(s) only and may contain confidential information.=20 > If you are=20 > > not the / an intended recipient, you are hereby notified=20 > that any use=20 > > or dissemination of this communication is strictly prohibited. > > If you receive this transmission in error, please notify us=20 > > immediately, and then delete this E-mail. > >=20 > > Neither the sender nor Eurobase accepts any liability=20 > whatsoever for=20 > > any defects of any kind either in or arising from this E-mail=20 > > transmission. E-Mail transmission cannot be guaranteed to=20 > be secure or=20 > > error-free, as messages can be intercepted, lost, corrupted,=20 > > destroyed, contain viruses, or arrive late or incomplete. Eurobase=20 > > does not accept any responsibility for viruses and it is your=20 > > responsibility to scan any attachments. > >=20 > > Registered Address: Essex House, 2 County Place, Chelmsford, Essex=20 > > CM2 0RE, United Kingdom > >=20 > >=20 > > -------------------------------------------------------------- > > ----------- > > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > > SourceForge.net's Techsay panel and you'll get the chance to share=20 > > your opinions on IT & business topics through brief surveys -- and=20 > > earn cash=20 > > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > > &CID=3DDEVDEV > > _______________________________________________ > > Quickfixj-users mailing list > > Qui...@li... > > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > >=20 >=20 >=20 > -------------------------------------------------------------- > ---------- > - > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys -- and earn cash=20 > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > &CID=3DDEVDE > V > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys -- and earn cash=20 > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > &CID=3DDEVDEV > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users >=20 |
|
From: Alex M. <ale...@eu...> - 2006-09-20 13:49:34
|
Hi Steve, There are no exceptions in the system out - here is the output from another shutdown: [20/09/06 13:57:18 BST] Service stopping [20/09/06 13:57:18 BST] : ESPMessageManager: entering close [20/09/06 13:57:18 BST] Alex: : ESPConnector: entering disconnect [20/09/06 13:57:18 BST] Alex: : ESPConnector: entering sendLogout [20/09/06 13:57:18 BST] TwistManager: timeout closedown now running [20/09/06 13:57:18 BST] Alex: : ESPConnector: entering send - message = =3D 8=3DFIX.4.2=019=3D5=0135=3D5=0110=3D166=01 [20/09/06 13:57:18 BST] Alex: : ESPConnector: FIXHandler toAdmin - message type =3D 5 message =3D 8=3DFIX.4.2=019=3D65=0135=3D5=0134=3D299=0149=3Dscbbanku2fixmaker=0152=3D= 20060920-12:57:18.266 =0156=3DCNX=0110=3D017=01 [20/09/06 13:57:18 BST] Alex: : ESPConnector: waiting for connection status [20/09/06 13:57:18 BST] Alex: : ESPConnector: FIXHandler onLogout [20/09/06 13:57:18 BST] Alex: : ESPCOnnector: notifying connectionWaiter listeners [20/09/06 13:57:18 BST] Alex debug: entering setConnected [20/09/06 13:57:18 BST] Alex debug: setConnected - got lock [20/09/06 13:57:18 BST] Alex debug: setConnected - set connected to false [20/09/06 13:57:18 BST] Alex debug: exiting setConnected [20/09/06 13:57:18 BST] Alex: : ESPConnector: exiting disconnect [20/09/06 13:57:18 BST] Service stopped And the message log for the same time (the server is 1 hour behind): 8=3DFIX.4.2=019=3D65=0135=3D5=0134=3D299=0149=3Dscbbanku2fixmaker=0152=3D= 20060920-12:57:18.266 =0156=3DCNX=0110=3D017=01 8=3DFIX.4.2=019=3D62=0135=3D5=0149=3DCNX=0156=3Dscbbanku2fixmaker=0134=3D= 1739=0152=3D20060920-12:5 8:31=0110=3D110=01 And the seqnums file after shutdown: 300:1739 Are there any other diagnostics that could shed more light on this? Thanks, Alex -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Steve Bate Sent: 20 September 2006 14:30 To: qui...@li... Subject: Re: [Quickfixj-users] Resend Request message QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ Hi Alex, Does the log indicate any validation errors or exceptions when processing the logout acknowledgement? For example, if there is an exception while verifying the logout ack, the fromAdmin callback will not be called although the=20 onLogout callback will be called during the subsequent=20 disconnect. Steve > -----Original Message----- > From: qui...@li...=20 > [mailto:qui...@li...] On=20 > Behalf Of Alex McGlashan > Sent: Wednesday, September 20, 2006 2:00 PM > To: qui...@li... > Subject: Re: [Quickfixj-users] Resend Request message >=20 > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ Hi Toby, >=20 > Thanks for the info and links - very helpful. >=20 > I now know why the sequence numbers are getting out of sync. =20 > What is happening is that when I initiate a logout, I wait=20 > for my onLogout callback method to be called and then shut=20 > down my adaptor. The message log indicates that I do indeed=20 > receive a logout response message: >=20 > = 8=3DFIX.4.2=019=3D65=0135=3D5=0134=3D189=0149=3Dscbbanku2fixmaker=0152=3D= 20060920-11 > :40:39.501 > =0156=3DCNX=0110=3D001=01 > = 8=3DFIX.4.2=019=3D62=0135=3D5=0149=3DCNX=0156=3Dscbbanku2fixmaker=0134=3D= 1481=0152=3D200 > 60920-11:4 > 1:52=0110=3D098=01 >=20 > However, the sequence number for the incoming message stream is not > incremented: >=20 > 190:1481 >=20 > I notice, also, that my fromAdmin method is not called with=20 > the incoming logout message. >=20 > How do I ensure that my seqnums file is incremented correctly? >=20 > Thanks in advance, >=20 > Alex >=20 >=20 >=20 > -----Original Message----- > From: qui...@li... > [mailto:qui...@li...] On=20 > Behalf Of Shepheard, Toby (London) > Sent: 15 September 2006 16:34 > To: qui...@li... > Subject: Re: [Quickfixj-users] Resend Request message >=20 > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ You=20 > have some control over what QuickFIX will do, but it does=20 > depend on you to configure it appropriately. See=20 > http://www.quickfixj.org/quickfixj/usermanual/usage/configurat > ion.html#M > iscellaneous - in particular it sounds like you need to be=20 > setting SendResetSeqNumFlag=3DY. If the counterparty expects=20 > you to start at 0 for each session and you're continuing with=20 > the last session's seqNum, then that will be causing=20 > problems. Setting this flag to Y will make QFJ automatically=20 > reset to 0 when it initiates a login. >=20 > As mentioned before, without seeing logs and your config I'm=20 > playing a bit of a guessing game; if you continue to have=20 > problems then it would really help to see these. >=20 >=20 > I also recommend reading the FIX spec on session management,=20 > available from=20 > http://www.fixprotocol.org/documents/347/fix-44_w_Errata_20030618.zip > (you may need to login first). I think it's the 2nd document=20 > that covers session behaviour, sequence number usage etc. >=20 >=20 >=20 > -----Original Message----- > From: qui...@li... > [mailto:qui...@li...] On=20 > Behalf Of Alex McGlashan > Sent: 15 September 2006 15:16 > To: qui...@li... > Subject: Re: [Quickfixj-users] Resend Request message >=20 >=20 > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ Thanks=20 > Toby, I think you're correct about the first sequence number=20 > being out. What seems to be happening is that the=20 > counterparty is sending me a ResendRequest message in the=20 > expectation that my seqnums file will be updated to match the=20 > NewSeqNo value. My question now is: > should QuickFIX update the seqnums file automatically or is=20 > this functionality I need to code for. If the former, it=20 > doesn't seem to be working, if the latter, how? >=20 > Regards, >=20 > Alex >=20 >=20 > -----Original Message----- > From: qui...@li... > [mailto:qui...@li...] On=20 > Behalf Of Shepheard, Toby (London) > Sent: 14 September 2006 09:19 > To: qui...@li... > Subject: Re: [Quickfixj-users] Resend Request message >=20 > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ 1. Is=20 > it sending the ResendRequest near the start of the session?=20 > If so, it may be that although the messages are in sequence,=20 > the first sequence number received is not as expected. There=20 > are various config settings for resetting the sequence=20 > number, and you have to make sure you configure it to match=20 > what the counterparty is doing. The fact that deleting your=20 > seqnums file resolved the issue temporarily suggests that=20 > this might well be the problem. >=20 > 2. Strange, it should handle this ok. Is your message store=20 > working properly? I'm not very familiar with gap-fills I'm afraid. >=20 > I think some logs files and your config file may be needed to=20 > really work out what's going on - either that or someone=20 > else's expertise who knows more about it than I do :)=20 >=20 > Rgds > Toby >=20 >=20 > -----Original Message----- > From: qui...@li... > [mailto:qui...@li...] On=20 > Behalf Of Alex McGlashan > Sent: 13 September 2006 18:25 > To: qui...@li... > Subject: Re: [Quickfixj-users] Resend Request message >=20 >=20 > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/=20 > Unfortunately that was a temporary fix - I do have an issue=20 > with sequence numbers after all. >=20 > As described earlier, my QuickFIX is sending a ResendRequest=20 > and the counterparty is responding with a SequenceReset with=20 > GapFillFlag =3D Y, at which point my QuickFIX stops handling=20 > QuoteRequests. >=20 > My questions are: >=20 > 1. The logs indicate that the incoming messages are in sequence i.e. > there are no gaps, so why is QuickFIX is sending the=20 > ResendRequest in the first place? >=20 > 2. Why is QuickFIX not handling the gap fill message correctly? > Shouldn't it just carry on receiving messages? >=20 > I have lots of logs and diagnostics and am running out of=20 > ideas so any help would be very much appreciated. >=20 > Alex > -------------------------------------------------------- >=20 > If you are not an intended recipient of this e-mail, please=20 > notify the sender, delete it and do not read, act upon,=20 > print, disclose, copy, retain or redistribute it. Click here=20 > for important additional terms > relating to this e-mail. http://www.ml.com/email_terms/ > -------------------------------------------------------- >=20 > -------------------------------------------------------------- > ---------- > - > Using Tomcat but need to do more? Need to support web=20 > services, security? > Get stuff done quickly with pre-integrated technology to make=20 > your job easier Download IBM WebSphere Application Server=20 > v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057& > dat=3D121642 > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users >=20 > Eurobase International Limited and its subsidiaries=20 > (Eurobase) are unable to exercise control over the content of=20 > information in E-Mails. Any views and opinions expressed may=20 > be personal to the sender and are not necessarily those of=20 > Eurobase. Eurobase will not enter into any contractual=20 > obligations in respect of any part of its business in any E-mail.=20 >=20 > Privileged / confidential information may be contained in=20 > this message and /or any attachments. This E-mail is intended=20 > for the use of the addressee(s) only and may contain=20 > confidential information. If you are not the / an intended=20 > recipient, you are hereby notified that any use or=20 > dissemination of this communication is strictly prohibited. =20 > If you receive this transmission in error, please notify us=20 > immediately, and then delete this E-mail.=20 >=20 > Neither the sender nor Eurobase accepts any liability=20 > whatsoever for any defects of any kind either in or arising=20 > from this E-mail transmission. E-Mail transmission cannot be=20 > guaranteed to be secure or error-free, as messages can be=20 > intercepted, lost, corrupted, destroyed, contain viruses, or=20 > arrive late or incomplete. Eurobase does not accept any=20 > responsibility for viruses and it is your responsibility to=20 > scan any attachments. >=20 > Registered Address: Essex House, 2 County Place, Chelmsford,=20 > Essex CM2 0RE, United Kingdom >=20 >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys -- and earn cash=20 > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > &CID=3DDEVDEV > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users >=20 ------------------------------------------------------------------------ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDE V _______________________________________________ Quickfixj-users mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfixj-users |
|
From: Steve B. <st...@te...> - 2006-09-20 13:28:56
|
Hi Alex, Does the log indicate any validation errors or exceptions when processing the logout acknowledgement? For example, if there is an exception while verifying the logout ack, the fromAdmin callback will not be called although the=20 onLogout callback will be called during the subsequent=20 disconnect. Steve > -----Original Message----- > From: qui...@li...=20 > [mailto:qui...@li...] On=20 > Behalf Of Alex McGlashan > Sent: Wednesday, September 20, 2006 2:00 PM > To: qui...@li... > Subject: Re: [Quickfixj-users] Resend Request message >=20 > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ Hi Toby, >=20 > Thanks for the info and links - very helpful. >=20 > I now know why the sequence numbers are getting out of sync. =20 > What is happening is that when I initiate a logout, I wait=20 > for my onLogout callback method to be called and then shut=20 > down my adaptor. The message log indicates that I do indeed=20 > receive a logout response message: >=20 > = 8=3DFIX.4.2=019=3D65=0135=3D5=0134=3D189=0149=3Dscbbanku2fixmaker=0152=3D= 20060920-11 > :40:39.501 > =0156=3DCNX=0110=3D001=01 > = 8=3DFIX.4.2=019=3D62=0135=3D5=0149=3DCNX=0156=3Dscbbanku2fixmaker=0134=3D= 1481=0152=3D200 > 60920-11:4 > 1:52=0110=3D098=01 >=20 > However, the sequence number for the incoming message stream is not > incremented: >=20 > 190:1481 >=20 > I notice, also, that my fromAdmin method is not called with=20 > the incoming logout message. >=20 > How do I ensure that my seqnums file is incremented correctly? >=20 > Thanks in advance, >=20 > Alex >=20 >=20 >=20 > -----Original Message----- > From: qui...@li... > [mailto:qui...@li...] On=20 > Behalf Of Shepheard, Toby (London) > Sent: 15 September 2006 16:34 > To: qui...@li... > Subject: Re: [Quickfixj-users] Resend Request message >=20 > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ You=20 > have some control over what QuickFIX will do, but it does=20 > depend on you to configure it appropriately. See=20 > http://www.quickfixj.org/quickfixj/usermanual/usage/configurat > ion.html#M > iscellaneous - in particular it sounds like you need to be=20 > setting SendResetSeqNumFlag=3DY. If the counterparty expects=20 > you to start at 0 for each session and you're continuing with=20 > the last session's seqNum, then that will be causing=20 > problems. Setting this flag to Y will make QFJ automatically=20 > reset to 0 when it initiates a login. >=20 > As mentioned before, without seeing logs and your config I'm=20 > playing a bit of a guessing game; if you continue to have=20 > problems then it would really help to see these. >=20 >=20 > I also recommend reading the FIX spec on session management,=20 > available from=20 > http://www.fixprotocol.org/documents/347/fix-44_w_Errata_20030618.zip > (you may need to login first). I think it's the 2nd document=20 > that covers session behaviour, sequence number usage etc. >=20 >=20 >=20 > -----Original Message----- > From: qui...@li... > [mailto:qui...@li...] On=20 > Behalf Of Alex McGlashan > Sent: 15 September 2006 15:16 > To: qui...@li... > Subject: Re: [Quickfixj-users] Resend Request message >=20 >=20 > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ Thanks=20 > Toby, I think you're correct about the first sequence number=20 > being out. What seems to be happening is that the=20 > counterparty is sending me a ResendRequest message in the=20 > expectation that my seqnums file will be updated to match the=20 > NewSeqNo value. My question now is: > should QuickFIX update the seqnums file automatically or is=20 > this functionality I need to code for. If the former, it=20 > doesn't seem to be working, if the latter, how? >=20 > Regards, >=20 > Alex >=20 >=20 > -----Original Message----- > From: qui...@li... > [mailto:qui...@li...] On=20 > Behalf Of Shepheard, Toby (London) > Sent: 14 September 2006 09:19 > To: qui...@li... > Subject: Re: [Quickfixj-users] Resend Request message >=20 > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/ 1. Is=20 > it sending the ResendRequest near the start of the session?=20 > If so, it may be that although the messages are in sequence,=20 > the first sequence number received is not as expected. There=20 > are various config settings for resetting the sequence=20 > number, and you have to make sure you configure it to match=20 > what the counterparty is doing. The fact that deleting your=20 > seqnums file resolved the issue temporarily suggests that=20 > this might well be the problem. >=20 > 2. Strange, it should handle this ok. Is your message store=20 > working properly? I'm not very familiar with gap-fills I'm afraid. >=20 > I think some logs files and your config file may be needed to=20 > really work out what's going on - either that or someone=20 > else's expertise who knows more about it than I do :)=20 >=20 > Rgds > Toby >=20 >=20 > -----Original Message----- > From: qui...@li... > [mailto:qui...@li...] On=20 > Behalf Of Alex McGlashan > Sent: 13 September 2006 18:25 > To: qui...@li... > Subject: Re: [Quickfixj-users] Resend Request message >=20 >=20 > QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ > QuickFIX/J Support: http://www.quickfixj.org/support/=20 > Unfortunately that was a temporary fix - I do have an issue=20 > with sequence numbers after all. >=20 > As described earlier, my QuickFIX is sending a ResendRequest=20 > and the counterparty is responding with a SequenceReset with=20 > GapFillFlag =3D Y, at which point my QuickFIX stops handling=20 > QuoteRequests. >=20 > My questions are: >=20 > 1. The logs indicate that the incoming messages are in sequence i.e. > there are no gaps, so why is QuickFIX is sending the=20 > ResendRequest in the first place? >=20 > 2. Why is QuickFIX not handling the gap fill message correctly? > Shouldn't it just carry on receiving messages? >=20 > I have lots of logs and diagnostics and am running out of=20 > ideas so any help would be very much appreciated. >=20 > Alex > -------------------------------------------------------- >=20 > If you are not an intended recipient of this e-mail, please=20 > notify the sender, delete it and do not read, act upon,=20 > print, disclose, copy, retain or redistribute it. Click here=20 > for important additional terms > relating to this e-mail. http://www.ml.com/email_terms/ > -------------------------------------------------------- >=20 > -------------------------------------------------------------- > ---------- > - > Using Tomcat but need to do more? Need to support web=20 > services, security? > Get stuff done quickly with pre-integrated technology to make=20 > your job easier Download IBM WebSphere Application Server=20 > v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057& > dat=3D121642 > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users >=20 > Eurobase International Limited and its subsidiaries=20 > (Eurobase) are unable to exercise control over the content of=20 > information in E-Mails. Any views and opinions expressed may=20 > be personal to the sender and are not necessarily those of=20 > Eurobase. Eurobase will not enter into any contractual=20 > obligations in respect of any part of its business in any E-mail.=20 >=20 > Privileged / confidential information may be contained in=20 > this message and /or any attachments. This E-mail is intended=20 > for the use of the addressee(s) only and may contain=20 > confidential information. If you are not the / an intended=20 > recipient, you are hereby notified that any use or=20 > dissemination of this communication is strictly prohibited. =20 > If you receive this transmission in error, please notify us=20 > immediately, and then delete this E-mail.=20 >=20 > Neither the sender nor Eurobase accepts any liability=20 > whatsoever for any defects of any kind either in or arising=20 > from this E-mail transmission. E-Mail transmission cannot be=20 > guaranteed to be secure or error-free, as messages can be=20 > intercepted, lost, corrupted, destroyed, contain viruses, or=20 > arrive late or incomplete. Eurobase does not accept any=20 > responsibility for viruses and it is your responsibility to=20 > scan any attachments. >=20 > Registered Address: Essex House, 2 County Place, Chelmsford,=20 > Essex CM2 0RE, United Kingdom >=20 >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys -- and earn cash=20 > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge > &CID=3DDEVDEV > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfixj-users >=20 |
|
From: Alex M. <ale...@eu...> - 2006-09-20 12:01:14
|
Hi Toby, Thanks for the info and links - very helpful. I now know why the sequence numbers are getting out of sync. What is happening is that when I initiate a logout, I wait for my onLogout callback method to be called and then shut down my adaptor. The message log indicates that I do indeed receive a logout response message: 8=3DFIX.4.2=019=3D65=0135=3D5=0134=3D189=0149=3Dscbbanku2fixmaker=0152=3D= 20060920-11:40:39.501 =0156=3DCNX=0110=3D001=01 8=3DFIX.4.2=019=3D62=0135=3D5=0149=3DCNX=0156=3Dscbbanku2fixmaker=0134=3D= 1481=0152=3D20060920-11:4 1:52=0110=3D098=01 However, the sequence number for the incoming message stream is not incremented: 190:1481 I notice, also, that my fromAdmin method is not called with the incoming logout message. How do I ensure that my seqnums file is incremented correctly? Thanks in advance, Alex -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Shepheard, Toby (London) Sent: 15 September 2006 16:34 To: qui...@li... Subject: Re: [Quickfixj-users] Resend Request message QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ You have some control over what QuickFIX will do, but it does depend on you to configure it appropriately. See http://www.quickfixj.org/quickfixj/usermanual/usage/configuration.html#M iscellaneous - in particular it sounds like you need to be setting SendResetSeqNumFlag=3DY. If the counterparty expects you to start at 0 = for each session and you're continuing with the last session's seqNum, then that will be causing problems. Setting this flag to Y will make QFJ automatically reset to 0 when it initiates a login. As mentioned before, without seeing logs and your config I'm playing a bit of a guessing game; if you continue to have problems then it would really help to see these. I also recommend reading the FIX spec on session management, available from http://www.fixprotocol.org/documents/347/fix-44_w_Errata_20030618.zip (you may need to login first). I think it's the 2nd document that covers session behaviour, sequence number usage etc. -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Alex McGlashan Sent: 15 September 2006 15:16 To: qui...@li... Subject: Re: [Quickfixj-users] Resend Request message QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ Thanks Toby, I think you're correct about the first sequence number being out. What seems to be happening is that the counterparty is sending me a ResendRequest message in the expectation that my seqnums file will be updated to match the NewSeqNo value. My question now is: should QuickFIX update the seqnums file automatically or is this functionality I need to code for. If the former, it doesn't seem to be working, if the latter, how? Regards, Alex -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Shepheard, Toby (London) Sent: 14 September 2006 09:19 To: qui...@li... Subject: Re: [Quickfixj-users] Resend Request message QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ 1. Is it sending the ResendRequest near the start of the session? If so, it may be that although the messages are in sequence, the first sequence number received is not as expected. There are various config settings for resetting the sequence number, and you have to make sure you configure it to match what the counterparty is doing. The fact that deleting your seqnums file resolved the issue temporarily suggests that this might well be the problem. 2. Strange, it should handle this ok. Is your message store working properly? I'm not very familiar with gap-fills I'm afraid. I think some logs files and your config file may be needed to really work out what's going on - either that or someone else's expertise who knows more about it than I do :)=20 Rgds Toby -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Alex McGlashan Sent: 13 September 2006 18:25 To: qui...@li... Subject: Re: [Quickfixj-users] Resend Request message QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ Unfortunately that was a temporary fix - I do have an issue with sequence numbers after all. As described earlier, my QuickFIX is sending a ResendRequest and the counterparty is responding with a SequenceReset with GapFillFlag =3D Y, = at which point my QuickFIX stops handling QuoteRequests. My questions are: 1. The logs indicate that the incoming messages are in sequence i.e. there are no gaps, so why is QuickFIX is sending the ResendRequest in the first place? 2. Why is QuickFIX not handling the gap fill message correctly? Shouldn't it just carry on receiving messages? I have lots of logs and diagnostics and am running out of ideas so any help would be very much appreciated. Alex -------------------------------------------------------- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ -------------------------------------------------------- ------------------------------------------------------------------------ - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 _______________________________________________ Quickfixj-users mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfixj-users Eurobase International Limited and its subsidiaries (Eurobase) are = unable to exercise control over the content of information in E-Mails. = Any views and opinions expressed may be personal to the sender and are = not necessarily those of Eurobase. Eurobase will not enter into any = contractual obligations in respect of any part of its business in any = E-mail.=20 Privileged / confidential information may be contained in this message = and /or any attachments. This E-mail is intended for the use of the = addressee(s) only and may contain confidential information. If you are = not the / an intended recipient, you are hereby notified that any use or = dissemination of this communication is strictly prohibited. If you = receive this transmission in error, please notify us immediately, and = then delete this E-mail.=20 Neither the sender nor Eurobase accepts any liability whatsoever for any = defects of any kind either in or arising from this E-mail transmission. = E-Mail transmission cannot be guaranteed to be secure or error-free, as = messages can be intercepted, lost, corrupted, destroyed, contain = viruses, or arrive late or incomplete. Eurobase does not accept any = responsibility for viruses and it is your responsibility to scan any = attachments. Registered Address: Essex House, 2 County Place, Chelmsford, Essex CM2 = 0RE, United Kingdom |
|
From: Shepheard, T. \(London\) <Tob...@ml...> - 2006-09-15 15:34:40
|
You have some control over what QuickFIX will do, but it does depend on you to configure it appropriately. See http://www.quickfixj.org/quickfixj/usermanual/usage/configuration.html#M iscellaneous - in particular it sounds like you need to be setting SendResetSeqNumFlag=3DY. If the counterparty expects you to start at 0 = for each session and you're continuing with the last session's seqNum, then that will be causing problems. Setting this flag to Y will make QFJ automatically reset to 0 when it initiates a login. As mentioned before, without seeing logs and your config I'm playing a bit of a guessing game; if you continue to have problems then it would really help to see these. I also recommend reading the FIX spec on session management, available from http://www.fixprotocol.org/documents/347/fix-44_w_Errata_20030618.zip (you may need to login first). I think it's the 2nd document that covers session behaviour, sequence number usage etc. -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Alex McGlashan Sent: 15 September 2006 15:16 To: qui...@li... Subject: Re: [Quickfixj-users] Resend Request message QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ Thanks Toby, I think you're correct about the first sequence number being out. What seems to be happening is that the counterparty is sending me a ResendRequest message in the expectation that my seqnums file will be updated to match the NewSeqNo value. My question now is: should QuickFIX update the seqnums file automatically or is this functionality I need to code for. If the former, it doesn't seem to be working, if the latter, how? Regards, Alex -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Shepheard, Toby (London) Sent: 14 September 2006 09:19 To: qui...@li... Subject: Re: [Quickfixj-users] Resend Request message QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ 1. Is it sending the ResendRequest near the start of the session? If so, it may be that although the messages are in sequence, the first sequence number received is not as expected. There are various config settings for resetting the sequence number, and you have to make sure you configure it to match what the counterparty is doing. The fact that deleting your seqnums file resolved the issue temporarily suggests that this might well be the problem. 2. Strange, it should handle this ok. Is your message store working properly? I'm not very familiar with gap-fills I'm afraid. I think some logs files and your config file may be needed to really work out what's going on - either that or someone else's expertise who knows more about it than I do :)=20 Rgds Toby -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Alex McGlashan Sent: 13 September 2006 18:25 To: qui...@li... Subject: Re: [Quickfixj-users] Resend Request message QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ Unfortunately that was a temporary fix - I do have an issue with sequence numbers after all. As described earlier, my QuickFIX is sending a ResendRequest and the counterparty is responding with a SequenceReset with GapFillFlag =3D Y, = at which point my QuickFIX stops handling QuoteRequests. My questions are: 1. The logs indicate that the incoming messages are in sequence i.e. there are no gaps, so why is QuickFIX is sending the ResendRequest in the first place? 2. Why is QuickFIX not handling the gap fill message correctly? Shouldn't it just carry on receiving messages? I have lots of logs and diagnostics and am running out of ideas so any help would be very much appreciated. Alex -------------------------------------------------------- If you are not an intended recipient of this e-mail, please notify the = sender, delete it and do not read, act upon, print, disclose, copy, = retain or redistribute it. Click here for important additional terms = relating to this e-mail. http://www.ml.com/email_terms/ -------------------------------------------------------- |
|
From: Alex M. <ale...@eu...> - 2006-09-15 14:17:25
|
Thanks Toby, I think you're correct about the first sequence number being out. What seems to be happening is that the counterparty is sending me a ResendRequest message in the expectation that my seqnums file will be updated to match the NewSeqNo value. My question now is: should QuickFIX update the seqnums file automatically or is this functionality I need to code for. If the former, it doesn't seem to be working, if the latter, how? Regards, Alex -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Shepheard, Toby (London) Sent: 14 September 2006 09:19 To: qui...@li... Subject: Re: [Quickfixj-users] Resend Request message QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ 1. Is it sending the ResendRequest near the start of the session? If so, it may be that although the messages are in sequence, the first sequence number received is not as expected. There are various config settings for resetting the sequence number, and you have to make sure you configure it to match what the counterparty is doing. The fact that deleting your seqnums file resolved the issue temporarily suggests that this might well be the problem. 2. Strange, it should handle this ok. Is your message store working properly? I'm not very familiar with gap-fills I'm afraid. I think some logs files and your config file may be needed to really work out what's going on - either that or someone else's expertise who knows more about it than I do :)=20 Rgds Toby -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Alex McGlashan Sent: 13 September 2006 18:25 To: qui...@li... Subject: Re: [Quickfixj-users] Resend Request message QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ Unfortunately that was a temporary fix - I do have an issue with sequence numbers after all. As described earlier, my QuickFIX is sending a ResendRequest and the counterparty is responding with a SequenceReset with GapFillFlag =3D Y, = at which point my QuickFIX stops handling QuoteRequests. My questions are: 1. The logs indicate that the incoming messages are in sequence i.e. there are no gaps, so why is QuickFIX is sending the ResendRequest in the first place? 2. Why is QuickFIX not handling the gap fill message correctly? Shouldn't it just carry on receiving messages? I have lots of logs and diagnostics and am running out of ideas so any help would be very much appreciated. Alex -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Alex McGlashan Sent: 13 September 2006 10:33 To: qui...@li... Subject: Re: [Quickfixj-users] Resend Request message QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ This turned out to be a sequence number problem. For future reference I resolved it by deleting the .seqnums file which reset the sequence numbers. Apologies for any time spent on this. Alex -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Alex McGlashan Sent: 12 September 2006 14:10 To: qui...@li... Subject: Re: [Quickfixj-users] Resend Request message QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ Thanks Toby - that makes sense. I think the underlying problem is that my QuickFIX is not recognising the incoming Trading Session Status message anymore (it used to) but I can see it in the messages.log and it looks ok. Any ideas how I can diagnose this further? -------------------------------------------------------- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ -------------------------------------------------------- ------------------------------------------------------------------------ - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 _______________________________________________ Quickfixj-users mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfixj-users Eurobase International Limited and its subsidiaries (Eurobase) are = unable to exercise control over the content of information in E-Mails. = Any views and opinions expressed may be personal to the sender and are = not necessarily those of Eurobase. Eurobase will not enter into any = contractual obligations in respect of any part of its business in any = E-mail.=20 Privileged / confidential information may be contained in this message = and /or any attachments. This E-mail is intended for the use of the = addressee(s) only and may contain confidential information. If you are = not the / an intended recipient, you are hereby notified that any use or = dissemination of this communication is strictly prohibited. If you = receive this transmission in error, please notify us immediately, and = then delete this E-mail.=20 Neither the sender nor Eurobase accepts any liability whatsoever for any = defects of any kind either in or arising from this E-mail transmission. = E-Mail transmission cannot be guaranteed to be secure or error-free, as = messages can be intercepted, lost, corrupted, destroyed, contain = viruses, or arrive late or incomplete. Eurobase does not accept any = responsibility for viruses and it is your responsibility to scan any = attachments. Registered Address: Essex House, 2 County Place, Chelmsford, Essex CM2 = 0RE, United Kingdom |
|
From: Alex M. <ale...@eu...> - 2006-09-14 10:13:15
|
Hi, =20 I'm suddenly getting an "error during session initialization" message for no apparent reason. I was connecting ok and have made no changes to my code. Any ideas?? =20 Thanks, =20 Alex Eurobase International Limited and its subsidiaries (Eurobase) are = unable to exercise control over the content of information in E-Mails. = Any views and opinions expressed may be personal to the sender and are = not necessarily those of Eurobase. Eurobase will not enter into any = contractual obligations in respect of any part of its business in any = E-mail.=20 Privileged / confidential information may be contained in this message = and /or any attachments. This E-mail is intended for the use of the = addressee(s) only and may contain confidential information. If you are = not the / an intended recipient, you are hereby notified that any use or = dissemination of this communication is strictly prohibited. If you = receive this transmission in error, please notify us immediately, and = then delete this E-mail.=20 Neither the sender nor Eurobase accepts any liability whatsoever for any = defects of any kind either in or arising from this E-mail transmission. = E-Mail transmission cannot be guaranteed to be secure or error-free, as = messages can be intercepted, lost, corrupted, destroyed, contain = viruses, or arrive late or incomplete. Eurobase does not accept any = responsibility for viruses and it is your responsibility to scan any = attachments. Registered Address: Essex House, 2 County Place, Chelmsford, Essex CM2 = 0RE, United Kingdom |
|
From: Shepheard, T. \(London\) <Tob...@ml...> - 2006-09-14 08:19:02
|
1. Is it sending the ResendRequest near the start of the session? If so, it may be that although the messages are in sequence, the first sequence number received is not as expected. There are various config settings for resetting the sequence number, and you have to make sure you configure it to match what the counterparty is doing. The fact that deleting your seqnums file resolved the issue temporarily suggests that this might well be the problem. 2. Strange, it should handle this ok. Is your message store working properly? I'm not very familiar with gap-fills I'm afraid. I think some logs files and your config file may be needed to really work out what's going on - either that or someone else's expertise who knows more about it than I do :)=20 Rgds Toby -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Alex McGlashan Sent: 13 September 2006 18:25 To: qui...@li... Subject: Re: [Quickfixj-users] Resend Request message QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ Unfortunately that was a temporary fix - I do have an issue with sequence numbers after all. As described earlier, my QuickFIX is sending a ResendRequest and the counterparty is responding with a SequenceReset with GapFillFlag =3D Y, = at which point my QuickFIX stops handling QuoteRequests. My questions are: 1. The logs indicate that the incoming messages are in sequence i.e. there are no gaps, so why is QuickFIX is sending the ResendRequest in the first place? 2. Why is QuickFIX not handling the gap fill message correctly? Shouldn't it just carry on receiving messages? I have lots of logs and diagnostics and am running out of ideas so any help would be very much appreciated. Alex -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Alex McGlashan Sent: 13 September 2006 10:33 To: qui...@li... Subject: Re: [Quickfixj-users] Resend Request message QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ This turned out to be a sequence number problem. For future reference I resolved it by deleting the .seqnums file which reset the sequence numbers. Apologies for any time spent on this. Alex -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Alex McGlashan Sent: 12 September 2006 14:10 To: qui...@li... Subject: Re: [Quickfixj-users] Resend Request message QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ Thanks Toby - that makes sense. I think the underlying problem is that my QuickFIX is not recognising the incoming Trading Session Status message anymore (it used to) but I can see it in the messages.log and it looks ok. Any ideas how I can diagnose this further? -------------------------------------------------------- If you are not an intended recipient of this e-mail, please notify the = sender, delete it and do not read, act upon, print, disclose, copy, = retain or redistribute it. Click here for important additional terms = relating to this e-mail. http://www.ml.com/email_terms/ -------------------------------------------------------- |
103 messages has been excluded from this view by a project administrator.
