quickfix-developers Mailing List for QuickFIX (Page 78)
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-developers — QuickFIX developers forum
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
(5) |
Mar
(16) |
Apr
(15) |
May
(17) |
Jun
(33) |
Jul
(35) |
Aug
(34) |
Sep
(19) |
Oct
(40) |
Nov
(51) |
Dec
(43) |
| 2003 |
Jan
(45) |
Feb
(79) |
Mar
(124) |
Apr
(121) |
May
(132) |
Jun
(77) |
Jul
(110) |
Aug
(57) |
Sep
(48) |
Oct
(83) |
Nov
(60) |
Dec
(40) |
| 2004 |
Jan
(67) |
Feb
(72) |
Mar
(74) |
Apr
(87) |
May
(70) |
Jun
(96) |
Jul
(75) |
Aug
(147) |
Sep
(128) |
Oct
(83) |
Nov
(67) |
Dec
(42) |
| 2005 |
Jan
(110) |
Feb
(84) |
Mar
(68) |
Apr
(55) |
May
(51) |
Jun
(192) |
Jul
(111) |
Aug
(100) |
Sep
(79) |
Oct
(127) |
Nov
(73) |
Dec
(112) |
| 2006 |
Jan
(95) |
Feb
(120) |
Mar
(138) |
Apr
(127) |
May
(124) |
Jun
(97) |
Jul
(103) |
Aug
(88) |
Sep
(138) |
Oct
(91) |
Nov
(112) |
Dec
(57) |
| 2007 |
Jan
(55) |
Feb
(35) |
Mar
(56) |
Apr
(16) |
May
(20) |
Jun
(77) |
Jul
(43) |
Aug
(47) |
Sep
(29) |
Oct
(54) |
Nov
(39) |
Dec
(40) |
| 2008 |
Jan
(69) |
Feb
(79) |
Mar
(122) |
Apr
(106) |
May
(114) |
Jun
(76) |
Jul
(83) |
Aug
(71) |
Sep
(53) |
Oct
(75) |
Nov
(54) |
Dec
(43) |
| 2009 |
Jan
(32) |
Feb
(31) |
Mar
(64) |
Apr
(48) |
May
(38) |
Jun
(43) |
Jul
(35) |
Aug
(15) |
Sep
(52) |
Oct
(62) |
Nov
(62) |
Dec
(21) |
| 2010 |
Jan
(44) |
Feb
(10) |
Mar
(47) |
Apr
(22) |
May
(5) |
Jun
(54) |
Jul
(19) |
Aug
(54) |
Sep
(16) |
Oct
(15) |
Nov
(7) |
Dec
(8) |
| 2011 |
Jan
(18) |
Feb
(9) |
Mar
(5) |
Apr
(5) |
May
(41) |
Jun
(40) |
Jul
(29) |
Aug
(17) |
Sep
(12) |
Oct
(23) |
Nov
(22) |
Dec
(11) |
| 2012 |
Jan
(8) |
Feb
(24) |
Mar
(5) |
Apr
(5) |
May
(6) |
Jun
(5) |
Jul
(5) |
Aug
(5) |
Sep
(2) |
Oct
(9) |
Nov
(2) |
Dec
(18) |
| 2013 |
Jan
(25) |
Feb
(16) |
Mar
(8) |
Apr
(2) |
May
(16) |
Jun
(17) |
Jul
(2) |
Aug
(13) |
Sep
(3) |
Oct
(4) |
Nov
(1) |
Dec
|
| 2014 |
Jan
(2) |
Feb
|
Mar
(22) |
Apr
(9) |
May
(3) |
Jun
(1) |
Jul
(5) |
Aug
(11) |
Sep
(18) |
Oct
(4) |
Nov
(4) |
Dec
(3) |
| 2015 |
Jan
(2) |
Feb
|
Mar
|
Apr
(3) |
May
(4) |
Jun
(37) |
Jul
|
Aug
(4) |
Sep
(6) |
Oct
(1) |
Nov
(4) |
Dec
(2) |
| 2016 |
Jan
(9) |
Feb
(3) |
Mar
(7) |
Apr
(1) |
May
(8) |
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
(3) |
Nov
(16) |
Dec
|
| 2017 |
Jan
(1) |
Feb
(15) |
Mar
(2) |
Apr
(12) |
May
(4) |
Jun
(7) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
(23) |
Dec
(8) |
| 2018 |
Jan
(2) |
Feb
(4) |
Mar
(2) |
Apr
(8) |
May
(3) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(5) |
Nov
(3) |
Dec
|
| 2020 |
Jan
|
Feb
(4) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(12) |
Aug
(5) |
Sep
(3) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: J. M. <jul...@pr...> - 2008-06-30 14:09:14
|
I'm trying to extend the QuickFix engine so it can support the FIXML format.
I've think in two solution, directly edit the C++ classes and recompile the
libraries or inherited from them and redefine the methods. But when a start
reading the C++ code I found some strange things, like for example:
bool Session::sendToTarget( Message* message )
{ QF_STACK_TRY
try
{
Message __pin * pMessage = message;
return FIX::Session::sendToTarget( pMessage->unmanaged() );
}
catch ( FIX::SessionNotFound& ) { throw new SessionNotFound(); };
QF_STACK_CATCH
}
This might one of the methods I'll have to redefine, but I still don't get
it. It is calling itself recursively. How can the message be send in this
terms...??? I look up for the message class to see what does the unmanaged()
method do....
FIX::Message& unmanaged()
{ return * m_pUnmanaged; }
Just return an attribute... so... let see where is that attribute is set...
Message() : disposed( false )
{ QF_STACK_TRY
m_pUnmanaged = new FIX::Message();
m_header = new Header( this );
m_trailer = new Trailer( this );
QF_STACK_CATCH
}
This finish to confused me.... the method is call recursively allocating
memory for a new Message..... What!!!!!! Obviously I'm quite rusty with C++.
Please help!!!!
Greetings, Julian.
|
|
From: J. M. <jul...@pr...> - 2008-06-30 14:07:54
|
Have any of you upgrade QuickFIX to work with FIXML format. In that case, how did you did it? Thanks, Julian. |
|
From: Kbo K. <kbo...@gm...> - 2008-06-29 21:49:21
|
> There is not a setting for it currently, but you can go to Session.cpp > in the doTargetTooHigh method, and comment out this line: m_state.queue( > msgSeqNum, msg ); > > I believe that should do it. Thanks. I would like, however, to make sure I understand your point, since modifying the DLL is not my first choice - I do trust you guys... I looked at the description of the Sequence Reset Gap Fill message in fixionary.com, and it states (for all types of this message): "The sending application will initiate the Sequence Reset. The message in all situations specifies NewSeqNo to reset to as the value of the next sequence number to be expected by the message receipient immediately following the messages and/or sequence numbers being skipped." Are you saying that since the message in question explicitly specifies a Gap Fill mode (123=Y), then it must fit with the previously sent messages (those for which a resend was not requested), whether queued or not (since queuing is recommended but not mandatory)? This would suggest that in Gap-Fill mode, this message cannot be used to arbitrarily reset the sequence number by the counterparty (it would take 123=N to do that) - is that correct? Please understand I'm asking this in order to be able to report the problem to my counterparty in the form of a FIX protocol breach (otherwise I might be kicked down the stairs). Is there anywhere I can get an official quote that specifies this behavior? Thanks again, Kbo |
|
From: James D. <jc...@co...> - 2008-06-27 13:27:35
|
It might be interesting to know who is the counter party with this behavior. If it is a big enough player, like an exchange, it might be worth creating a setting. On Fri, Jun 27, 2008 at 8:23 AM, <or...@qu...> wrote: > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > There is not a setting for it currently, but you can go to Session.cpp > in the doTargetTooHigh method, and comment out this line: m_state.queue( > msgSeqNum, msg ); > > I believe that should do it. > > > -------- Original Message -------- > > Subject: Re: [Quickfix-developers] SequenceReset bug? > > From: Kbo Keplowsky <kbo...@gm...> > > Date: Fri, June 27, 2008 2:57 am > > To: qui...@li... > > > > > > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > > QuickFIX Support: http://www.quickfixengine.org/services.html > > > > I see what you mean, and I agree. However, I thought I'd attach the > relevant > > part of the log just to make sure I haven't made a mistake in my > description > > (should have done that from the start, I guess). > > > > In case I will have to adapt to the counterparty's behavior, is there any > > quick way to turn off queueing? > > > > Here goes: > > > > <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, outgoing> > > (8=FIX.4.4 9=105 35=A 34=192 49=ME 52=20080622-13:28:53.466 > > 56=CNTRPRTY 50=user 98=0 108=20 553=user 554=pass 10=071 ) > > <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, event> > > (Initiated logon request) > > <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, incoming> > > (8=FIX.4.4 9=82 35=A 34=508 49=CNTRPRTY 50=FixGateway 56=ME > > 52=20080622-13:32:01.445 98=0 108=20 10=072 ) > > <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, event> > > (Received logon response) > > <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, event> > > (MsgSeqNum too high, expecting 507 but received 508) > > <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, outgoing> > > (8=FIX.4.4 9=104 35=2 34=193 49=ME 52=20080622-13:28:53.716 > > 56=CNTRPRTY 7=507 16=0 50=user 553=user 554=pass 10=004 ) > > <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, event> > > (Sent ResendRequest FROM: 507 TO: 0) > > <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, incoming> > > (8=FIX.4.4 9=74 35=4 49=CNTRPRTY 56=ME 34=507 43=Y > > 52=20080622-13:32:01.710 123=Y 36=508 10=241 ) > > <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, event> > > (ResendRequest for messages FROM: 507 TO: 507 has been satisfied.) > > <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, event> > > (Received SequenceReset FROM: 507 TO: 508) > > <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, event> > > (Processing QUEUED message: 508) > > <20080622-13:29:13, FIX.4.4:ME->CNTRPRTY:0, outgoing> > > (8=FIX.4.4 9=93 35=0 34=194 49=ME 52=20080622-13:29:13.248 > > 56=CNTRPRTY 50=user 553=user 554=pass 10=241 ) > > <20080622-13:29:13, FIX.4.4:ME->CNTRPRTY:0, incoming> > > (8=FIX.4.4 9=70 35=0 34=508 49=CNTRPRTY 50=FixGateway 56=ME > > 52=20080622-13:32:21.710 10=025 ) > > <20080622-13:29:13, FIX.4.4:ME->CNTRPRTY:0, outgoing> > > (8=FIX.4.4 9=146 35=5 34=195 49=ME 52=20080622-13:29:13.951 > > 56=CNTRPRTY 50=user 58=MsgSeqNum too low, expecting 509 but received > > 508 553=user 554=pass 10=150 ) > > <20080622-13:29:13, FIX.4.4:ME->CNTRPRTY:0, event> > > (MsgSeqNum too low, expecting 509 but received 508) > > <20080622-13:29:13, FIX.4.4:ME->CNTRPRTY:0, event> > > (Disconnecting) > > > > Thanks, > > > > Kbo > > > > > > ------------------------------------------------------------------------- > > Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services for > > just about anything Open Source. > > http://sourceforge.net/services/buy/index.php > > _______________________________________________ > > Quickfix-developers mailing list > > Qui...@li... > > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
|
From: <or...@qu...> - 2008-06-27 13:23:46
|
There is not a setting for it currently, but you can go to Session.cpp in the doTargetTooHigh method, and comment out this line: m_state.queue( msgSeqNum, msg ); I believe that should do it. > -------- Original Message -------- > Subject: Re: [Quickfix-developers] SequenceReset bug? > From: Kbo Keplowsky <kbo...@gm...> > Date: Fri, June 27, 2008 2:57 am > To: qui...@li... > > > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > I see what you mean, and I agree. However, I thought I'd attach the relevant > part of the log just to make sure I haven't made a mistake in my description > (should have done that from the start, I guess). > > In case I will have to adapt to the counterparty's behavior, is there any > quick way to turn off queueing? > > Here goes: > > <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, outgoing> > (8=FIX.4.4 9=105 35=A 34=192 49=ME 52=20080622-13:28:53.466 > 56=CNTRPRTY 50=user 98=0 108=20 553=user 554=pass 10=071 ) > <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, event> > (Initiated logon request) > <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, incoming> > (8=FIX.4.4 9=82 35=A 34=508 49=CNTRPRTY 50=FixGateway 56=ME > 52=20080622-13:32:01.445 98=0 108=20 10=072 ) > <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, event> > (Received logon response) > <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, event> > (MsgSeqNum too high, expecting 507 but received 508) > <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, outgoing> > (8=FIX.4.4 9=104 35=2 34=193 49=ME 52=20080622-13:28:53.716 > 56=CNTRPRTY 7=507 16=0 50=user 553=user 554=pass 10=004 ) > <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, event> > (Sent ResendRequest FROM: 507 TO: 0) > <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, incoming> > (8=FIX.4.4 9=74 35=4 49=CNTRPRTY 56=ME 34=507 43=Y > 52=20080622-13:32:01.710 123=Y 36=508 10=241 ) > <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, event> > (ResendRequest for messages FROM: 507 TO: 507 has been satisfied.) > <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, event> > (Received SequenceReset FROM: 507 TO: 508) > <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, event> > (Processing QUEUED message: 508) > <20080622-13:29:13, FIX.4.4:ME->CNTRPRTY:0, outgoing> > (8=FIX.4.4 9=93 35=0 34=194 49=ME 52=20080622-13:29:13.248 > 56=CNTRPRTY 50=user 553=user 554=pass 10=241 ) > <20080622-13:29:13, FIX.4.4:ME->CNTRPRTY:0, incoming> > (8=FIX.4.4 9=70 35=0 34=508 49=CNTRPRTY 50=FixGateway 56=ME > 52=20080622-13:32:21.710 10=025 ) > <20080622-13:29:13, FIX.4.4:ME->CNTRPRTY:0, outgoing> > (8=FIX.4.4 9=146 35=5 34=195 49=ME 52=20080622-13:29:13.951 > 56=CNTRPRTY 50=user 58=MsgSeqNum too low, expecting 509 but received > 508 553=user 554=pass 10=150 ) > <20080622-13:29:13, FIX.4.4:ME->CNTRPRTY:0, event> > (MsgSeqNum too low, expecting 509 but received 508) > <20080622-13:29:13, FIX.4.4:ME->CNTRPRTY:0, event> > (Disconnecting) > > Thanks, > > Kbo > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Kbo K. <kbo...@gm...> - 2008-06-27 07:57:43
|
I see what you mean, and I agree. However, I thought I'd attach the relevant part of the log just to make sure I haven't made a mistake in my description (should have done that from the start, I guess). In case I will have to adapt to the counterparty's behavior, is there any quick way to turn off queueing? Here goes: <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, outgoing> (8=FIX.4.4 9=105 35=A 34=192 49=ME 52=20080622-13:28:53.466 56=CNTRPRTY 50=user 98=0 108=20 553=user 554=pass 10=071 ) <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, event> (Initiated logon request) <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, incoming> (8=FIX.4.4 9=82 35=A 34=508 49=CNTRPRTY 50=FixGateway 56=ME 52=20080622-13:32:01.445 98=0 108=20 10=072 ) <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, event> (Received logon response) <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, event> (MsgSeqNum too high, expecting 507 but received 508) <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, outgoing> (8=FIX.4.4 9=104 35=2 34=193 49=ME 52=20080622-13:28:53.716 56=CNTRPRTY 7=507 16=0 50=user 553=user 554=pass 10=004 ) <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, event> (Sent ResendRequest FROM: 507 TO: 0) <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, incoming> (8=FIX.4.4 9=74 35=4 49=CNTRPRTY 56=ME 34=507 43=Y 52=20080622-13:32:01.710 123=Y 36=508 10=241 ) <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, event> (ResendRequest for messages FROM: 507 TO: 507 has been satisfied.) <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, event> (Received SequenceReset FROM: 507 TO: 508) <20080622-13:28:53, FIX.4.4:ME->CNTRPRTY:0, event> (Processing QUEUED message: 508) <20080622-13:29:13, FIX.4.4:ME->CNTRPRTY:0, outgoing> (8=FIX.4.4 9=93 35=0 34=194 49=ME 52=20080622-13:29:13.248 56=CNTRPRTY 50=user 553=user 554=pass 10=241 ) <20080622-13:29:13, FIX.4.4:ME->CNTRPRTY:0, incoming> (8=FIX.4.4 9=70 35=0 34=508 49=CNTRPRTY 50=FixGateway 56=ME 52=20080622-13:32:21.710 10=025 ) <20080622-13:29:13, FIX.4.4:ME->CNTRPRTY:0, outgoing> (8=FIX.4.4 9=146 35=5 34=195 49=ME 52=20080622-13:29:13.951 56=CNTRPRTY 50=user 58=MsgSeqNum too low, expecting 509 but received 508 553=user 554=pass 10=150 ) <20080622-13:29:13, FIX.4.4:ME->CNTRPRTY:0, event> (MsgSeqNum too low, expecting 509 but received 508) <20080622-13:29:13, FIX.4.4:ME->CNTRPRTY:0, event> (Disconnecting) Thanks, Kbo |
|
From: Jonathan A. <ja...@aa...> - 2008-06-26 18:37:39
|
Well that's certainly a stupid limitation on C#'s part. And since "just use VB" probably isn't the answer you are looking for, I'm behind you on this one. Looking through the object model, it looks like there are a lot of other places where making that change would also be beneficial. For example, it looks like all the field enumerations use that instead of constants. Jonathan Louis Allen Software Developer D: 858.547.7731 C: 619.933.8527 Advisors Asset Management 7220 Trade Street Suite 310 San Diego, CA 92121 www.aam.us.com ________________________________ From: qui...@li... [mailto:qui...@li...] On Behalf Of Brian Erst Sent: Thursday, June 26, 2008 9:32 AM To: qui...@li... Subject: [Quickfix-developers] Non-const constants Is there are a reason that constant strings in the .Net library are not "const"? For instance, the MsgType class defines a whole series of static string "constants" for all the known FIX message types (beginning with ALLOCATION and ending with XML_MESSAGE). Unfortunately, they are defined as "public static string" rather than "public const string". This may seem like a trivial difference, but it means that these values can't be used as part of a switch() statement. switch (msgType.getValue()) { case MsgType.HEARTBEAT: // Doesn't work - not a constant value } So, I end up making parallel classes that simply redefine the values in a "const" manner. public class MsgTypeConstants { public const string HEARTBEAT = "0"; ... } switch (msgType.getValue()) { case MsgTypeConstants.HEARTBEAT: // This works } Is there a reason for "static" instead of "const"? - Brian Erst Thynk Software, Inc. Advisors Asset Management, Inc. (AAM) is a FINRA/ SIPC member and SEC Registered Investment Advisor. INFORMATION REGARDING SECURITIES IS FOR BROKER/DEALER AND REGISTERED ADVISOR USE ONLY - NOT FOR USE WITH THE PUBLIC If the reader of this message is not the intended recipient, you are notified that any disclosure, distribution or copying is prohibited. Please see http://www.aam.us.com/FISBonds/PublicSite/EmailDisclosures.aspx for additional disclosures. |
|
From: Brian E. <azz...@ya...> - 2008-06-26 16:32:05
|
Is there are a reason that constant strings in the .Net library are not "const"?
For instance, the MsgType class defines a whole series of static string "constants" for all the known FIX message types (beginning with ALLOCATION and ending with XML_MESSAGE). Unfortunately, they are defined as "public static string" rather than "public const string".
This may seem like a trivial difference, but it means that these values can't be used as part of a switch() statement.
switch (msgType.getValue())
{
case MsgType.HEARTBEAT: // Doesn't work - not a constant value
}
So, I end up making parallel classes that simply redefine the values in a "const" manner.
public class MsgTypeConstants
{
public const string HEARTBEAT = "0";
...
}
switch (msgType.getValue())
{
case MsgTypeConstants.HEARTBEAT: // This works
}
Is there a reason for "static" instead of "const"?
- Brian Erst
Thynk Software, Inc.
|
|
From: <or...@qu...> - 2008-06-26 14:53:58
|
Do you have any logs of the messages you are processing? Did this not happen when you ran single threaded? --oren > -------- Original Message -------- > Subject: RE: [Quickfix-developers] Core after converting to > multithreadedapplication > From: "Mangalore, Channabasava" > <cha...@cr...> > Date: Thu, June 26, 2008 2:31 am > To: or...@qu... > Cc: qui...@li... > Hi Oren, > Even After updating to the quickfix 1.12.4 I am seeing the crash at the > same level, > Attached is there stack trace for your reference > (dbx) where > current thread: t@13 > =>[1] t_delete(0x60a5e0, 0xfdabc008, 0xfdac27cc, 0xfdac284c, 0xfdac2848, > 0x0), at 0xfda427f0 > [2] _malloc_unlocked(0x2b, 0x60a5e0, 0xfdabc008, 0x30, 0x60a5e0, 0x0), > at 0xfda41e80 > [3] malloc(0x2b, 0xfdac27cc, 0x1, 0x0, 0x46c5, 0x920f4), at 0xfda41cd8 > [4] malloc(0xfda41cb8, 0xfda41cb8, 0xfdc63d20, 0x2b, 0xc14, 0xc00), at > 0xfdbd1c68 > [5] operator new(0x2b, 0x0, 0x328ac, 0xfdc306a0, 0x1400, 0xfdc63d20), > at 0xfdc314a0 > [6] std::basic_string<char,std::char_traits<char>,std::allocator<char> > >::__getRep(0x1400, 0x1, 0x1, 0x0, 0x10c, 0x3b650), at 0xfdc29c4c > [7] std::basic_string<char,std::char_traits<char>,std::allocator<char> > >::basic_string(0xf67ff110, 0xf67ff11e, 0x1, 0xf67ff10f, 0x45a900, > 0x3e9be8), at 0xfdc287c0 > [8] FIX::FieldMap::addGroup(0x609b10, 0xc, 0x609b48, 0x0, 0x1, > 0x609cd0), at 0xfe342824 > [9] FIX::FieldMap::operator=(0x609b10, 0xf67ff9f4, 0x3e6730, 0x609b14, > 0x5a3fe0, 0x529220), at 0xfe3425dc > [10] HSFXMessageData::HSFXMessageData(0x5edd78, 0xf67ff9f4, > 0xf67ff38c, 0x609b48, 0x609b14, 0x5edd84), at 0x365ac > [11] HSFXListener::pushIntoIQueue(0x2b1ee8, 0xf67ff9f4, 0x1, > 0xf67ff38c, 0xf67ff38f, 0x5edd78), at 0x410d8 > [12] HSFXService::fromApp(0x64d8af, 0xf67ff9f4, 0x64d8ac, 0x64d898, > 0x0, 0xf67ff3d8), at 0x4cae8 > [13] FIX::Session::fromCallback(0x32d2b8, 0xf67ff540, 0xf67ff9f4, > 0x32d2bc, 0x1000000, 0x257474), at 0xfe2eac1c > [14] FIX::Session::verify(0x32d2b8, 0xf67ff9f4, 0x3dcab8, 0x32d3a8, > 0x32d3a8, 0x0), at 0xfe2ea094 > [15] FIX::Session::next(0x32d2b8, 0x0, 0xf67ff884, 0xf67ff878, > 0xfe3b4eac, 0xf67ff9f4), at 0xfe2ed784 > [16] FIX::Session::next(0x32d2b8, 0xf67ffb7c, 0x0, 0x0, 0x1, 0x1), at > 0xfe2ecc5c > [17] FIX::ThreadedSocketConnection::processStream(0x2fe718, 0x46b068, > 0x0, 0xe3ee0, 0x0, 0xfdc63d20), at 0xfe324908 > [18] FIX::ThreadedSocketConnection::read(0x2fe718, 0x2feb58, 0x257474, > 0x19, 0x0, 0x0), at 0xfe3246f0 > [19] FIX::ThreadedSocketInitiator::socketThread(0x2b4c88, 0x38, 0x0, > 0x0, 0x22040, 0x32d2b8), at 0xfe322250 > (dbx) threads > t@1 a l@3 ?() LWP suspended in _poll() > t@2 b l@2 ?() LWP suspended in _signotifywait() > t@3 ?() sleep on (unknown) in _reap_wait() > t@4 a l@10 eeThreadStart() LWP suspended in _poll() > t@5 a l@6 eeThreadStart() sleep on 0xf7010018 in > _lwp_sema_wait() > t@6 eeThreadStart() sleep on 0xf7010018 in > cond_reltimedwait() > t@7 a l@9 eeThreadStart() sleep on 0xf7010018 in > _lwp_sema_wait() > t@8 b l@7 _co_timerset() LWP suspended in > private___lwp_cond_wait() > t@9 a l@11 internalQueueThreadEntry() sleep on 0x2b4f78 > in _lwp_sema_wait() > t@10 a l@8 internalQueueThreadEntry() sleep on 0x2b4fb0 > in _lwp_sema_wait() > t@11 a l@1 internalQueueThreadEntry() sleep on 0x2b4fe8 > in _lwp_sema_wait() > t@12 a l@5 startThread() LWP suspended in _libc_nanosleep() > o> t@13 a l@4 socketThread() signal SIGSEGV in t_delete() > (dbx) > Do let me know if you need anymore information regarding the same > Thanks > -Channa > -----Original Message----- > From: or...@qu... [mailto:or...@qu...] > Sent: 17 June 2008 23:21 > To: Mangalore, Channabasava > Cc: qui...@li... > Subject: RE: [Quickfix-developers] Core after converting to multi > threadedapplication > Version of QuickFIX? This looks like something that has been fixed in a > previous release, I would be very interested to hear if this is > happening with 1.12.4 > --oren > > -------- Original Message -------- > > Subject: Re: [Quickfix-developers] Core after converting to multi > > threadedapplication > > From: "Mangalore, Channabasava" > > <cha...@cr...> > > Date: Sun, June 15, 2008 11:47 pm > > To: "Mangalore, Channabasava" > > <cha...@cr...>,quickfix-developers@lists.s > > ourceforge.net QuickFIX Documentation: > > http://www.quickfixengine.org/quickfix/doc/html/index.html > > QuickFIX Support: http://www.quickfixengine.org/services.html<hr>Some > > more info I am using FIX42 messaging And it is a C++ application > > running on SunOS 5.8 Generic_117000-05 sun4u sparc SUNW,Sun-Fire-480R > > Mostly it is happening when the system is loaded. > > Thanks > > Channa > > > _____________________________________________ > > > From: Mangalore, Channabasava > > > Sent: 16 June 2008 12:25 > > > To: qui...@li... > > > Subject: Core after converting to multi threaded application > > > Importance: High > > > > > > Dear All, > > > > > > I was trying to decouple the fromApp message receiving and the local > > > data processing. > > > I am copying the message received from the fromApp and pushing into > > > the queue. In the our test environment it worked wonderfully and > > > passed all the required test cases without any problem. > > > > > > When we rolled out to production it started coring :-( below is the > > > stack trace of the core > > > > > > (dbx) where > > > current thread: t@15 > > > =>[1] t_delete(0x5d11e8, 0xfe43c008, 0xfe4427cc, 0xfe44284c, > > > 0xfe442848, 0x0), at 0xfe3c27f0 > > > [2] _malloc_unlocked(0x44, 0x1d20c58, 0xfe43c008, 0x48, 0x5d11e8, > > > 0x0), at 0xfe3c1e80 > > > [3] malloc(0x44, 0x0, 0xfe43c008, 0xfe3c1ce4, 0x222e8, 0x920f4), > > > at > > > 0xfe3c1cd8 > > > [4] malloc(0xfe3c1cb8, 0xfe3c1cb8, 0xfe5e3d20, 0x44, 0xc14, > > > 0xc00), at 0xfe551c68 > > > [5] operator new(0x44, 0xfe3c1cb8, 0x13b88, 0xfe551c68, > > > 0xfee1a08c, 0x44), at 0xfee06528 > > > [6] FIX::message_order::message_order(0x11, 0x523f38, 0x1400, 0x3, > > > 0x17ac, 0xfe904df4), at 0xfe88a1a0 > > > [7] FIX::Message::setGroup(0xf6fffad4, 0x61713c, 0x617138, > > > 0xf6fffc5c, 0xf6fff974, 0x0), at 0xfe855d30 > > > [8] FIX::Message::setString(0xf6fffad4, 0xf6fffc5c, 0x1, 0x5a3090, > > > 0x6872b020, 0xf6fff94c), at 0xfe855a60 > > > [9] FIX::Message::Message(0xf6fffad4, 0xf6fffc5c, 0x5a3090, > > > 0xf6fffb88, 0xf6fffb50, 0xf6fffb30), at 0xfe853274 > > > [10] FIX::Session::next(0x5a2f10, 0xf6fffc5c, 0x1, 0xf0e3d8, > > > 0x76294, 0xfe909b74), at 0xfe87db3c > > > [11] FIX::ThreadedSocketConnection::processStream(0x52a8e8, > > > 0x1dfe550, 0x0, 0x2df240, 0x0, 0xfe5e3d20), at 0xfe88ebe4 > > > [12] FIX::ThreadedSocketConnection::readQueue(0x52a8e8, > > > 0xfe90b5a4, 0x4851049f, 0x0, 0x0, 0x0), at 0xfe88ea1c > > > [13] FIX::ThreadedSocketConnection::queueThread(0x52a8e8, > > > 0xfe935d38, 0x1, 0xfe378d04, 0x0, 0x2), at 0xfe88f0c4 > > > > > > core '../log/core' of 14663: > > > data model = _ILP32 > > > /4: flags = PR_PCINVAL > > > sigmask = 0xffffbefc,0x00001fff cursig = SIGBUS > > > /5: flags = PR_STOPPED > > > why = PR_SUSPENDED > > > /6: flags = PR_STOPPED > > > why = PR_SUSPENDED > > > /7: flags = PR_STOPPED > > > why = PR_SUSPENDED > > > sigmask = 0xffbffeff,0x00001fff > > > /8: flags = PR_STOPPED > > > why = PR_SUSPENDED > > > /9: flags = PR_STOPPED > > > why = PR_SUSPENDED > > > /10: flags = PR_STOPPED > > > why = PR_SUSPENDED > > > /11: flags = PR_STOPPED > > > why = PR_SUSPENDED > > > /12: flags = PR_STOPPED > > > why = PR_SUSPENDED > > > /13: flags = PR_STOPPED > > > why = PR_SUSPENDED > > > /1: flags = PR_STOPPED > > > why = PR_SUSPENDED > > > /2: flags = PR_STOPPED|PR_ASLWP > > > why = PR_SUSPENDED > > > sigmask = 0xffbffeff,0x00001fff > > > /3: flags = PR_STOPPED > > > why = PR_SUSPENDED > > > > > > By any chance has anyone this kind of crash? What could be the > > > possible reason for it? > > > > > > P.S. I am constructing a new message object and pushing in the > queue. > > > Am I missing something while constructing an object? > > > > > > You help in this matter will be highly appreciated. > > > > > > > > > Thanks > > > -Channa > > > > > > > > > P Please consider the environment before printing this e-mail. Thank > > > you. > > > > > > > > ====================================================================== > > ======== Please access the attached hyperlink for an important > > electronic communications disclaimer: > > http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > > ====================================================================== > > ========<hr>---------------------------------------------------------- > > --------------- Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services for just about anything > > Open Source. > > http://sourceforge.net/services/buy/index.php<hr>_____________________ > > __________________________ > > Quickfix-developers mailing list > > Qui...@li... > > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > ============================================================================== > Please access the attached hyperlink for an important electronic communications disclaimer: > http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html > ============================================================================== |
|
From: <or...@qu...> - 2008-06-26 14:50:40
|
> Hi, > Thanks for the quick reply. > > you request all messages up to 507 > Yes. And I receive them. However, the last message sent from the counterparty > is a Sequence Reset message specifying NewSeqNo=508, meaning the next message > they will send (they do not know nor care about the queue on my side, > obviously) will have a sequence number of 508. No. That is not what it means. All it means is that they have completed the resend request up to message 507. It does not mean that 508 is the next message you should be expecting. You already received 508, and unless you explicitly request 508, they should not be sending it to you again. They don't need to know about your queue, they just need to know they already sent the message. You can do a resend request any time for any reason. If the last message you received was 10,000, and you decide on a whim you want to see messages 20-50 again, this does not mean they can start sending you new messages starting with 51. One has nothing to do with the other. > I assume that by that point QuickFix does expect 508, but I guess that > processing the queued message causes it to expect 509 - this seems to > contradict FIX as it modifies expectations from the counterparty accoring to a > unilateral event (i.e. processing something queues on my side, older than the > last message received from the counterparty). Not only does the behavior not contradict the expectations of the protocol, it explicitly adheres to a reccomendation in the specification: "It is also recommended that an engine should store out of sequence messages in a temporary queue and process them in order when the gap is closed. This prevents generating resend requests for n->m, n->m+1, n->m+2, ... which can result in many resent PossDupFlag=Y messages." > I've checked with the counterparty, and this is the way they work with all of > their customers... > What do you say? I say they are incorrect in their behavior if it is as you described and they are. Now, can we add a setting that will turn off queing so it can adapt to this behavior? Absolutely, and I think we will do this because we want to be able to communicate with whatever is out there even if not completely correct. |
|
From: Kbo K. <kbo...@gm...> - 2008-06-26 11:50:04
|
Hi, Thanks for the quick reply. > you request all messages up to 507 Yes. And I receive them. However, the last message sent from the counterparty is a Sequence Reset message specifying NewSeqNo=508, meaning the next message they will send (they do not know nor care about the queue on my side, obviously) will have a sequence number of 508. I assume that by that point QuickFix does expect 508, but I guess that processing the queued message causes it to expect 509 - this seems to contradict FIX as it modifies expectations from the counterparty accoring to a unilateral event (i.e. processing something queues on my side, older than the last message received from the counterparty). I've checked with the counterparty, and this is the way they work with all of their customers... What do you say? Thanks again, Kbo |
|
From: mwins <mar...@wi...> - 2008-06-26 09:06:26
|
>> You can retrieve messages from the store by sequence number. For the >> C++ api it goes something like this: Use FIX::Session::lookupSession() >> to obtain the Session by SessionID. Then call getStore() on that >> Session. You can then call the Store's get() method, which takes a seq >> num range and a vector into which the resulting messages will be >> returned. >> >> Maybe it would be easier/faster to keep a record of used clordids as >> they come in? Thanks. This is what I thought I would have to do. I've got the model in place to support the in-memory clordids, but I just didn't know how to get the clordids from the store after a system restart. -- View this message in context: http://www.nabble.com/PossResend-and-rejecting-duplicates-tp18071972p18129661.html Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |
|
From: Mangalore, C. <cha...@cr...> - 2008-06-26 07:33:17
|
Hi Oren,
Even After updating to the quickfix 1.12.4 I am seeing the crash at the
same level,
Attached is there stack trace for your reference
(dbx) where
current thread: t@13
=>[1] t_delete(0x60a5e0, 0xfdabc008, 0xfdac27cc, 0xfdac284c, 0xfdac2848,
0x0), at 0xfda427f0
[2] _malloc_unlocked(0x2b, 0x60a5e0, 0xfdabc008, 0x30, 0x60a5e0, 0x0),
at 0xfda41e80
[3] malloc(0x2b, 0xfdac27cc, 0x1, 0x0, 0x46c5, 0x920f4), at 0xfda41cd8
[4] malloc(0xfda41cb8, 0xfda41cb8, 0xfdc63d20, 0x2b, 0xc14, 0xc00), at
0xfdbd1c68
[5] operator new(0x2b, 0x0, 0x328ac, 0xfdc306a0, 0x1400, 0xfdc63d20),
at 0xfdc314a0
[6] std::basic_string<char,std::char_traits<char>,std::allocator<char>
>::__getRep(0x1400, 0x1, 0x1, 0x0, 0x10c, 0x3b650), at 0xfdc29c4c
[7] std::basic_string<char,std::char_traits<char>,std::allocator<char>
>::basic_string(0xf67ff110, 0xf67ff11e, 0x1, 0xf67ff10f, 0x45a900,
0x3e9be8), at 0xfdc287c0
[8] FIX::FieldMap::addGroup(0x609b10, 0xc, 0x609b48, 0x0, 0x1,
0x609cd0), at 0xfe342824
[9] FIX::FieldMap::operator=(0x609b10, 0xf67ff9f4, 0x3e6730, 0x609b14,
0x5a3fe0, 0x529220), at 0xfe3425dc
[10] HSFXMessageData::HSFXMessageData(0x5edd78, 0xf67ff9f4,
0xf67ff38c, 0x609b48, 0x609b14, 0x5edd84), at 0x365ac
[11] HSFXListener::pushIntoIQueue(0x2b1ee8, 0xf67ff9f4, 0x1,
0xf67ff38c, 0xf67ff38f, 0x5edd78), at 0x410d8
[12] HSFXService::fromApp(0x64d8af, 0xf67ff9f4, 0x64d8ac, 0x64d898,
0x0, 0xf67ff3d8), at 0x4cae8
[13] FIX::Session::fromCallback(0x32d2b8, 0xf67ff540, 0xf67ff9f4,
0x32d2bc, 0x1000000, 0x257474), at 0xfe2eac1c
[14] FIX::Session::verify(0x32d2b8, 0xf67ff9f4, 0x3dcab8, 0x32d3a8,
0x32d3a8, 0x0), at 0xfe2ea094
[15] FIX::Session::next(0x32d2b8, 0x0, 0xf67ff884, 0xf67ff878,
0xfe3b4eac, 0xf67ff9f4), at 0xfe2ed784
[16] FIX::Session::next(0x32d2b8, 0xf67ffb7c, 0x0, 0x0, 0x1, 0x1), at
0xfe2ecc5c
[17] FIX::ThreadedSocketConnection::processStream(0x2fe718, 0x46b068,
0x0, 0xe3ee0, 0x0, 0xfdc63d20), at 0xfe324908
[18] FIX::ThreadedSocketConnection::read(0x2fe718, 0x2feb58, 0x257474,
0x19, 0x0, 0x0), at 0xfe3246f0
[19] FIX::ThreadedSocketInitiator::socketThread(0x2b4c88, 0x38, 0x0,
0x0, 0x22040, 0x32d2b8), at 0xfe322250
(dbx) threads
t@1 a l@3 ?() LWP suspended in _poll()
t@2 b l@2 ?() LWP suspended in _signotifywait()
t@3 ?() sleep on (unknown) in _reap_wait()
t@4 a l@10 eeThreadStart() LWP suspended in _poll()
t@5 a l@6 eeThreadStart() sleep on 0xf7010018 in
_lwp_sema_wait()
t@6 eeThreadStart() sleep on 0xf7010018 in
cond_reltimedwait()
t@7 a l@9 eeThreadStart() sleep on 0xf7010018 in
_lwp_sema_wait()
t@8 b l@7 _co_timerset() LWP suspended in
private___lwp_cond_wait()
t@9 a l@11 internalQueueThreadEntry() sleep on 0x2b4f78
in _lwp_sema_wait()
t@10 a l@8 internalQueueThreadEntry() sleep on 0x2b4fb0
in _lwp_sema_wait()
t@11 a l@1 internalQueueThreadEntry() sleep on 0x2b4fe8
in _lwp_sema_wait()
t@12 a l@5 startThread() LWP suspended in _libc_nanosleep()
o> t@13 a l@4 socketThread() signal SIGSEGV in t_delete()
(dbx)
Do let me know if you need anymore information regarding the same
Thanks
-Channa
-----Original Message-----
From: or...@qu... [mailto:or...@qu...]
Sent: 17 June 2008 23:21
To: Mangalore, Channabasava
Cc: qui...@li...
Subject: RE: [Quickfix-developers] Core after converting to multi
threadedapplication
Version of QuickFIX? This looks like something that has been fixed in a
previous release, I would be very interested to hear if this is
happening with 1.12.4
--oren
> -------- Original Message --------
> Subject: Re: [Quickfix-developers] Core after converting to multi
> threadedapplication
> From: "Mangalore, Channabasava"
> <cha...@cr...>
> Date: Sun, June 15, 2008 11:47 pm
> To: "Mangalore, Channabasava"
> <cha...@cr...>,quickfix-developers@lists.s
> ourceforge.net QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html<hr>Some
> more info I am using FIX42 messaging And it is a C++ application
> running on SunOS 5.8 Generic_117000-05 sun4u sparc SUNW,Sun-Fire-480R
> Mostly it is happening when the system is loaded.
> Thanks
> Channa
> > _____________________________________________
> > From: Mangalore, Channabasava
> > Sent: 16 June 2008 12:25
> > To: qui...@li...
> > Subject: Core after converting to multi threaded application
> > Importance: High
> >
> > Dear All,
> >
> > I was trying to decouple the fromApp message receiving and the local
> > data processing.
> > I am copying the message received from the fromApp and pushing into
> > the queue. In the our test environment it worked wonderfully and
> > passed all the required test cases without any problem.
> >
> > When we rolled out to production it started coring :-( below is the
> > stack trace of the core
> >
> > (dbx) where
> > current thread: t@15
> > =>[1] t_delete(0x5d11e8, 0xfe43c008, 0xfe4427cc, 0xfe44284c,
> > 0xfe442848, 0x0), at 0xfe3c27f0
> > [2] _malloc_unlocked(0x44, 0x1d20c58, 0xfe43c008, 0x48, 0x5d11e8,
> > 0x0), at 0xfe3c1e80
> > [3] malloc(0x44, 0x0, 0xfe43c008, 0xfe3c1ce4, 0x222e8, 0x920f4),
> > at
> > 0xfe3c1cd8
> > [4] malloc(0xfe3c1cb8, 0xfe3c1cb8, 0xfe5e3d20, 0x44, 0xc14,
> > 0xc00), at 0xfe551c68
> > [5] operator new(0x44, 0xfe3c1cb8, 0x13b88, 0xfe551c68,
> > 0xfee1a08c, 0x44), at 0xfee06528
> > [6] FIX::message_order::message_order(0x11, 0x523f38, 0x1400, 0x3,
> > 0x17ac, 0xfe904df4), at 0xfe88a1a0
> > [7] FIX::Message::setGroup(0xf6fffad4, 0x61713c, 0x617138,
> > 0xf6fffc5c, 0xf6fff974, 0x0), at 0xfe855d30
> > [8] FIX::Message::setString(0xf6fffad4, 0xf6fffc5c, 0x1, 0x5a3090,
> > 0x6872b020, 0xf6fff94c), at 0xfe855a60
> > [9] FIX::Message::Message(0xf6fffad4, 0xf6fffc5c, 0x5a3090,
> > 0xf6fffb88, 0xf6fffb50, 0xf6fffb30), at 0xfe853274
> > [10] FIX::Session::next(0x5a2f10, 0xf6fffc5c, 0x1, 0xf0e3d8,
> > 0x76294, 0xfe909b74), at 0xfe87db3c
> > [11] FIX::ThreadedSocketConnection::processStream(0x52a8e8,
> > 0x1dfe550, 0x0, 0x2df240, 0x0, 0xfe5e3d20), at 0xfe88ebe4
> > [12] FIX::ThreadedSocketConnection::readQueue(0x52a8e8,
> > 0xfe90b5a4, 0x4851049f, 0x0, 0x0, 0x0), at 0xfe88ea1c
> > [13] FIX::ThreadedSocketConnection::queueThread(0x52a8e8,
> > 0xfe935d38, 0x1, 0xfe378d04, 0x0, 0x2), at 0xfe88f0c4
> >
> > core '../log/core' of 14663:
> > data model = _ILP32
> > /4: flags = PR_PCINVAL
> > sigmask = 0xffffbefc,0x00001fff cursig = SIGBUS
> > /5: flags = PR_STOPPED
> > why = PR_SUSPENDED
> > /6: flags = PR_STOPPED
> > why = PR_SUSPENDED
> > /7: flags = PR_STOPPED
> > why = PR_SUSPENDED
> > sigmask = 0xffbffeff,0x00001fff
> > /8: flags = PR_STOPPED
> > why = PR_SUSPENDED
> > /9: flags = PR_STOPPED
> > why = PR_SUSPENDED
> > /10: flags = PR_STOPPED
> > why = PR_SUSPENDED
> > /11: flags = PR_STOPPED
> > why = PR_SUSPENDED
> > /12: flags = PR_STOPPED
> > why = PR_SUSPENDED
> > /13: flags = PR_STOPPED
> > why = PR_SUSPENDED
> > /1: flags = PR_STOPPED
> > why = PR_SUSPENDED
> > /2: flags = PR_STOPPED|PR_ASLWP
> > why = PR_SUSPENDED
> > sigmask = 0xffbffeff,0x00001fff
> > /3: flags = PR_STOPPED
> > why = PR_SUSPENDED
> >
> > By any chance has anyone this kind of crash? What could be the
> > possible reason for it?
> >
> > P.S. I am constructing a new message object and pushing in the
queue.
> > Am I missing something while constructing an object?
> >
> > You help in this matter will be highly appreciated.
> >
> >
> > Thanks
> > -Channa
> >
> >
> > P Please consider the environment before printing this e-mail. Thank
> > you.
> >
> >
> ======================================================================
> ======== Please access the attached hyperlink for an important
> electronic communications disclaimer:
> http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
> ======================================================================
> ========<hr>----------------------------------------------------------
> --------------- Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for just about anything
> Open Source.
> http://sourceforge.net/services/buy/index.php<hr>_____________________
> __________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================
|
|
From: <go...@gm...> - 2008-06-25 22:01:08
|
Sent from my BlackBerry® smartphone with SprintSpeed -----Original Message----- From: Neeraj Rai <rn...@ya...> Date: Tue, 24 Jun 2008 19:02:41 To:qui...@li... Subject: Re: [Quickfix-developers] repeating tag 382 fix 4.2 QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html QuickFIX Support: http://www.quickfixengine.org/services.html A1. I was able to fix the porblem by changing fromApp(FIX::Execution..) and calling setField(382, "1") before the crack(message) A2. I was able to simulate the error by reading the log file generated by client FIX interaction. I would be eager to hear better solutions. thanks Neeraj --- On Fri, 6/20/08, Neeraj Rai <rn...@ya...> wrote: > From: Neeraj Rai <rn...@ya...> > Subject: repeating tag 382 fix 4.2 > To: qui...@li... > Date: Friday, June 20, 2008, 8:42 PM > We are using FIX 4.2 > My counterparty is sending execution reports with tags 337 > and 375, but > no tag 382. > Quickfix is rejecting the mesg with 58="field 337 not > supported for this > msg type" > I have a testing engine written in quickfix. I tried to > simulate the error > by sending similar fields, apparently, quickfix adds tag > 382 when creating a > group. > Q1. Is there any way I can process the counter party mesg > and not have it > rejected. We know they will only send 1 repeating group > ? > Q2. Is there any way we can simulate this bad mesg in test > environment with > quickfix ? > > thanks > Neeraj ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Mike G. <mg...@co...> - 2008-06-25 20:39:56
|
mwins wrote: > I would like to reject any messages where (97)PossResend=Y and the > (11)CliOrderId is not unique. Does the engine support this? You would have to add the logic to do this, e.g. during fromApp or onMessage. > is there an API to obtain the messages from the store? > E.g. How could I load in the store to check whether I have received the > CliOrdId before? You can retrieve messages from the store by sequence number. For the C++ api it goes something like this: Use FIX::Session::lookupSession() to obtain the Session by SessionID. Then call getStore() on that Session. You can then call the Store's get() method, which takes a seq num range and a vector into which the resulting messages will be returned. Maybe it would be easier/faster to keep a record of used clordids as they come in? -- Mike Gatny Connamara Systems, LLC http://www.connamara.com/ |
|
From: Rick L. <ric...@gm...> - 2008-06-25 17:00:41
|
I should also mention the exception occurs at another line (in the same
body of the same "consumer" loop), but I removed this line from my
pseudo code below:
qty = (int)group.getMDEntrySize().getValue();
This occasionally also throws the exception.
Rick Lane wrote:
> Greetings,
>
> I have provided a slimmed-down version of the two threads that are
> running concurrently in my application in an attempt to see if anyone
> can pinpoint why I might be getting this ugly exception when grabbing
> integer values from QuickFix.Message objects.
>
> The first thread is my "producer" thread, and it basically converts
> FAST data into a valid FIX message, constructs a QuickFix.Message from
> this FIX string and then adds this Message object onto the "consumers"
> queue.
>
> The second (consumer) thread waits for new QuickFix.Message objects to
> be added to the queue, and then does the necessary processing.
>
> When the exception occurs, I print out the FIX message text in
> question to see if there is something errant about it -- I then, in a
> separate application, construct a QuickFix.Message object from the
> /same /FIX message string (that caused the original exception) and it
> works fine -- so it's definitely not a FIX-formatting issue. It must
> be a thread issue because the bug is very intermittent, some machines
> it happens every few minutes, while some machines it happens only once
> or twice a week.
>
> Please let me know if you see any glaring issues -- the same
> QuickFix.Message object is never accessed on more than one thread at a
> time, so it seems that there must be some static or shared component
> of QuickFix that is having concurrency issues when 2 threads are
> accessing it at the same time (meaning, I might have 2
> QuickFix.Message objects, one on each thread, and each thread is
> performing actions on these objects individually -- which should be
> allowed, but if each of these distinct objects has some shared
> component, then I can see a problem arising).
>
> Thanks in advance!
>
> Rick
>
> private void runProducerThread()
> {
> while (WaitHandle.WaitAny(m_SyncEventsMarketData.EventArray) != 1) {
> // raw FAST-decoded data will come in through this Queue
> ArrayList newMessages = new ArrayList();
> lock (m_QueueMarketData.SyncRoot) {
> newMessages.AddRange(m_QueueMarketData);
> m_QueueMarketData.Clear();
> }
>
> for (int msgNum = 0; msgNum < newMessages.Count; msgNum++) {
> FASTDataPacket packet = (FASTDataPacket)newMessages[msgNum];
> // my MarketDataDecoder will convert the FAST-encoded data
> into a valid FIX message string
> string msgText = m_MarketDataDecoder.ProcessPacket(packet);
> // I create a QuickFix.Message object with this string and
> my DataDictionary
> QuickFix.Message message = new QuickFix.Message(msgText,
> m_DataDictionary);
> int msgSeqNum = message.getHeader().getInt(34);* *
>
> if (msgSeqNum = m_NextMarketDataSeqNum) {
> // The other (consumer) thread, which I'm adding this
> QuickFix.Message to will do the actual
> // processing of the *contents* of the message -- this
> thread simply ensures that we don't
> // miss any UDP packets by looking at the MsgSeqNum of
> each incoming packet. The other
> // thread, then, doesn't have to worry about this.
> lock (m_ConsumerQueue.SyncRoot) {
> m_ConsumerQueue.Enqueue(message);
> m_ConsumerSyncEvents.NewItemEvent.Set();
> }
> m_NextMarketDataSeqNum = msgSeqNum + 1;
> } else {
> // reconcile missed messages...
> }
> }
> }
> }
> private void runConsumerThread()
> {
> // Wait for producer thread to add another QuickFix.Message to my Queue
> while (!m_ConsumerSyncEvents.ExitThreadEvent.WaitOne(0, false) &&
> WaitHandle.WaitAny(m_ConsumerSyncEvents.EventArray) != 1) {
> ArrayList newMessages = new ArrayList();
>
> lock (m_ConsumerQueue.SyncRoot) {
> newMessages.AddRange(m_ConsumerQueue);
> m_ConsumerQueue.Clear();
> }
> for (int i = 0; i < newMessages.Count; i++) {
> // Perform necessary processing on this Message object
> QuickFix.Message message = (QuickFix.Message)newMessages[i];
> int msgSeqNum = message.getHeader().getInt(34);
> int numEntries = message.getInt(268);
> // Each update will have multiple MDEntries
> for (uint i = 0; i < numEntries; i++) {
> QuickFix44.MarketDataIncrementalRefresh.NoMDEntries
> group = new QuickFix44.MarketDataIncrementalRefresh.NoMDEntries();
> message.getGroup(i + 1, group);
> string securityID = group.getSecurityID().getValue();
> MDPInstrument inst =
> (MDPInstrument)m_ISINToInstrumentMap[securityID];
>
> if (inst != null) {
> if (group.isSetField(83)) {
> int rptSeqNum = group.getField(new
> IntField(83)).getValue();
> if (inst.lastMarketDataSeqNum != -1 &&
> msgSeqNum > inst.lastMarketDataSeqNum) {
> // process inc refresh
> MDUpdateAction updateAction =
> group.getMDUpdateAction();
> int entrySize = 0;
> if (group.isSetMDEntrySize()) {
> MDEntrySize mdEntrySize =
> group.getMDEntrySize();
> entrySize = (int)mdEntrySize.getValue();
> }
> double entryPrice = 0;
>
> MDEntryPx entryPx = group.getMDEntryPx();
> entryPrice = entryPx.getValue();
>
> MDEntryType entryType =
> group.getMDEntryType();
> bool implied = false;
>
> QuoteCondition quoteCondition = null;
> if (group.isSetQuoteCondition()) {
> quoteCondition =
> group.getQuoteCondition();
>
> if (group.isSetQuoteCondition()) {
> if
> (group.getQuoteCondition().getValue()[0] == 'K') {
> implied = true;
> }
> }
> }
> if (group.isSetField(1020)) {
> int tradeVolume = group.getField(new
> IntField(1020)).getValue();
> inst.SetTradeVolume(tradeVolume);
> }
>
> if ((quoteCondition == null ||
> quoteCondition.getValue()[0] != QuoteCondition.EXCHANGE_BEST)) {
> int priceLevel = -1;
> switch (entryType.getValue()) {
> case MDEntryType.BID: {
> // This is where the exception is occurring
> *priceLevel =
> group.getField(new IntField(1023)).getValue();** *
> switch
> (updateAction.getValue()) {
> case MDUpdateAction.NEW:
> // do necessary
> processing...
> break;
> case
> MDUpdateAction.DELETE:
> // do necessary
> processing...
> break;
> case
> MDUpdateAction.CHANGE:
> // do necessary
> processing...
> break;
> }
> }
> break;
> case MDEntryType.OFFER: {
> // This is also where the exception is
> occurring
> *priceLevel =
> group.getField(new IntField(1023)).getValue();** *
> switch
> (updateAction.getValue()) {
> case MDUpdateAction.NEW:
> // do necessary
> processing...
> break;
> case
> MDUpdateAction.DELETE:
> // do necessary
> processing...
> break;
> case
> MDUpdateAction.CHANGE:
> // do necessary
> processing...
> break;
> }
> }
> break;
> case MDEntryType.TRADE_VOLUME:
> // do necessary processing...
> break;
> case
> MDEntryType.TRADING_SESSION_LOW_PRICE:
> // do necessary processing...
> break;
> case
> MDEntryType.TRADING_SESSION_HIGH_PRICE:
> // do necessary processing...
> break;
> case MDEntryType.SETTLEMENT_PRICE:
> // do necessary processing...
> break;
> }
> }
> }
> }
> }
> }
> }
> }
> }
>
|
|
From: Rick L. <ric...@gm...> - 2008-06-25 16:14:09
|
It is very /not /OK to have nested for-loops w/ the same counter
variable -- just another side effect of my cut-paste job. Sorry for the
confusion....
Rick
John Haldi wrote:
> I'm not a C# guy, but is it ok to have nested For loops with the same
> counter variable? In VB this would be dangerous:
>
> For i = 0 to .....
> For i = 0 to ......
>
> Next
> Next
>
> ------------------------------------------------------------------------
> *From:* qui...@li...
> [mailto:qui...@li...] *On Behalf
> Of *Rick Lane
> *Sent:* Wednesday, June 25, 2008 11:34 AM
> *To:* qui...@li...
> *Subject:* [Quickfix-developers] concurrent threads -- "External
> component hasthrown an exception"
>
> Greetings,
>
> I have provided a slimmed-down version of the two threads that are
> running concurrently in my application in an attempt to see if anyone
> can pinpoint why I might be getting this ugly exception when grabbing
> integer values from QuickFix.Message objects.
>
> The first thread is my "producer" thread, and it basically converts
> FAST data into a valid FIX message, constructs a QuickFix.Message from
> this FIX string and then adds this Message object onto the "consumers"
> queue.
>
> The second (consumer) thread waits for new QuickFix.Message objects to
> be added to the queue, and then does the necessary processing.
>
> When the exception occurs, I print out the FIX message text in
> question to see if there is something errant about it -- I then, in a
> separate application, construct a QuickFix.Message object from the
> /same /FIX message string (that caused the original exception) and it
> works fine -- so it's definitely not a FIX-formatting issue. It must
> be a thread issue because the bug is very intermittent, some machines
> it happens every few minutes, while some machines it happens only once
> or twice a week.
>
> Please let me know if you see any glaring issues -- the same
> QuickFix.Message object is never accessed on more than one thread at a
> time, so it seems that there must be some static or shared component
> of QuickFix that is having concurrency issues when 2 threads are
> accessing it at the same time (meaning, I might have 2
> QuickFix.Message objects, one on each thread, and each thread is
> performing actions on these objects individually -- which should be
> allowed, but if each of these distinct objects has some shared
> component, then I can see a problem arising).
>
> Thanks in advance!
>
> Rick
>
> private void runProducerThread()
> {
> while (WaitHandle.WaitAny(m_SyncEventsMarketData.EventArray) != 1) {
> // raw FAST-decoded data will come in through this Queue
> ArrayList newMessages = new ArrayList();
> lock (m_QueueMarketData.SyncRoot) {
> newMessages.AddRange(m_QueueMarketData);
> m_QueueMarketData.Clear();
> }
>
> for (int msgNum = 0; msgNum < newMessages.Count; msgNum++) {
> FASTDataPacket packet = (FASTDataPacket)newMessages[msgNum];
> // my MarketDataDecoder will convert the FAST-encoded data
> into a valid FIX message string
> string msgText = m_MarketDataDecoder.ProcessPacket(packet);
> // I create a QuickFix.Message object with this string and
> my DataDictionary
> QuickFix.Message message = new QuickFix.Message(msgText,
> m_DataDictionary);
> int msgSeqNum = message.getHeader().getInt(34);* *
>
> if (msgSeqNum = m_NextMarketDataSeqNum) {
> // The other (consumer) thread, which I'm adding this
> QuickFix.Message to will do the actual
> // processing of the *contents* of the message -- this
> thread simply ensures that we don't
> // miss any UDP packets by looking at the MsgSeqNum of
> each incoming packet. The other
> // thread, then, doesn't have to worry about this.
> lock (m_ConsumerQueue.SyncRoot) {
> m_ConsumerQueue.Enqueue(message);
> m_ConsumerSyncEvents.NewItemEvent.Set();
> }
> m_NextMarketDataSeqNum = msgSeqNum + 1;
> } else {
> // reconcile missed messages...
> }
> }
> }
> }
> private void runConsumerThread()
> {
> // Wait for producer thread to add another QuickFix.Message to my Queue
> while (!m_ConsumerSyncEvents.ExitThreadEvent.WaitOne(0, false) &&
> WaitHandle.WaitAny(m_ConsumerSyncEvents.EventArray) != 1) {
> ArrayList newMessages = new ArrayList();
>
> lock (m_ConsumerQueue.SyncRoot) {
> newMessages.AddRange(m_ConsumerQueue);
> m_ConsumerQueue.Clear();
> }
> for (int i = 0; i < newMessages.Count; i++) {
> // Perform necessary processing on this Message object
> QuickFix.Message message = (QuickFix.Message)newMessages[i];
> int msgSeqNum = message.getHeader().getInt(34);
> int numEntries = message.getInt(268);
> // Each update will have multiple MDEntries
> for (uint i = 0; i < numEntries; i++) {
> QuickFix44.MarketDataIncrementalRefresh.NoMDEntries
> group = new QuickFix44.MarketDataIncrementalRefresh.NoMDEntries();
> message.getGroup(i + 1, group);
> string securityID = group.getSecurityID().getValue();
> MDPInstrument inst =
> (MDPInstrument)m_ISINToInstrumentMap[securityID];
>
> if (inst != null) {
> if (group.isSetField(83)) {
> int rptSeqNum = group.getField(new
> IntField(83)).getValue();
> if (inst.lastMarketDataSeqNum != -1 &&
> msgSeqNum > inst.lastMarketDataSeqNum) {
> // process inc refresh
> MDUpdateAction updateAction =
> group.getMDUpdateAction();
> int entrySize = 0;
> if (group.isSetMDEntrySize()) {
> MDEntrySize mdEntrySize =
> group.getMDEntrySize();
> entrySize = (int)mdEntrySize.getValue();
> }
> double entryPrice = 0;
>
> MDEntryPx entryPx = group.getMDEntryPx();
> entryPrice = entryPx.getValue();
>
> MDEntryType entryType =
> group.getMDEntryType();
> bool implied = false;
>
> QuoteCondition quoteCondition = null;
> if (group.isSetQuoteCondition()) {
> quoteCondition =
> group.getQuoteCondition();
>
> if (group.isSetQuoteCondition()) {
> if
> (group.getQuoteCondition().getValue()[0] == 'K') {
> implied = true;
> }
> }
> }
> if (group.isSetField(1020)) {
> int tradeVolume = group.getField(new
> IntField(1020)).getValue();
> inst.SetTradeVolume(tradeVolume);
> }
>
> if ((quoteCondition == null ||
> quoteCondition.getValue()[0] != QuoteCondition.EXCHANGE_BEST)) {
> int priceLevel = -1;
> switch (entryType.getValue()) {
> case MDEntryType.BID: {
> // This is where the exception is occurring
> *priceLevel =
> group.getField(new IntField(1023)).getValue();** *
> switch
> (updateAction.getValue()) {
> case MDUpdateAction.NEW:
> // do necessary
> processing...
> break;
> case
> MDUpdateAction.DELETE:
> // do necessary
> processing...
> break;
> case
> MDUpdateAction.CHANGE:
> // do necessary
> processing...
> break;
> }
> }
> break;
> case MDEntryType.OFFER: {
> // This is also where the exception is
> occurring
> *priceLevel =
> group.getField(new IntField(1023)).getValue();** *
> switch
> (updateAction.getValue()) {
> case MDUpdateAction.NEW:
> // do necessary
> processing...
> break;
> case
> MDUpdateAction.DELETE:
> // do necessary
> processing...
> break;
> case
> MDUpdateAction.CHANGE:
> // do necessary
> processing...
> break;
> }
> }
> break;
> case MDEntryType.TRADE_VOLUME:
> // do necessary processing...
> break;
> case
> MDEntryType.TRADING_SESSION_LOW_PRICE:
> // do necessary processing...
> break;
> case
> MDEntryType.TRADING_SESSION_HIGH_PRICE:
> // do necessary processing...
> break;
> case MDEntryType.SETTLEMENT_PRICE:
> // do necessary processing...
> break;
> }
> }
> }
> }
> }
> }
> }
> }
> }
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 8.0.101 / Virus Database: 270.4.1/1518 - Release Date:
> 6/25/2008 9:46 AM
>
|
|
From: Rick L. <ric...@gm...> - 2008-06-25 15:55:06
|
I re-wrote a lot of this in MS Word so I could preserve the color
formatting of the code so it would be easier for people to read -- this
will almost certainly not compile (and yes, in my code it's actually >=,
but I removed a block of code, so I meant to replace it with ==).
Thanks.
Rick
or...@qu... wrote:
> Haven't completely gone through this, and not what you are looking for,
> but is this line correct?
> if (msgSeqNum = m_NextMarketDataSeqNum) {
>
> Did you mean this to be a comparison?
>
>
>> private void runProducerThread()
>> {
>> while (WaitHandle.WaitAny(m_SyncEventsMarketData.EventArray) != 1) {
>> // raw FAST-decoded data will come in through this Queue
>> ArrayList newMessages = new ArrayList();
>> lock (m_QueueMarketData.SyncRoot) {
>> newMessages.AddRange(m_QueueMarketData);
>> m_QueueMarketData.Clear();
>> }
>>
>> for (int msgNum = 0; msgNum < newMessages.Count; msgNum++) {
>> FASTDataPacket packet = (FASTDataPacket)newMessages[msgNum];
>> // my MarketDataDecoder will convert the FAST-encoded data
>> into a valid FIX message string
>> string msgText = m_MarketDataDecoder.ProcessPacket(packet);
>> // I create a QuickFix.Message object with this string and
>> my DataDictionary
>> QuickFix.Message message = new QuickFix.Message(msgText,
>> m_DataDictionary);
>> int msgSeqNum = message.getHeader().getInt(34);* *
>>
>> if (msgSeqNum = m_NextMarketDataSeqNum) {
>> // The other (consumer) thread, which I'm adding this
>> QuickFix.Message to will do the actual
>> // processing of the *contents* of the message -- this
>> thread simply ensures that we don't
>> // miss any UDP packets by looking at the MsgSeqNum of
>> each incoming packet. The other
>> // thread, then, doesn't have to worry about this.
>> lock (m_ConsumerQueue.SyncRoot) {
>> m_ConsumerQueue.Enqueue(message);
>> m_ConsumerSyncEvents.NewItemEvent.Set();
>> }
>> m_NextMarketDataSeqNum = msgSeqNum + 1;
>> } else {
>> // reconcile missed messages...
>> }
>> }
>> }
>> }
>> private void runConsumerThread()
>> {
>> // Wait for producer thread to add another QuickFix.Message to my Queue
>> while (!m_ConsumerSyncEvents.ExitThreadEvent.WaitOne(0, false) &&
>> WaitHandle.WaitAny(m_ConsumerSyncEvents.EventArray) != 1) {
>> ArrayList newMessages = new ArrayList();
>>
>> lock (m_ConsumerQueue.SyncRoot) {
>> newMessages.AddRange(m_ConsumerQueue);
>> m_ConsumerQueue.Clear();
>> }
>> for (int i = 0; i < newMessages.Count; i++) {
>> // Perform necessary processing on this Message object
>> QuickFix.Message message = (QuickFix.Message)newMessages[i];
>> int msgSeqNum = message.getHeader().getInt(34);
>> int numEntries = message.getInt(268);
>> // Each update will have multiple MDEntries
>> for (uint i = 0; i < numEntries; i++) {
>> QuickFix44.MarketDataIncrementalRefresh.NoMDEntries
>> group = new QuickFix44.MarketDataIncrementalRefresh.NoMDEntries();
>> message.getGroup(i + 1, group);
>> string securityID = group.getSecurityID().getValue();
>> MDPInstrument inst =
>> (MDPInstrument)m_ISINToInstrumentMap[securityID];
>>
>> if (inst != null) {
>> if (group.isSetField(83)) {
>> int rptSeqNum = group.getField(new
>> IntField(83)).getValue();
>> if (inst.lastMarketDataSeqNum != -1 && msgSeqNum
>> > inst.lastMarketDataSeqNum) {
>> // process inc refresh
>> MDUpdateAction updateAction =
>> group.getMDUpdateAction();
>> int entrySize = 0;
>> if (group.isSetMDEntrySize()) {
>> MDEntrySize mdEntrySize =
>> group.getMDEntrySize();
>> entrySize = (int)mdEntrySize.getValue();
>> }
>> double entryPrice = 0;
>>
>> MDEntryPx entryPx = group.getMDEntryPx();
>> entryPrice = entryPx.getValue();
>>
>> MDEntryType entryType = group.getMDEntryType();
>> bool implied = false;
>>
>> QuoteCondition quoteCondition = null;
>> if (group.isSetQuoteCondition()) {
>> quoteCondition = group.getQuoteCondition();
>>
>> if (group.isSetQuoteCondition()) {
>> if
>> (group.getQuoteCondition().getValue()[0] == 'K') {
>> implied = true;
>> }
>> }
>> }
>> if (group.isSetField(1020)) {
>> int tradeVolume = group.getField(new
>> IntField(1020)).getValue();
>> inst.SetTradeVolume(tradeVolume);
>> }
>>
>> if ((quoteCondition == null ||
>> quoteCondition.getValue()[0] != QuoteCondition.EXCHANGE_BEST)) {
>> int priceLevel = -1;
>> switch (entryType.getValue()) {
>> case MDEntryType.BID: {
>> // This is where the exception is occurring
>> *priceLevel =
>> group.getField(new IntField(1023)).getValue();** *
>> switch
>> (updateAction.getValue()) {
>> case MDUpdateAction.NEW:
>> // do necessary
>> processing...
>> break;
>> case MDUpdateAction.DELETE:
>> // do necessary
>> processing...
>> break;
>> case MDUpdateAction.CHANGE:
>> // do necessary
>> processing...
>> break;
>> }
>> }
>> break;
>> case MDEntryType.OFFER: {
>> // This is also where the exception is
>> occurring
>> *priceLevel =
>> group.getField(new IntField(1023)).getValue();** *
>> switch
>> (updateAction.getValue()) {
>> case MDUpdateAction.NEW:
>> // do necessary
>> processing...
>> break;
>> case MDUpdateAction.DELETE:
>> // do necessary
>> processing...
>> break;
>> case MDUpdateAction.CHANGE:
>> // do necessary
>> processing...
>> break;
>> }
>> }
>> break;
>> case MDEntryType.TRADE_VOLUME:
>> // do necessary processing...
>> break;
>> case
>> MDEntryType.TRADING_SESSION_LOW_PRICE:
>> // do necessary processing...
>> break;
>> case
>> MDEntryType.TRADING_SESSION_HIGH_PRICE:
>> // do necessary processing...
>> break;
>> case MDEntryType.SETTLEMENT_PRICE:
>> // do necessary processing...
>> break;
>> }
>> }
>> }
>> }
>> }
>> }
>> }
>> }
>> }<hr>-------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php<hr>_______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>
>
|
|
From: <or...@qu...> - 2008-06-25 15:51:16
|
Haven't completely gone through this, and not what you are looking for,
but is this line correct?
if (msgSeqNum = m_NextMarketDataSeqNum) {
Did you mean this to be a comparison?
> private void runProducerThread()
> {
> while (WaitHandle.WaitAny(m_SyncEventsMarketData.EventArray) != 1) {
> // raw FAST-decoded data will come in through this Queue
> ArrayList newMessages = new ArrayList();
> lock (m_QueueMarketData.SyncRoot) {
> newMessages.AddRange(m_QueueMarketData);
> m_QueueMarketData.Clear();
> }
>
> for (int msgNum = 0; msgNum < newMessages.Count; msgNum++) {
> FASTDataPacket packet = (FASTDataPacket)newMessages[msgNum];
> // my MarketDataDecoder will convert the FAST-encoded data
> into a valid FIX message string
> string msgText = m_MarketDataDecoder.ProcessPacket(packet);
> // I create a QuickFix.Message object with this string and
> my DataDictionary
> QuickFix.Message message = new QuickFix.Message(msgText,
> m_DataDictionary);
> int msgSeqNum = message.getHeader().getInt(34);* *
>
> if (msgSeqNum = m_NextMarketDataSeqNum) {
> // The other (consumer) thread, which I'm adding this
> QuickFix.Message to will do the actual
> // processing of the *contents* of the message -- this
> thread simply ensures that we don't
> // miss any UDP packets by looking at the MsgSeqNum of
> each incoming packet. The other
> // thread, then, doesn't have to worry about this.
> lock (m_ConsumerQueue.SyncRoot) {
> m_ConsumerQueue.Enqueue(message);
> m_ConsumerSyncEvents.NewItemEvent.Set();
> }
> m_NextMarketDataSeqNum = msgSeqNum + 1;
> } else {
> // reconcile missed messages...
> }
> }
> }
> }
> private void runConsumerThread()
> {
> // Wait for producer thread to add another QuickFix.Message to my Queue
> while (!m_ConsumerSyncEvents.ExitThreadEvent.WaitOne(0, false) &&
> WaitHandle.WaitAny(m_ConsumerSyncEvents.EventArray) != 1) {
> ArrayList newMessages = new ArrayList();
>
> lock (m_ConsumerQueue.SyncRoot) {
> newMessages.AddRange(m_ConsumerQueue);
> m_ConsumerQueue.Clear();
> }
> for (int i = 0; i < newMessages.Count; i++) {
> // Perform necessary processing on this Message object
> QuickFix.Message message = (QuickFix.Message)newMessages[i];
> int msgSeqNum = message.getHeader().getInt(34);
> int numEntries = message.getInt(268);
> // Each update will have multiple MDEntries
> for (uint i = 0; i < numEntries; i++) {
> QuickFix44.MarketDataIncrementalRefresh.NoMDEntries
> group = new QuickFix44.MarketDataIncrementalRefresh.NoMDEntries();
> message.getGroup(i + 1, group);
> string securityID = group.getSecurityID().getValue();
> MDPInstrument inst =
> (MDPInstrument)m_ISINToInstrumentMap[securityID];
>
> if (inst != null) {
> if (group.isSetField(83)) {
> int rptSeqNum = group.getField(new
> IntField(83)).getValue();
> if (inst.lastMarketDataSeqNum != -1 && msgSeqNum
> > inst.lastMarketDataSeqNum) {
> // process inc refresh
> MDUpdateAction updateAction =
> group.getMDUpdateAction();
> int entrySize = 0;
> if (group.isSetMDEntrySize()) {
> MDEntrySize mdEntrySize =
> group.getMDEntrySize();
> entrySize = (int)mdEntrySize.getValue();
> }
> double entryPrice = 0;
>
> MDEntryPx entryPx = group.getMDEntryPx();
> entryPrice = entryPx.getValue();
>
> MDEntryType entryType = group.getMDEntryType();
> bool implied = false;
>
> QuoteCondition quoteCondition = null;
> if (group.isSetQuoteCondition()) {
> quoteCondition = group.getQuoteCondition();
>
> if (group.isSetQuoteCondition()) {
> if
> (group.getQuoteCondition().getValue()[0] == 'K') {
> implied = true;
> }
> }
> }
> if (group.isSetField(1020)) {
> int tradeVolume = group.getField(new
> IntField(1020)).getValue();
> inst.SetTradeVolume(tradeVolume);
> }
>
> if ((quoteCondition == null ||
> quoteCondition.getValue()[0] != QuoteCondition.EXCHANGE_BEST)) {
> int priceLevel = -1;
> switch (entryType.getValue()) {
> case MDEntryType.BID: {
> // This is where the exception is occurring
> *priceLevel =
> group.getField(new IntField(1023)).getValue();** *
> switch
> (updateAction.getValue()) {
> case MDUpdateAction.NEW:
> // do necessary
> processing...
> break;
> case MDUpdateAction.DELETE:
> // do necessary
> processing...
> break;
> case MDUpdateAction.CHANGE:
> // do necessary
> processing...
> break;
> }
> }
> break;
> case MDEntryType.OFFER: {
> // This is also where the exception is
> occurring
> *priceLevel =
> group.getField(new IntField(1023)).getValue();** *
> switch
> (updateAction.getValue()) {
> case MDUpdateAction.NEW:
> // do necessary
> processing...
> break;
> case MDUpdateAction.DELETE:
> // do necessary
> processing...
> break;
> case MDUpdateAction.CHANGE:
> // do necessary
> processing...
> break;
> }
> }
> break;
> case MDEntryType.TRADE_VOLUME:
> // do necessary processing...
> break;
> case
> MDEntryType.TRADING_SESSION_LOW_PRICE:
> // do necessary processing...
> break;
> case
> MDEntryType.TRADING_SESSION_HIGH_PRICE:
> // do necessary processing...
> break;
> case MDEntryType.SETTLEMENT_PRICE:
> // do necessary processing...
> break;
> }
> }
> }
> }
> }
> }
> }
> }
> }<hr>-------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php<hr>_______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
|
|
From: Rick L. <ric...@gm...> - 2008-06-25 15:35:10
|
Greetings,
I have provided a slimmed-down version of the two threads that are
running concurrently in my application in an attempt to see if anyone
can pinpoint why I might be getting this ugly exception when grabbing
integer values from QuickFix.Message objects.
The first thread is my "producer" thread, and it basically converts FAST
data into a valid FIX message, constructs a QuickFix.Message from this
FIX string and then adds this Message object onto the "consumers" queue.
The second (consumer) thread waits for new QuickFix.Message objects to
be added to the queue, and then does the necessary processing.
When the exception occurs, I print out the FIX message text in question
to see if there is something errant about it -- I then, in a separate
application, construct a QuickFix.Message object from the /same /FIX
message string (that caused the original exception) and it works fine --
so it's definitely not a FIX-formatting issue. It must be a thread
issue because the bug is very intermittent, some machines it happens
every few minutes, while some machines it happens only once or twice a week.
Please let me know if you see any glaring issues -- the same
QuickFix.Message object is never accessed on more than one thread at a
time, so it seems that there must be some static or shared component of
QuickFix that is having concurrency issues when 2 threads are accessing
it at the same time (meaning, I might have 2 QuickFix.Message objects,
one on each thread, and each thread is performing actions on these
objects individually -- which should be allowed, but if each of these
distinct objects has some shared component, then I can see a problem
arising).
Thanks in advance!
Rick
private void runProducerThread()
{
while (WaitHandle.WaitAny(m_SyncEventsMarketData.EventArray) != 1) {
// raw FAST-decoded data will come in through this Queue
ArrayList newMessages = new ArrayList();
lock (m_QueueMarketData.SyncRoot) {
newMessages.AddRange(m_QueueMarketData);
m_QueueMarketData.Clear();
}
for (int msgNum = 0; msgNum < newMessages.Count; msgNum++) {
FASTDataPacket packet = (FASTDataPacket)newMessages[msgNum];
// my MarketDataDecoder will convert the FAST-encoded data
into a valid FIX message string
string msgText = m_MarketDataDecoder.ProcessPacket(packet);
// I create a QuickFix.Message object with this string and
my DataDictionary
QuickFix.Message message = new QuickFix.Message(msgText,
m_DataDictionary);
int msgSeqNum = message.getHeader().getInt(34);* *
if (msgSeqNum = m_NextMarketDataSeqNum) {
// The other (consumer) thread, which I'm adding this
QuickFix.Message to will do the actual
// processing of the *contents* of the message -- this
thread simply ensures that we don't
// miss any UDP packets by looking at the MsgSeqNum of
each incoming packet. The other
// thread, then, doesn't have to worry about this.
lock (m_ConsumerQueue.SyncRoot) {
m_ConsumerQueue.Enqueue(message);
m_ConsumerSyncEvents.NewItemEvent.Set();
}
m_NextMarketDataSeqNum = msgSeqNum + 1;
} else {
// reconcile missed messages...
}
}
}
}
private void runConsumerThread()
{
// Wait for producer thread to add another QuickFix.Message to my Queue
while (!m_ConsumerSyncEvents.ExitThreadEvent.WaitOne(0, false) &&
WaitHandle.WaitAny(m_ConsumerSyncEvents.EventArray) != 1) {
ArrayList newMessages = new ArrayList();
lock (m_ConsumerQueue.SyncRoot) {
newMessages.AddRange(m_ConsumerQueue);
m_ConsumerQueue.Clear();
}
for (int i = 0; i < newMessages.Count; i++) {
// Perform necessary processing on this Message object
QuickFix.Message message = (QuickFix.Message)newMessages[i];
int msgSeqNum = message.getHeader().getInt(34);
int numEntries = message.getInt(268);
// Each update will have multiple MDEntries
for (uint i = 0; i < numEntries; i++) {
QuickFix44.MarketDataIncrementalRefresh.NoMDEntries
group = new QuickFix44.MarketDataIncrementalRefresh.NoMDEntries();
message.getGroup(i + 1, group);
string securityID = group.getSecurityID().getValue();
MDPInstrument inst =
(MDPInstrument)m_ISINToInstrumentMap[securityID];
if (inst != null) {
if (group.isSetField(83)) {
int rptSeqNum = group.getField(new
IntField(83)).getValue();
if (inst.lastMarketDataSeqNum != -1 && msgSeqNum
> inst.lastMarketDataSeqNum) {
// process inc refresh
MDUpdateAction updateAction =
group.getMDUpdateAction();
int entrySize = 0;
if (group.isSetMDEntrySize()) {
MDEntrySize mdEntrySize =
group.getMDEntrySize();
entrySize = (int)mdEntrySize.getValue();
}
double entryPrice = 0;
MDEntryPx entryPx = group.getMDEntryPx();
entryPrice = entryPx.getValue();
MDEntryType entryType = group.getMDEntryType();
bool implied = false;
QuoteCondition quoteCondition = null;
if (group.isSetQuoteCondition()) {
quoteCondition = group.getQuoteCondition();
if (group.isSetQuoteCondition()) {
if
(group.getQuoteCondition().getValue()[0] == 'K') {
implied = true;
}
}
}
if (group.isSetField(1020)) {
int tradeVolume = group.getField(new
IntField(1020)).getValue();
inst.SetTradeVolume(tradeVolume);
}
if ((quoteCondition == null ||
quoteCondition.getValue()[0] != QuoteCondition.EXCHANGE_BEST)) {
int priceLevel = -1;
switch (entryType.getValue()) {
case MDEntryType.BID: {
// This is where the exception is occurring
*priceLevel =
group.getField(new IntField(1023)).getValue();** *
switch
(updateAction.getValue()) {
case MDUpdateAction.NEW:
// do necessary
processing...
break;
case MDUpdateAction.DELETE:
// do necessary
processing...
break;
case MDUpdateAction.CHANGE:
// do necessary
processing...
break;
}
}
break;
case MDEntryType.OFFER: {
// This is also where the exception is
occurring
*priceLevel =
group.getField(new IntField(1023)).getValue();** *
switch
(updateAction.getValue()) {
case MDUpdateAction.NEW:
// do necessary
processing...
break;
case MDUpdateAction.DELETE:
// do necessary
processing...
break;
case MDUpdateAction.CHANGE:
// do necessary
processing...
break;
}
}
break;
case MDEntryType.TRADE_VOLUME:
// do necessary processing...
break;
case
MDEntryType.TRADING_SESSION_LOW_PRICE:
// do necessary processing...
break;
case
MDEntryType.TRADING_SESSION_HIGH_PRICE:
// do necessary processing...
break;
case MDEntryType.SETTLEMENT_PRICE:
// do necessary processing...
break;
}
}
}
}
}
}
}
}
}
|
|
From: Neeraj R. <rn...@ya...> - 2008-06-25 02:09:11
|
There may be several causes for this. One that I recently ran into, was that unknown to me, the code was calling msg.get(FIX::<somefield>) and quickfix sent a reject back. In my case, I could have that call under an if condition, for only those cases where it was required. For example, FIX::lastShares is not required on execution report with trans type = Cxl, ack or rej. thanks neeraj --- On Tue, 6/24/08, qui...@li... <qui...@li...> wrote: > From: qui...@li... <qui...@li...> > Subject: Quickfix-developers Digest, Vol 25, Issue 14 > To: qui...@li... > Date: Tuesday, June 24, 2008, 9:20 PM > Send Quickfix-developers mailing list submissions to > qui...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > or, via email, send a message with subject or body > 'help' to > qui...@li... > > You can reach the person managing the list at > qui...@li... > > When replying, please edit your Subject line so it is more > specific > than "Re: Contents of Quickfix-developers > digest..." > > > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: > http://www.quickfixengine.org/services.html > > > Today's Topics: > > 1. TradeCaptureReport rejected by QF (Jack Goral) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 24 Jun 2008 14:46:28 -0500 > From: Jack Goral <jg...@ch...> > Subject: [Quickfix-developers] TradeCaptureReport rejected > by QF > To: > "'qui...@li...'" > <qui...@li...> > Message-ID: > <44A...@ch...> > > Content-Type: text/plain; charset="us-ascii" > > A TradeCaptureReport (35=AE) message which comes to me is > rejected (35=3). QF complains about field NoLegs (555). The > NoLegs field is missing from message TradeCaptureReport. > > Why is this message rejected if the field NoLegs is not > required? > > Any hints welcome. > > 20080620 13:42:29.493(000132.737579)| INFO > |712|QFIX_LOG_MESSAGE:8=FIX.4.49=42235=AE49=ICE56=285634=752=20080620-18:42:29.34557=1571=192487=0856=0828=017=39392010521239=2570=N55=21783648=BRN > FMQ0008!22=8461=FXXXXX32=1.031=132.29018=175=2008062060=20080620-18:42:29.470552=154=237=39392010521211=456564249453=6448=blablabla447=D452=11448=blablabla > 1447=D452=13448=2856447=D452=56448=637447=D452=4448=2122805447=D452=51448=U447=D452=5458=45656424910=196|FIX::ThreadedFileLog::onIncoming|ThreadedFileLog.cpp(45) > > 20080620 13:42:29.525(000132.766330)| INFO > |712|QFIX_LOG_EVENT:20080620-18:42:29 : Message 7 Rejected: > Incorrect data format for > value:555|FIX::ThreadedFileLog::onEvent|ThreadedFileLog.cpp(58) > > 20080620 13:42:29.525(000132.766522)| INFO |712|OUT: > toAdmin (to ICE): > 8=FIX.4.49=11135=334=749=285652=20080620-18:42:29.52556=ICE45=758=Incorrect > data format for > value371=555372=AE373=610=216|ice::ICE_FIXApplication::toAdmin|FIXApplication.cpp(270) > > 20080620 13:42:29.525(000132.766583)| INFO > |712|QFIX_LOG_MESSAGE:8=FIX.4.49=11135=334=749=285652=20080620-18:42:29.52556=ICE45=758=Incorrect > data format for > value371=555372=AE373=610=216|FIX::ThreadedFileLog::onOutgoing|ThreadedFileLog.cpp(52) > > QuickFix config file has: > ------------------------- > > UseDataDictionary=Y > DataDictionary=FIX44_ICE.xml > ValidateFieldsOutOfOrder = N > ValidateFieldsHaveValues = N > ValidateUserDefinedFields = N > > My FIX44_ICE.xml : > ------------------ > <message name="TradeCaptureReport" > msgtype="AE" msgcat="app"> > <field name="TradeReportID" > required="Y" /> > <field name="TradeReportTransType" > required="N" /> > <field name="TradeReportType" > required="N" /> > ...... > <field name="AvgPxIndicator" > required="N" /> > <component name="PositionAmountData" > required="N" /> > <field name="MultiLegReportingType" > required="N" /> > <field name="TradeLegRefID" > required="N" /> > <group name="NoLegs" > required="N"> > <component name="InstrumentLeg" > required="N" /> > <field name="LegQty" > required="N" /> > <field name="LegSwapType" > required="N" /> > <component name="LegStipulations" > required="N" /> > ..... > <field number="555" > name="NoLegs" type="NUMINGROUP" /> > ..... > > > Jack Goral > Software Engineer > Chopper Trading, LLC > jg...@ch...<mailto:jg...@ch...> > (312)628-3722 > > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > > ------------------------------ > > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > > End of Quickfix-developers Digest, Vol 25, Issue 14 > *************************************************** |
|
From: Neeraj R. <rn...@ya...> - 2008-06-25 02:02:48
|
A1. I was able to fix the porblem by changing fromApp(FIX::Execution..)
and calling setField(382, "1") before the crack(message)
A2. I was able to simulate the error by reading the log file generated by
client FIX interaction.
I would be eager to hear better solutions.
thanks
Neeraj
--- On Fri, 6/20/08, Neeraj Rai <rn...@ya...> wrote:
> From: Neeraj Rai <rn...@ya...>
> Subject: repeating tag 382 fix 4.2
> To: qui...@li...
> Date: Friday, June 20, 2008, 8:42 PM
> We are using FIX 4.2
> My counterparty is sending execution reports with tags 337
> and 375, but
> no tag 382.
> Quickfix is rejecting the mesg with 58="field 337 not
> supported for this
> msg type"
> I have a testing engine written in quickfix. I tried to
> simulate the error
> by sending similar fields, apparently, quickfix adds tag
> 382 when creating a
> group.
> Q1. Is there any way I can process the counter party mesg
> and not have it
> rejected. We know they will only send 1 repeating group
> ?
> Q2. Is there any way we can simulate this bad mesg in test
> environment with
> quickfix ?
>
> thanks
> Neeraj
|
|
From: Jack G. <jg...@ch...> - 2008-06-24 19:46:37
|
A TradeCaptureReport (35=AE) message which comes to me is rejected (35=3). QF complains about field NoLegs (555). The NoLegs field is missing from message TradeCaptureReport.
Why is this message rejected if the field NoLegs is not required?
Any hints welcome.
20080620 13:42:29.493(000132.737579)| INFO |712|QFIX_LOG_MESSAGE:8=FIX.4.49=42235=AE49=ICE56=285634=752=20080620-18:42:29.34557=1571=192487=0856=0828=017=39392010521239=2570=N55=21783648=BRN FMQ0008!22=8461=FXXXXX32=1.031=132.29018=175=2008062060=20080620-18:42:29.470552=154=237=39392010521211=456564249453=6448=blablabla447=D452=11448=blablabla 1447=D452=13448=2856447=D452=56448=637447=D452=4448=2122805447=D452=51448=U447=D452=5458=45656424910=196|FIX::ThreadedFileLog::onIncoming|ThreadedFileLog.cpp(45)
20080620 13:42:29.525(000132.766330)| INFO |712|QFIX_LOG_EVENT:20080620-18:42:29 : Message 7 Rejected: Incorrect data format for value:555|FIX::ThreadedFileLog::onEvent|ThreadedFileLog.cpp(58)
20080620 13:42:29.525(000132.766522)| INFO |712|OUT: toAdmin (to ICE): 8=FIX.4.49=11135=334=749=285652=20080620-18:42:29.52556=ICE45=758=Incorrect data format for value371=555372=AE373=610=216|ice::ICE_FIXApplication::toAdmin|FIXApplication.cpp(270)
20080620 13:42:29.525(000132.766583)| INFO |712|QFIX_LOG_MESSAGE:8=FIX.4.49=11135=334=749=285652=20080620-18:42:29.52556=ICE45=758=Incorrect data format for value371=555372=AE373=610=216|FIX::ThreadedFileLog::onOutgoing|ThreadedFileLog.cpp(52)
QuickFix config file has:
-------------------------
UseDataDictionary=Y
DataDictionary=FIX44_ICE.xml
ValidateFieldsOutOfOrder = N
ValidateFieldsHaveValues = N
ValidateUserDefinedFields = N
My FIX44_ICE.xml :
------------------
<message name="TradeCaptureReport" msgtype="AE" msgcat="app">
<field name="TradeReportID" required="Y" />
<field name="TradeReportTransType" required="N" />
<field name="TradeReportType" required="N" />
......
<field name="AvgPxIndicator" required="N" />
<component name="PositionAmountData" required="N" />
<field name="MultiLegReportingType" required="N" />
<field name="TradeLegRefID" required="N" />
<group name="NoLegs" required="N">
<component name="InstrumentLeg" required="N" />
<field name="LegQty" required="N" />
<field name="LegSwapType" required="N" />
<component name="LegStipulations" required="N" />
.....
<field number="555" name="NoLegs" type="NUMINGROUP" />
.....
Jack Goral
Software Engineer
Chopper Trading, LLC
jg...@ch...<mailto:jg...@ch...>
(312)628-3722
|
|
From: Rick L. <ric...@gm...> - 2008-06-24 18:15:08
|
John Haldi discovered that IntConvertor.convert() is a static method --
I have 2 threads that run concurrently in the following manner:
Thread A (producer):
-----------
1) takes in raw compressed FAST data from the CME, converts it to a FIX
string
2) takes FIX string and creates a QuickFix.Message object, passing the
string into the constructor
3) checks the MsgSeqNum of this message ( message.getHeader().getInt(34) )
3a) if MsgSeqNum is the next one it expects, it hands it off to
the consumer (Thread B)
3b) if MsgSeqNum is /not /the next one, it creates a request to
obtain the missed packets (this is on UDP so unreliable)
Thread B (consumer):
----------
1) listens for Thread A to add another QuickFix.Message to a shared Queue
2) Processes the message's fields
So I'm wondering if the two red portions are causing these issues,
because the low-level IntConvertor.convert() function is static. Even
though the same message object will NEVER be accessed by more than one
thread, if the same helper function is then I could see this causing a
problem....
I don't see any shared/static member /variables /used by these methods,
so I don't know how they could be interfering with each other -- but I
thought I'd add this bit of information.
Thanks,
Rick
John Haldi wrote:
> Sorry it wasn't helpful. In looking at the source code for QF, I see
> that the FIX.IntConvertor.convert function is indeed declared as a
> shared method, but that and a buck will get you a cup of coffee. From
> what you say there is no possibility of another thread calling the
> convert function concurrently, so I'm somewhat at a loss as to what
> could cause the function to fail. Its pretty straightforward code in
> that function, so if something is wrong it should throw the exception
> constantly. I'm still suspicious that something in the QF library
> could be calling this function concurrently, but I have no clue where
> to begin guessing...
>
> jh
>
> ------------------------------------------------------------------------
> *From:* Rick Lane [mailto:ric...@gm...]
> *Sent:* Tuesday, June 24, 2008 11:39 AM
> *To:* John Haldi
> *Subject:* Re: [Quickfix-developers] FIX.IntConvertor.convert()
> throwingexception
>
> John,
>
> Yes, my first thought was a threading issue as well, however I don't
> believe it is one -- and if it is, it's not as straightforward as your
> example below. Here's why:
>
> I am not establishing a FIX session -- I am simply using the QuickFix
> library as a "utility" library to parse incoming FIX messages. The
> CME (which I forget -- is this what you work with as well?) provides
> /market data/ in FAST format ("FIX Adapted for STreaming" or something
> like that) which is compressed data that I decode into a string.
> Rather than re-invent the wheel and parse the string representation of
> the FIX message myself, I simply create a QuickFix.Message object
> passing this string into the constructor (along with a
> DataDictionary). Then I can use the QuickFix functions like getGroup,
> getIntField, etc..., and it does all the parsing legwork for me.
>
> Also, there is only one thread listening to market data.
>
> Now, the /order routing /portion of my server /does /use a true
> QuickFix "session" -- however for testing purposes, I'm not even
> instantiating this, I'm /only /listening to the Market Data side of
> things....
>
> Thanks again for your time!
>
> Rick
>
> John Haldi wrote:
>> Rick,
>>
>> Is it possible that somehow the group and/or the field in question is
>> getting overwritten by a concurrent call on a different thread. My
>> thinking is as follows: If you have a threadSocketInitiator/Acceptor
>> working, perhaps every now and then two messages with this repeating
>> group are coming in at the exact same time on two different threads,
>> and that there is a helper function of some sort going on under the
>> hood and one message is stomping on the other message - i.e. maybe
>> the helper function is using a shared variable/class when it should
>> be using an instance variable/class.
>>
>> The scenario I'm thinking of goes something like this:
>>
>> Thread #1 gets message with 10 group elements
>> Thread #1 calls getGroup - getGroup stores group related info in a
>> variable
>> Thread #1 processes the first 5 of 10 group elements
>> Thread #2 gets message with 3 group elements
>> Thread #2 calls getGroup - getGroup stores group related info in the
>> same variable
>> Thread #1 now tries to access 6-10 of the group elements but they
>> point to disposed memory
>> Thread #1 throws a really nasty exception
>>
>> If we allow for something like the above as a possibility, it would
>> explain 1) the seemingly intermittent nature of the problem, and 2)
>> why you can't recreate it in a debugger.
>>
>> Its just a thought...
>>
>> John
>>
>>
>> ------------------------------------------------------------------------
>> *From:* qui...@li...
>> [mailto:qui...@li...] *On Behalf
>> Of *Rick Lane
>> *Sent:* Tuesday, June 24, 2008 11:13 AM
>> *To:* qui...@li...
>> *Subject:* Re: [Quickfix-developers] FIX.IntConvertor.convert()
>> throwingexception
>>
>> What's interesting is that I take the message text from the message
>> that causes the exception and then basically recreate the
>> QuickFix.Message object with this string in a separate application,
>> and make the same calls, and I don't get the exception.
>>
>> So it seems pretty obvious to me this isn't a message-formatting
>> issue -- does this shed any light onto what might be the problem?
>> Not sure why my Exception text is so vague (" External component has
>> thrown an exception.").
>>
>> Rick Lane wrote:
>>> Greetings,
>>>
>>> I have finally tracked down a bug that has been giving me problems
>>> for some time. I'm getting an exception thrown in the
>>> FIX.IntConvertor.convert(string) function, and I can't seem to
>>> figure out why. It always happens at the same place: in an
>>> Incremental Refresh message, I extract the NoMDEntries group. I
>>> then try to extract the "price level" of the update (int field
>>> 1023), and here is where I get the exception. Here is the stack trace:
>>>
>>> External component has thrown an exception.
>>> at _CxxThrowException(Void* , _s__ThrowInfo* )
>>> at
>>> FIX.IntConvertor.convert(basic_string<char\,std::char_traits<char>\,std::allocator<char>
>>> >* value)
>>> at QuickFix.Group.getField(IntField field)
>>> at
>>> MDPDataServer.MDPMarketDataProvider.ProcessMarketDataIncrementalRefresh
>>>
>>> and here's the line of code that's causing the exception:
>>>
>>> // message is a QuickFix.Message object constructed from the string
>>> below
>>> int numEntries = message.getInt(268);
>>> for (uint i = 0; i < numEntries; i++) {
>>> QuickFix44.MarketDataIncrementalRefresh.NoMDEntries group = new
>>> QuickFix44.MarketDataIncrementalRefresh.NoMDEntries();
>>> message.getGroup(i + 1, group);
>>> int priceLevel = group.getField(new IntField(1023)).getValue();
>>> // exception occurs here
>>> ...
>>>
>>> What's strange is that I process millions of market data messages
>>> every day and this only happens maybe 2 or 3 times a week -- my
>>> first thought was that this was a FAST decoding issue (when I'm
>>> building the text representation of the FIX message before QuickFix
>>> is even used), but at such a low probability of occurrence, I can't
>>> imagine this is a decoding issue.
>>>
>>> Here is the message that is throwing the exception; I've highlighted
>>> the 1023 entries, and they all look fine to me -- any thoughts?
>>> (also, to make it more readable/email friendly, I removed the
>>> stop-bits and replaced them with the | character).
>>>
>>> Thanks,
>>> Rick
>>>
>>> 8=FIX.4.2 | 9=1961 | 35=X | 34=1304872 | 49=CME |
>>> 52=20080624115930866 | 75=20080624 | 268=22 | 279=1 | *1023=2* |
>>> 269=0 | 270=45 | 271=85 | 273=115930000 | 336=2 | 276=K | 22=8 |
>>> 48=801005 | 83=13568 | 279=1 | *1023=1* | 269=0 | 270=94 | 271=293 |
>>> 273=115930000 | 336=2 | 276=K | 22=8 | 48=801101 | 83=38117 | 279=1
>>> | *1023=1* | 269=0 | 270=112.5 | 271=293 | 273=115930000 | 336=2 |
>>> 276=K | 22=8 | 48=801109 | 83=35245 | 279=1 | *1023=2* | 269=1 |
>>> 270=9551 | 271=1743 | 273=115930000 | 336=2 | 276=K | 22=8 |
>>> 48=803001 | 83=231922 | 279=1 | *1023=1* | 269=1 | 270=9631 |
>>> 271=1134 | 273=115930000 | 336=2 | 276=K | 22=8 | 48=803900 |
>>> 83=278737 | 279=1 | *1023=2* | 269=1 | 270=9631.5 | 271=12656 |
>>> 273=115930000 | 336=2 | 276=K | 22=8 | 48=803900 | 83=278738 | 279=1
>>> | *1023=1* | 269=1 | 270=9536 | 271=1175 | 273=115930000 | 336=2 |
>>> 276=K | 22=8 | 48=806001 | 83=204449 | 279=1 | *1023=2* | 269=1 |
>>> 270=9536.5 | 271=13774 | 273=115930000 | 336=2 | 276=K | 22=8 |
>>> 48=806001 | 83=204450 | 279=1 | *1023=1* | 269=1 | 270=9612 |
>>> 271=332 | 273=115930000 | 336=2 | 276=K | 22=8 | 48=806901 |
>>> 83=422681 | 279=1 | *1023=2* | 269=1 | 270=9612.5 | 271=17576 |
>>> 273=115930000 | 336=2 | 276=K | 22=8 | 48=806901 | 83=422682 | 279=1
>>> | *1023=2* | 269=1 | 270=9592 | 271=30035 | 273=115930000 | 336=2 |
>>> 276=K | 22=8 | 48=809901 | 83=312614 | 279=1 | *1023=2* | 269=0 |
>>> 270=17 | 271=47 | 273=115930000 | 336=2 | 276=K | 22=8 | 48=800915 |
>>> 83=20839 | 279=1 | *1023=1* | 269=0 | 270=43 | 271=58 |
>>> 273=115930000 | 336=2 | 276=K | 22=8 | 48=801105 | 83=10961 | 279=2
>>> | *1023=1* | 269=1 | 270=44.5 | 271=12 | 273=115930000 | 336=2 |
>>> 276=K | 22=8 | 48=801105 | 83=10962 | 279=1 | *1023=1* | 269=1 |
>>> 270=45 | 271=12 | 273=115930000 | 336=2 | 276=K | 22=8 | 48=801105 |
>>> 83=10963 | 279=0 | *1023=2* | 269=1 | 270=45.5 | 271=216 |
>>> 273=115930000 | 336=2 | 276=K | 22=8 | 48=801105 | 83=10964 | 279=1
>>> | *1023=1* | 269=0 | 270=60 | 271=58 | 273=115930000 | 336=2 | 276=K
>>> | 22=8 | 48=801113 | 83=9462 | 279=1 | *1023=2* | 269=0 | 270=-4 |
>>> 271=24 | 273=115930000 | 336=2 | 276=K | 22=8 | 48=801208 | 83=3856
>>> | 279=2 | *1023=2* | 269=1 | 270=9495.5 | 271=49 | 273=115930000 |
>>> 336=2 | 276=K | 22=8 | 48=803201 | 83=8643 | 279=0 | *1023=2* |
>>> 269=1 | 270=9496 | 271=93 | 273=115930000 | 336=2 | 276=K | 22=8 |
>>> 48=803201 | 83=8644 | 279=1 | *1023=1* | 269=0 | 270=81 | 271=967 |
>>> 273=115930000 | 336=2 | 276=K | 22=8 | 48=800208 | 83=76335 | 279=1
>>> | *1023=2* | 269=0 | 270=80.5 | 271=409 | 273=115930000 | 336=2 |
>>> 276=K | 22=8 | 48=800208 | 83=76336 | 1128=8 | 10=233 |
>>>
>>>
>>>
>> No virus found in this incoming message.
>> Checked by AVG.
>> Version: 8.0.100 / Virus Database: 270.4.1/1516 - Release Date:
>> 6/24/2008 7:53 AM
>>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 8.0.100 / Virus Database: 270.4.1/1516 - Release Date:
> 6/24/2008 7:53 AM
>
|
|
From: <or...@qu...> - 2008-06-24 15:39:20
|
I'm not sure I see this as a bug in quickfix, but rather a bug in the counterprty. Let me make sure I understand what you are saying. You receive message 508, but expect 507 508 is queued you request all messages up to 507 you are now expecting 508 the queued 508 message, which is the expected number, is processed you should now expect 509, since you have process 508 which was not part of the resend request They send you a new message with sequence number 508, completely different from the previous message they tagged with 508. Eep! That's not allowed. > -------- Original Message -------- > Subject: [Quickfix-developers] SequenceReset bug? > From: Kbo Keplowsky <kbo...@gm...> > Date: Sun, June 22, 2008 9:21 am > To: qui...@li... > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > Hi all, > I've come across an issue that looks like a bug to me - i.e. not in accordance > with the FIX protocol. > My system (QuickFix initiator) logs in, only to find out that the sequence > number is too high (508 instead of 507). > That's cool, so it queues the current message (#508) and sends a resend > request (0 to 507). > The counterparty responds, sending a sequence reset from 507 to 508 (basically > saying there's nothing to send, and that 508 is the next sequence number, I > assume). > Now here's the problem - my system is satisfied, sets the next expected number > to 508, and processes the queued message (#508, remember?). This, however, > advances the sequence number... > On the next heartbeat, my system gets a heartbeat response, with a sequence > number of (did you guess?) 508... which is reasonable for the counterparty, > but too low for my system, and so it disconnects. This can go on forever. > What should I do? I've read the FIX specs, and it explicitly say that the > NewSeqNum field in the SequenceReset message is the next number sent by the > counterparty, so I believe the bug is with QuickFix, talking into account the > seqnum of the queued message... > Help, please... > Thanks, > Kbo > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
98 messages has been excluded from this view by a project administrator.
