quickfix-developers — QuickFIX developers forum

Re: [Quickfix-developers] problem when message.setField method is called

[Mikhail V. <mve...@gm...>]

You may want to consider using specific message class defined rather
then using the underlying base.
-  
Regards,

Mikhail Veygman


-----Original Message-----
From: Brian Hill <bh...@pe...>
To: qui...@li...
<qui...@li...>
Subject: [Quickfix-developers] problem when message.setField method is
called
Date: Wed, 9 Dec 2009 11:54:02 -0600

QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Hi,

 

If I modify a FIX message by calling the setField method, I get a
segmentation fault when the destructor of the FIX message is called.

 

I am using the latest QuickFIX, Ubuntu 4.1.2-16, and gcc 4.1.3. I have
debugged and searched everywhere, but can't find a solution.

Any help would be appreciated. Please see below for details.

 

Thank you,

Brian

 

####################################

My Program

####################################

void testMessage()

{

                cout << "Creating message..." << endl;

                FIX::Message message;

                

                cout << "Adding field..." << endl;

                message.setField(35, "A");

//            message.setField(FIX::MsgType("A")); // it doesn't matter
which way I set the field

//            message.setField(55, "IBM");                     // it
doesn't matter which field I set

}

 

int main(int argc, const char *argv[])

{

                testMessage();

                return 0;

}

 

####################################

GDB Output

####################################

 

(gdb) run

Starting program: /home/user/workspace/Client/Debug/Client

[Thread debugging using libthread_db enabled]

[New Thread -1213826560 (LWP 12088)]

Creating message...

Adding field...

 

Program received signal SIGSEGV, Segmentation fault.

 

[Switching to Thread -1213826560 (LWP 12088)]

0xb7d7c566 in __gnu_cxx::__pool<true>::_M_reclaim_block ()
from /usr/lib/libstdc++.so.6

(gdb) backtrace

#0  0xb7d7c566 in __gnu_cxx::__pool<true>::_M_reclaim_block ()
from /usr/lib/libstdc++.so.6

#1  0xb7e6083c in __gnu_cxx::__mt_alloc<std::_Rb_tree_node<std::pair<int
const, FIX::FieldBase> >,
__gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::deallocate
(this=0xbfba0dfc, __p=0x8053230, __n=1)

    at /usr/include/c++/4.1.3/ext/mt_allocator.h:721

#2  0xb7e60938 in std::_Rb_tree<int, std::pair<int const,
FIX::FieldBase>, std::_Select1st<std::pair<int const, FIX::FieldBase> >,
FIX::message_order, __gnu_cxx::__mt_alloc<std::pair<int const,
FIX::FieldBase>, __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool,
true> > >::_M_erase (this=0xbfba0dfc, __x=0x8053230)

    at /usr/include/c++/4.1.3/bits/stl_tree.h:362

#3  0xb7eb75c9 in FIX::FieldMap::clear (this=0xbfba0df8)
at /usr/include/c++/4.1.3/bits/stl_tree.h:692

#4  0xb7eb76a0 in ~FieldMap (this=0xbfba0df8) at FieldMap.cpp:35

#5  0x0804b3a5 in ~Message (this=0xbfba0df8)
at /home/user/quickfix/include/quickfix/Message.h:57

#6  0x0804a535 in testMessage () at ../Main.cpp:24

#7  0x0804a5bb in main (argc=8, argv=0xbfba1264) at ../Main.cpp:30

 

 

 

####################################

FieldMap.cpp - WHERE I THINK THE PROBLEM IS

####################################

 

The destructor gets called:

---------------------------

FieldMap::~FieldMap()

{ QF_STACK_IGNORE_BEGIN


clear();                                                                

  QF_STACK_IGNORE_END

}

 

The clear method gets called:

-----------------------------

void FieldMap::clear()

{ QF_STACK_PUSH(FieldMap::clear)

 

  m_fields.clear();                             // ####### The clear
method is called on an stl::multimap and this is where the seg fault
occurs

 

  Groups::iterator i;

  for ( i = m_groups.begin(); i != m_groups.end(); ++i )

  {

    std::vector < FieldMap* > ::iterator j;

    for ( j = i->second.begin(); j != i->second.end(); ++j )

      delete *j;

  }

  m_groups.clear();

 

  QF_STACK_POP

}

 

 



STATEMENT OF CONFIDENTIALITY: This message and any attachments are
intended solely for the person or entity to which it is addressed and
may contain confidential or privileged information. If the recipient of
this message is not the addressee or a person responsible for delivering
the message to the addressee, such recipient is prohibited from reading
or using this message in any way. If you have received this message in
error, please call the sender of this message immediately and delete the
message from any computer.

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] problem when message.setField method is called

[Brian H. <bh...@pe...>]

Hi,

If I modify a FIX message by calling the setField method, I get a segmentation fault when the destructor of the FIX message is called.

I am using the latest QuickFIX, Ubuntu 4.1.2-16, and gcc 4.1.3. I have debugged and searched everywhere, but can't find a solution.
Any help would be appreciated. Please see below for details.

Thank you,
Brian

####################################
My Program
####################################
void testMessage()
{
                cout << "Creating message..." << endl;
                FIX::Message message;

                cout << "Adding field..." << endl;
                message.setField(35, "A");
//            message.setField(FIX::MsgType("A")); // it doesn't matter which way I set the field
//            message.setField(55, "IBM");                     // it doesn't matter which field I set
}

int main(int argc, const char *argv[])
{
                testMessage();
                return 0;
}

####################################
GDB Output
####################################

(gdb) run
Starting program: /home/user/workspace/Client/Debug/Client
[Thread debugging using libthread_db enabled]
[New Thread -1213826560 (LWP 12088)]
Creating message...
Adding field...

Program received signal SIGSEGV, Segmentation fault.

[Switching to Thread -1213826560 (LWP 12088)]
0xb7d7c566 in __gnu_cxx::__pool<true>::_M_reclaim_block () from /usr/lib/libstdc++.so.6
(gdb) backtrace
#0  0xb7d7c566 in __gnu_cxx::__pool<true>::_M_reclaim_block () from /usr/lib/libstdc++.so.6
#1  0xb7e6083c in __gnu_cxx::__mt_alloc<std::_Rb_tree_node<std::pair<int const, FIX::FieldBase> >, __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::deallocate (this=0xbfba0dfc, __p=0x8053230, __n=1)
    at /usr/include/c++/4.1.3/ext/mt_allocator.h:721
#2  0xb7e60938 in std::_Rb_tree<int, std::pair<int const, FIX::FieldBase>, std::_Select1st<std::pair<int const, FIX::FieldBase> >, FIX::message_order, __gnu_cxx::__mt_alloc<std::pair<int const, FIX::FieldBase>, __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> > >::_M_erase (this=0xbfba0dfc, __x=0x8053230)
    at /usr/include/c++/4.1.3/bits/stl_tree.h:362
#3  0xb7eb75c9 in FIX::FieldMap::clear (this=0xbfba0df8) at /usr/include/c++/4.1.3/bits/stl_tree.h:692
#4  0xb7eb76a0 in ~FieldMap (this=0xbfba0df8) at FieldMap.cpp:35
#5  0x0804b3a5 in ~Message (this=0xbfba0df8) at /home/user/quickfix/include/quickfix/Message.h:57
#6  0x0804a535 in testMessage () at ../Main.cpp:24
#7  0x0804a5bb in main (argc=8, argv=0xbfba1264) at ../Main.cpp:30



####################################
FieldMap.cpp - WHERE I THINK THE PROBLEM IS
####################################

The destructor gets called:
---------------------------
FieldMap::~FieldMap()
{ QF_STACK_IGNORE_BEGIN
  clear();
  QF_STACK_IGNORE_END
}

The clear method gets called:
-----------------------------
void FieldMap::clear()
{ QF_STACK_PUSH(FieldMap::clear)

  m_fields.clear();                             // ####### The clear method is called on an stl::multimap and this is where the seg fault occurs

  Groups::iterator i;
  for ( i = m_groups.begin(); i != m_groups.end(); ++i )
  {
    std::vector < FieldMap* > ::iterator j;
    for ( j = i->second.begin(); j != i->second.end(); ++j )
      delete *j;
  }
  m_groups.clear();

  QF_STACK_POP
}



STATEMENT OF CONFIDENTIALITY: This message and any attachments are intended solely for the person or entity to which it is addressed and may contain confidential or privileged information. If the recipient of this message is not the addressee or a person responsible for delivering the message to the addressee, such recipient is prohibited from reading or using this message in any way. If you have received this message in error, please call the sender of this message immediately and delete the message from any computer.

Re: [Quickfix-developers] Market Data Request -- dificulties getting a group.

[Ben L. <be...@no...>]

Thanks.  Yeah, I'd figured that much out.  I hadn't realized the indexes were
one based, so thanks for that.  I'm not trying to grab a field out of that
group.  I'm doing it this way.  Is there a more fully qualified way to do
it?

FIX::MDEntryType mDEntryType;
noMDEntries.getField(mDEntryType);
-- 
View this message in context: http://old.nabble.com/Market-Data-Request----dificulties-getting-a-group.-tp26687543p26687744.html
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.

Re: [Quickfix-developers] Market Data Request -- dificulties getting a group.

[Andrei G. <an...@gm...>]

[...]

> void Application::onMessage( const FIX42::MarketDataSnapshotFullRefresh&
> message, const FIX::SessionID& )
> {
>        cout << "onMessage: " << message.toString() << endl;
>
>        FIX::Symbol symbol;
>        message.get(symbol);
>
>        FIX::NoMDEntries noMDEntries;
>        message.getGroup(0, noMDEntries);
> }

FIX::NoMDEntries is a Field class. In order to get the group instance, try:

FIX42::MarketDataSnapshotFullRefresh::NoMDEntries noMDEntries;
message.getGroup(1, noMDEntries);//Indexes are 1-based

Re: [Quickfix-developers] Market Data Request -- dificulties getting a group.

[Ben L. <be...@no...>]

Just realized what I was doing wrong....  Fixed code:

void Application::onMessage( const FIX42::MarketDataSnapshotFullRefresh&
message, const FIX::SessionID& )
{
	cout << "onMessage: " << message.toString() << endl;
	
	FIX::Symbol symbol;
	message.get(symbol);

	FIX42::MarketDataSnapshotFullRefresh::NoMDEntries noMDEntries;
	message.getGroup(0, noMDEntries);
}
-- 
View this message in context: http://old.nabble.com/Market-Data-Request----dificulties-getting-a-group.-tp26687543p26687621.html
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.

[Quickfix-developers] Market Data Request -- dificulties getting a group.

[Ben L. <be...@no...>]

Hi,  I'm trying to grab a group from a market data reply and having issues.

The relevant code is below.  I'm compiling with MSVS 2010 and getting this
error:
error C2664: 'FIX::Message::getGroup' : cannot convert parameter 2 from
'FIX::NoMDEntries' to 'FIX::Group &'

Any help would be greatly appreciated. 

Thanks,
Ben

void Application::onMessage( const FIX42::MarketDataSnapshotFullRefresh&
message, const FIX::SessionID& )
{
	cout << "onMessage: " << message.toString() << endl;
	
	FIX::Symbol symbol;
	message.get(symbol);

	FIX::NoMDEntries noMDEntries;
	message.getGroup(0, noMDEntries);
}
-- 
View this message in context: http://old.nabble.com/Market-Data-Request----dificulties-getting-a-group.-tp26687543p26687543.html
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.

[Quickfix-developers] New FIX Protocol London Weekly Workshop

[sedisscom <se...@se...>]

The new FIX protocol weekly 3 hours workshop in London gives members of the
FIX protocol community the opportunity to gain valuable knowledge about
implementation of the FIX protocol, algorithmic applications development and
integration in trading solutions.
Participants from all backgrounds and all levels of expertise learn new
skills and find answers to their questions and discover practical solutions
to FIX protocol usage.

Main topics of the workshop:
- installation, setup and running a FIX engine
- communication between an engine and a trading application
- connection to a counterparty system
- using trading platforms
- developing your own trading application
- algorithmic trading strategies
- setting up a trading hardware system
- service providers
- troubleshooting
- plus other topics as required

The workshop takes place every Monday from 6pm to 9pm in Kensington Town
Hall, London, just two minutes from High Street Kensington tube station.
Tickets are £75, via pre-sale only. For tickets contact me on 07835526065.

Bring your own system and show others how you do it.   
-- 
View this message in context: http://old.nabble.com/New-FIX-Protocol-London-Weekly-Workshop-tp26680006p26680006.html
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.

[Quickfix-developers] Fix QuoteRequest

[Fabio R. <FRe...@1e...>]

Hi together

i try to create a quoterequest like this:



DataDictionary dictionary = new DataDictionary(FixTransmitterProperties.GetDictionaryStream(properties.DataDictionaryPath));

Message fixMessage = new Message(sendMessage, dictionary);



when i do it with only one leg, which means with 146=1 and then only one time 55=Bla167=CALL etc., then it works fine and i get the message in the order i declared it in the datadictionary. but if i try to create it with 2 or more legs, i get it in  an ascending order:



15=CHF?54=2?55=103022_1?60=20091202-13:32:34? and so on.



has anybody a clue what the problem could be?



best regards

fabio

Re: [Quickfix-developers] CME iLink 2500 message resend limit‏

[Steve S. <st...@ho...>]

Hi,

 

The reason I think one needs this is that I beleive the way the QF code currently works is that if you are doing a resend request in FIX Version 4.2 you will get a zero for the EndSeqNo. You are correct that you can catch the resend request message that you are about to send out. However, unless I am mistaken, you cannot tell how many messages you are requesting with that resend request since EndSeqNo is set to zero. If you could tell, you could modify the message before it went out to set the EndSeqNo to a number that iLink will accept.

 

Steve

 

 
> Date: Tue, 24 Nov 2009 10:56:25 -0200
> Subject: Re: [Quickfix-developers] CME iLink 2500 message resend limit‏
> From: bl...@gm...
> To: st...@ho...
> CC: qui...@li...
> 
> Hi,
> 
> Why you want this?
> 
> EndSeqNo equals zero doesn't mean "resend all messages from sequence
> number equals BeginSeqNo to the last one message sent"?
> 
> You really need it?
> 
> Alternativelly you can catch any message that will be resent
> imediately before it be resent, into the callback "toApp".
> 
> Blabos
> 
> 2009/11/23 Steve Smith <st...@ho...>:
> > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> >
> >
> > I appologize if this has already been asked but am wondering how others have addressed this. We are intercepting the resend request that QuickFIX generates after seeing a sequence number gap. QuickFIX sets the EndSeqNo to zero, as it should. We can change the EndSeqNo to the BeginSeqNo + 2499, but this breaks down if the gap was less than 2500 messages as we are asking for more messages than the other side (the CME) has to deliver. There is a way to get the sequence number that QuickFIX expects, but is there anyway to get the sequence number that triggered the resend request? Or is there a better way to address this?
> >
> > Thanks, Steve
> > ________________________________
> > Windows 7: It works the way you want. Learn more.
> > ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> > trial. Simplify your report design, integration and deployment - and focus on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > Quickfix-developers mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> >
 		 	   		  
_________________________________________________________________
Bing brings you maps, menus, and reviews organized in one place.
http://www.bing.com/search?q=restaurants&form=MFESRP&publ=WLHMTAG&crea=TEXT_MFESRP_Local_MapsMenu_Resturants_1x1

[Quickfix-developers] please unsubscribe me... thanks in advance

[Avi R. <avi...@gm...>]

I'm not developing in quickfix any more...

[Quickfix-developers] QuickFix hangs forvever if the the FIX session gets loggged out while the network connection is down.

[christophe v <cve...@ho...>]

Hi,

We are using a vpn to connect to our FIX broker's server. We have been
experiencing different behaviour when the vpn connection gets disconnected.

Note that we are using the C++ implementation of QuickFix and I have set the
ReconnectInterval to 1sec.

1st Case :

If the vpn connection is disconnected but is reconnected before the
FIX::onLogout event occurs, the FIX session reconnects as soon as the
onLogout event happens.

2nd Case:

If the vpn connection is disconnected but is reconnected only after
FIX::onLogout event occurs, the FIX session takes approximately 6min before
it tries to issue another logon request. During these 6min nothing happens,
no FIX messages are exchanged between our application and the FIX server. 

Does anybody has any clue of what might be happening? To me it looks like a
quickfix setting, in that case how can we change that behaviour?

Thanks

Chris
-- 
View this message in context: http://old.nabble.com/QuickFix-hangs-forvever-if-the-the-FIX-session-gets-loggged-out-while-the-network-connection-is-down.-tp26517490p26517490.html
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.

Re: [Quickfix-developers] CME iLink 2500 message resend limit‏

[Blabos de B. <bl...@gm...>]

Hi,

Why you want this?

EndSeqNo equals zero doesn't mean "resend all messages from sequence
number equals BeginSeqNo to the last one message sent"?

You really need it?

Alternativelly you can catch any message that will be resent
imediately before it be resent, into the callback "toApp".

Blabos

2009/11/23 Steve Smith <st...@ho...>:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> I appologize if this has already been asked but am wondering how others have addressed this. We are intercepting the resend request that QuickFIX generates after seeing a sequence number gap. QuickFIX sets the EndSeqNo to zero, as it should. We can change the EndSeqNo to the BeginSeqNo + 2499, but this breaks down if the gap was less than 2500 messages as we are asking for more messages than the other side (the CME) has to deliver. There is a way to get the sequence number that QuickFIX expects, but is there anyway to get the sequence number that triggered the resend request? Or is there a better way to address this?
>
> Thanks, Steve
> ________________________________
> Windows 7: It works the way you want. Learn more.
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

[Quickfix-developers] CME iLink 2500 message resend limit‏

[Steve S. <st...@ho...>]

I appologize if this has already been asked but am wondering how others have addressed this. We are intercepting the resend request that QuickFIX generates after seeing a sequence number gap. QuickFIX sets the EndSeqNo to zero, as it should. We can change the EndSeqNo to the BeginSeqNo + 2499, but this breaks down if the gap was less than 2500 messages as we are asking for more messages than the other side (the CME) has to deliver. There is a way to get the sequence number that QuickFIX expects, but is there anyway to get the sequence number that triggered the resend request? Or is there a better way to address this?
 
Thanks, Steve  		 	   		  
_________________________________________________________________
Windows 7: It works the way you want. Learn more.
http://www.microsoft.com/Windows/windows-7/default.aspx?ocid=PID24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_evergreen:112009v2

Re: [Quickfix-developers] Issue in parsing FIX44 Message - MsgTyp=n

[Tan W. H. <wen...@bu...>]

Hi Andrei,

I'm afraid, extractField(...) method is the private method of Message
class.

The issue is still that:

Message::getHeader().getField(TAG213) always return INCOMPLETE data,
whenever the raw message contains embedded SOH character in Tag213

Best regards,
wh

>>> Andrei Goldchleger <an...@gm...> 11/23/2009 9:33:39 AM >>>
On Sun, Nov 22, 2009 at 11:08 PM, Tan Weng Heng
<wen...@bu...> wrote:
> QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html 
> QuickFIX Support: http://www.quickfixengine.org/services.html 
>
> Yes. I loaded the FIX44 (Quickfix-1.12.4) dict object & pass it to
the
> Message constructor before callilng the Message::setString(...)
method
> to perform the parsing.
>
> As I understand it, the QF parser would separate the message fields
> into 3 categories, as specified in the dict:
> 1) HEADER
> 2) BODY/MESSAGE
> 3) TRAILER
>
> My debugging session shows that the Message::extractField(...) only
> looks into the BODY list for the field length, which always fail as
tag
> 212 & 213 is catagerized as HEADER as per the FIX spec.
>
> Is this a bug ?

Try Message::getHeader().extractField().

DISCLAIMER:

This e-mail (including any attachments) may contain confidential information. If you are not the intended recipient, you are hereby notified that any review, distribution, printing, copying or use of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the sender or Bursa Malaysia immediately and delete the original message. Opinions, conclusions and other information in this e-mail that do not relate to the official business of Bursa Malaysia and/or its group of companies ("Bursa Malaysia Group") shall be understood as neither given nor endorsed by Bursa Malaysia Group and Bursa Malaysia Group accepts no responsibility for the same. All liability arising from or in connection with computer viruses and/or corrupted e-mails is excluded to the fullest extent permitted by law.

Re: [Quickfix-developers] Issue in parsing FIX44 Message - MsgTyp=n

[Andrei G. <an...@gm...>]

On Sun, Nov 22, 2009 at 11:08 PM, Tan Weng Heng
<wen...@bu...> wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Yes. I loaded the FIX44 (Quickfix-1.12.4) dict object & pass it to the
> Message constructor before callilng the Message::setString(...) method
> to perform the parsing.
>
> As I understand it, the QF parser would separate the message fields
> into 3 categories, as specified in the dict:
> 1) HEADER
> 2) BODY/MESSAGE
> 3) TRAILER
>
> My debugging session shows that the Message::extractField(...) only
> looks into the BODY list for the field length, which always fail as tag
> 212 & 213 is catagerized as HEADER as per the FIX spec.
>
> Is this a bug ?

Try Message::getHeader().extractField().

Re: [Quickfix-developers] Issue in parsing FIX44 Message - MsgTyp=n

[Tan W. H. <wen...@bu...>]

Yes. I loaded the FIX44 (Quickfix-1.12.4) dict object & pass it to the
Message constructor before callilng the Message::setString(...) method
to perform the parsing.

As I understand it, the QF parser would separate the message fields
into 3 categories, as specified in the dict:
1) HEADER
2) BODY/MESSAGE
3) TRAILER

My debugging session shows that the Message::extractField(...) only
looks into the BODY list for the field length, which always fail as tag
212 & 213 is catagerized as HEADER as per the FIX spec.

Is this a bug ?

Thanks,
wh


>>> Dale Wilson <wi...@oc...> 11/20/2009 11:58:02 PM >>>
Are you passing a data dictionary as well as the string?   QuickFIX 
needs the data dictionary to know that XmlDataLen is the length field 
for XmlData.

Dale

Tan Weng Heng wrote:
> QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html 
> QuickFIX Support: http://www.quickfixengine.org/services.html 
>
> Hi All,
>
> Is this a known issue in QuickFix ?
>
> Whenever I pass the Message class a string with the following C++
> string:
>
>
"8=FIX.4.4\0019=73\00135=n\00149=BRKR\00156=INVMGR\00134=235\00152=19980604-07:58:28\001212=14\001213=<R>A=B\001C=D</R>\00110=235\001"
>
> It's unable to extract XmlData(213) properly if the contents
contains
> embeded SOH characters, eventhough XmlDataLen(212) has specified its
> length accordingly.
>
> The Message::extractField method seems to only check the
availability
> of the "length field" i.e XmlDataLen(212) in the BODY fields,
ignoring
> the HEADER fields.
>
> Please correct me if I'm wrong.
>
> Thanks,
> wh
>
> --------------START Code Excerpt--------------------------
>     if ( pDD && pDD->isDataField(field) )
>     {
>       std::string fieldLength;
>       // Assume length field is 1 less.
>       int lenField = field - 1;
>       // Special case for Signature which violates above assumption.
>       if ( field == 89 ) lenField = 93;
>
>       if ( pGroup && pGroup->isSetField( lenField ) )
>       {
>         fieldLength = pGroup->getField( lenField );
>         soh = equalSign + 1 + atol( fieldLength.c_str() );
>       }
>       else if ( isSetField( lenField ) )
>       {
>         fieldLength = getField( lenField );
>         soh = equalSign + 1 + atol( fieldLength.c_str() );
>       }
>     ///****NO LOGIC TO LOOK INTO the HEADER FIELDS****
> --------------END Code Excerpt --------------------------
>
>
> DISCLAIMER:
>
> This e-mail (including any attachments) may contain confidential
information. If you are not the intended recipient, you are hereby
notified that any review, distribution, printing, copying or use of this
e-mail is strictly prohibited. If you have received this e-mail in
error, please notify the sender or Bursa Malaysia immediately and delete
the original message. Opinions, conclusions and other information in
this e-mail that do not relate to the official business of Bursa
Malaysia and/or its group of companies ("Bursa Malaysia Group") shall be
understood as neither given nor endorsed by Bursa Malaysia Group and
Bursa Malaysia Group accepts no responsibility for the same. All
liability arising from or in connection with computer viruses and/or
corrupted e-mails is excluded to the fullest extent permitted by law.
>
>
------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day 
> trial. Simplify your report design, integration and deployment - and
focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july 
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li... 
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers 
>   


DISCLAIMER:

This e-mail (including any attachments) may contain confidential information. If you are not the intended recipient, you are hereby notified that any review, distribution, printing, copying or use of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the sender or Bursa Malaysia immediately and delete the original message. Opinions, conclusions and other information in this e-mail that do not relate to the official business of Bursa Malaysia and/or its group of companies ("Bursa Malaysia Group") shall be understood as neither given nor endorsed by Bursa Malaysia Group and Bursa Malaysia Group accepts no responsibility for the same. All liability arising from or in connection with computer viruses and/or corrupted e-mails is excluded to the fullest extent permitted by law.

Re: [Quickfix-developers] Issue in parsing FIX44 Message - MsgTyp=n

[Dale W. <wi...@oc...>]

Are you passing a data dictionary as well as the string?   QuickFIX 
needs the data dictionary to know that XmlDataLen is the length field 
for XmlData.

Dale

Tan Weng Heng wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi All,
>
> Is this a known issue in QuickFix ?
>
> Whenever I pass the Message class a string with the following C++
> string:
>
> "8=FIX.4.4\0019=73\00135=n\00149=BRKR\00156=INVMGR\00134=235\00152=19980604-07:58:28\001212=14\001213=<R>A=B\001C=D</R>\00110=235\001"
>
> It's unable to extract XmlData(213) properly if the contents contains
> embeded SOH characters, eventhough XmlDataLen(212) has specified its
> length accordingly.
>
> The Message::extractField method seems to only check the availability
> of the "length field" i.e XmlDataLen(212) in the BODY fields, ignoring
> the HEADER fields.
>
> Please correct me if I'm wrong.
>
> Thanks,
> wh
>
> --------------START Code Excerpt--------------------------
>     if ( pDD && pDD->isDataField(field) )
>     {
>       std::string fieldLength;
>       // Assume length field is 1 less.
>       int lenField = field - 1;
>       // Special case for Signature which violates above assumption.
>       if ( field == 89 ) lenField = 93;
>
>       if ( pGroup && pGroup->isSetField( lenField ) )
>       {
>         fieldLength = pGroup->getField( lenField );
>         soh = equalSign + 1 + atol( fieldLength.c_str() );
>       }
>       else if ( isSetField( lenField ) )
>       {
>         fieldLength = getField( lenField );
>         soh = equalSign + 1 + atol( fieldLength.c_str() );
>       }
>     ///****NO LOGIC TO LOOK INTO the HEADER FIELDS****
> --------------END Code Excerpt --------------------------
>
>
> DISCLAIMER:
>
> This e-mail (including any attachments) may contain confidential information. If you are not the intended recipient, you are hereby notified that any review, distribution, printing, copying or use of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the sender or Bursa Malaysia immediately and delete the original message. Opinions, conclusions and other information in this e-mail that do not relate to the official business of Bursa Malaysia and/or its group of companies ("Bursa Malaysia Group") shall be understood as neither given nor endorsed by Bursa Malaysia Group and Bursa Malaysia Group accepts no responsibility for the same. All liability arising from or in connection with computer viruses and/or corrupted e-mails is excluded to the fullest extent permitted by law.
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>   

Re: [Quickfix-developers] Initiator Reconnect?

[Grant B. <gbi...@co...>]

Likely the latter.

On Fri, Nov 20, 2009 at 7:39 AM, Robert Levas
<le...@qe...> wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> Should I assume that no one uses the C++ library or is it that no one has the issue I am having?
>
> Robert Levas
>
> Systems Architect/Developer
>
> QED Financial Systems, Inc.
>
> 10,000 Sagemore
> Marlton, New Jersey 08053 USA
>
> tel       856.797.1200
>
> fax      856.797.9719
>
> email   le...@QE...
>
> This electronic message is intended only for the receipt by, and the personal and confidential use of, the designated recipient(s) named
> above.  If you are not an intended recipient of this electronic message you are hereby notified that any review, dissemination, distribution
> or copy of this message is strictly prohibited.  QED Financial Systems, Inc. reserves all rights to the content of this electronic message,
> which is the exclusive property of QED Financial Systems.
>
>
>
> From: Robert Levas [mailto:le...@qe...]
> Sent: Wednesday, November 11, 2009 3:58 PM
> To: qui...@li...
> Subject: Re: [Quickfix-developers] Initiator Reconnect?
>
>
>
> If anyone is interested I submitted a bug report on this. I also attached two patch files that can be used to fix the issue.  It appears to be fixed on my end with the patch in place.
>
>
>
>                 http://sourceforge.net/tracker/?func=detail&aid=2895449&group_id=37535&atid=1126912
>
>
>
>
>
> Robert Levas
>
> Systems Architect/Developer
>
> QED Financial Systems, Inc.
>
> 10,000 Sagemore
> Marlton, New Jersey 08053 USA
>
> tel       856.797.1200
>
> fax      856.797.9719
>
> email   le...@QE...
>
> This electronic message is intended only for the receipt by, and the personal and confidential use of, the designated recipient(s) named
> above.  If you are not an intended recipient of this electronic message you are hereby notified that any review, dissemination, distribution
> or copy of this message is strictly prohibited.  QED Financial Systems, Inc. reserves all rights to the content of this electronic message,
> which is the exclusive property of QED Financial Systems.
>
>
>
> From: Robert Levas [mailto:le...@qe...]
> Sent: Tuesday, November 10, 2009 3:06 PM
> To: qui...@li...
> Subject: Re: [Quickfix-developers] Initiator Reconnect?
>
>
>
> Apparently this appears to be a bug in how the connection workflow is set up.  What seems to happen is
>
>
>
> 1)      When the Initiator is initialized, a connection for every configured Session is created and placed in the “disconnected” bin
>
> 2)      Later, a SocketInitiator::onStart which invokes the Initiator::connect method
>
> 3)      Each connection in the “disconnected” bin is tested and then passed to the SocketInitiator::doConnect method, which
>
> a.       removes the connection from the “disconnected” bin and places it in the “pending” bin
>
> b.      calls “connect” on the connection
>
> 4)      If the connection connects all is well, however if a connection is not made by some timeout value, SocketInitiator::onTimeout is invoked, which
>
> a.       Check to see a retry is allowed based on the last time it was tried
>
> b.      Attempts to reconnect using the Initiator::connect method (as in item #2, above).
>
>
>
> The issue is that when the connect method is called again, the connection(s) that timed out were never moved from the “pending” bin to the “disconnected” bin and therefore a connection is never retried.  This is because the connect method only works on connections in the “disconnected” bin – which makes sense.
>
>
>
> I will be summiting a bug report as soon as I can get an OpenID and log into the appropriate SourceForge bug tracker.
>
> Robert Levas
>
> Systems Architect/Developer
>
> QED Financial Systems, Inc.
>
> 10,000 Sagemore
> Marlton, New Jersey 08053 USA
>
> tel       856.797.1200
>
> fax      856.797.9719
>
> email   le...@QE...
>
> This electronic message is intended only for the receipt by, and the personal and confidential use of, the designated recipient(s) named
> above.  If you are not an intended recipient of this electronic message you are hereby notified that any review, dissemination, distribution
> or copy of this message is strictly prohibited.  QED Financial Systems, Inc. reserves all rights to the content of this electronic message,
> which is the exclusive property of QED Financial Systems.
>
>
>
> From: Robert Levas [mailto:le...@qe...]
> Sent: Monday, November 09, 2009 1:22 PM
> To: qui...@li...
> Subject: [Quickfix-developers] Initiator Reconnect?
>
>
>
> I am using the C++ library for QuickFIX version 1.12.4.
>
>
>
> I have a FIX::Application implementation that successfully connects to and logs into the executor example application (that comes with the library).  Things seem to be working as expected however if the client starts up after the executor server or the executor server goes down and doesn’t come up within 15 seconds, the client doesn’t attempt to connect to it. I assume that  should expect the client to retry connecting to the server but that is not happening and do I see anything relevant in the docs at http://www.quickfixengine.org/quickfix/doc/html/index.html
>
>
>
> To make things clear here are the two scenarios I quickly outlined:
>
> a.       Client starts before Server
>
> b.      Execute my application
>
> c.       Wait a few seconds
>
> d.      Client application logs “Connecting to localhost on port 5001”
>
> e.      Start executor server (using run_executor_cpp)
>
> f.        Executor starts up successfully
>
> g.       Client application never retries to connect to executor server
>
> h.      Server exists/crashes before Client
>
> i.         Start executor server (using run_executor_cpp)
>
> j.        Executor starts up successfully
>
> k.       Execute my application
>
> l.         Connection is made and login successful
>
> m.    Kill executor server (manually for testing)
>
> n.      Client application gets disconnect and logout event
>
> o.      Client application attempts to reconnect and logs “Connecting to localhost on port 5001”
>
> p.      Wait 15 or so seconds
>
> q.      Start executor server (using run_executor_cpp)
>
> r.        Executor starts up successfully
>
> s.       Client application never retries to connect to executor server
>
>
>
> Should I be doing something in code to get this reconnect behavior working?
>
>
>
> Thanks,
>
> Robert Levas
>
> Systems Architect/Developer
>
> QED Financial Systems, Inc.
>
> 10,000 Sagemore
> Marlton, New Jersey 08053 USA
>
> tel       856.797.1200
>
> fax      856.797.9719
>
> email   le...@QE...
>
> This electronic message is intended only for the receipt by, and the personal and confidential use of, the designated recipient(s) named
> above.  If you are not an intended recipient of this electronic message you are hereby notified that any review, dissemination, distribution
> or copy of this message is strictly prohibited.  QED Financial Systems, Inc. reserves all rights to the content of this electronic message,
> which is the exclusive property of QED Financial Systems.
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] Initiator Reconnect?

[Robert L. <le...@qe...>]

Should I assume that no one uses the C++ library or is it that no one has
the issue I am having?

Robert Levas

Systems Architect/Developer

QED Financial Systems, Inc.

10,000 Sagemore
Marlton, New Jersey 08053 USA

tel       856.797.1200

fax      856.797.9719

email   le...@QE...

This electronic message is intended only for the receipt by, and the
personal and confidential use of, the designated recipient(s) named 
above.  If you are not an intended recipient of this electronic message you
are hereby notified that any review, dissemination, distribution 
or copy of this message is strictly prohibited.  QED Financial Systems, Inc.
reserves all rights to the content of this electronic message,  
which is the exclusive property of QED Financial Systems.

 

From: Robert Levas [mailto:le...@qe...] 
Sent: Wednesday, November 11, 2009 3:58 PM
To: qui...@li...
Subject: Re: [Quickfix-developers] Initiator Reconnect?

 

If anyone is interested I submitted a bug report on this. I also attached
two patch files that can be used to fix the issue.  It appears to be fixed
on my end with the patch in place. 

 

                http://sourceforge.net/tracker/?func=detail
<http://sourceforge.net/tracker/?func=detail&aid=2895449&group_id=37535&atid
=1126912> &aid=2895449&group_id=37535&atid=1126912

 

 

Robert Levas

Systems Architect/Developer

QED Financial Systems, Inc.

10,000 Sagemore
Marlton, New Jersey 08053 USA

tel       856.797.1200

fax      856.797.9719

email   le...@QE...

This electronic message is intended only for the receipt by, and the
personal and confidential use of, the designated recipient(s) named 
above.  If you are not an intended recipient of this electronic message you
are hereby notified that any review, dissemination, distribution 
or copy of this message is strictly prohibited.  QED Financial Systems, Inc.
reserves all rights to the content of this electronic message,  
which is the exclusive property of QED Financial Systems.

 

From: Robert Levas [mailto:le...@qe...] 
Sent: Tuesday, November 10, 2009 3:06 PM
To: qui...@li...
Subject: Re: [Quickfix-developers] Initiator Reconnect?

 

Apparently this appears to be a bug in how the connection workflow is set
up.  What seems to happen is 

 

1)      When the Initiator is initialized, a connection for every configured
Session is created and placed in the "disconnected" bin

2)      Later, a SocketInitiator::onStart which invokes the
Initiator::connect method

3)      Each connection in the "disconnected" bin is tested and then passed
to the SocketInitiator::doConnect method, which 

a.       removes the connection from the "disconnected" bin and places it in
the "pending" bin

b.      calls "connect" on the connection

4)      If the connection connects all is well, however if a connection is
not made by some timeout value, SocketInitiator::onTimeout is invoked, which

a.       Check to see a retry is allowed based on the last time it was tried

b.      Attempts to reconnect using the Initiator::connect method (as in
item #2, above).

 

The issue is that when the connect method is called again, the connection(s)
that timed out were never moved from the "pending" bin to the "disconnected"
bin and therefore a connection is never retried.  This is because the
connect method only works on connections in the "disconnected" bin - which
makes sense.

 

I will be summiting a bug report as soon as I can get an OpenID and log into
the appropriate SourceForge bug tracker.  

Robert Levas

Systems Architect/Developer

QED Financial Systems, Inc.

10,000 Sagemore
Marlton, New Jersey 08053 USA

tel       856.797.1200

fax      856.797.9719

email   le...@QE...

This electronic message is intended only for the receipt by, and the
personal and confidential use of, the designated recipient(s) named 
above.  If you are not an intended recipient of this electronic message you
are hereby notified that any review, dissemination, distribution 
or copy of this message is strictly prohibited.  QED Financial Systems, Inc.
reserves all rights to the content of this electronic message,  
which is the exclusive property of QED Financial Systems.

 

From: Robert Levas [mailto:le...@qe...] 
Sent: Monday, November 09, 2009 1:22 PM
To: qui...@li...
Subject: [Quickfix-developers] Initiator Reconnect?

 

I am using the C++ library for QuickFIX version 1.12.4.  

 

I have a FIX::Application implementation that successfully connects to and
logs into the executor example application (that comes with the library).
Things seem to be working as expected however if the client starts up after
the executor server or the executor server goes down and doesn't come up
within 15 seconds, the client doesn't attempt to connect to it. I assume
that  should expect the client to retry connecting to the server but that is
not happening and do I see anything relevant in the docs at
http://www.quickfixengine.org/quickfix/doc/html/index.html

 

To make things clear here are the two scenarios I quickly outlined:  

a.       Client starts before Server

b.      Execute my application

c.       Wait a few seconds

d.      Client application logs "Connecting to localhost on port 5001"

e.      Start executor server (using run_executor_cpp)

f.        Executor starts up successfully

g.       Client application never retries to connect to executor server

h.      Server exists/crashes before Client

i.         Start executor server (using run_executor_cpp)

j.        Executor starts up successfully

k.       Execute my application

l.         Connection is made and login successful

m.    Kill executor server (manually for testing)

n.      Client application gets disconnect and logout event

o.      Client application attempts to reconnect and logs "Connecting to
localhost on port 5001"

p.      Wait 15 or so seconds

q.      Start executor server (using run_executor_cpp)

r.        Executor starts up successfully

s.       Client application never retries to connect to executor server

 

Should I be doing something in code to get this reconnect behavior working?

 

Thanks,

Robert Levas

Systems Architect/Developer

QED Financial Systems, Inc.

10,000 Sagemore
Marlton, New Jersey 08053 USA

tel       856.797.1200

fax      856.797.9719

email   le...@QE...

This electronic message is intended only for the receipt by, and the
personal and confidential use of, the designated recipient(s) named 
above.  If you are not an intended recipient of this electronic message you
are hereby notified that any review, dissemination, distribution 
or copy of this message is strictly prohibited.  QED Financial Systems, Inc.
reserves all rights to the content of this electronic message,  
which is the exclusive property of QED Financial Systems.

 

[Quickfix-developers] Issue in parsing FIX44 Message - MsgTyp=n

[Tan W. H. <wen...@bu...>]

Hi All,

Is this a known issue in QuickFix ?

Whenever I pass the Message class a string with the following C++
string:

"8=FIX.4.4\0019=73\00135=n\00149=BRKR\00156=INVMGR\00134=235\00152=19980604-07:58:28\001212=14\001213=<R>A=B\001C=D</R>\00110=235\001"

It's unable to extract XmlData(213) properly if the contents contains
embeded SOH characters, eventhough XmlDataLen(212) has specified its
length accordingly.

The Message::extractField method seems to only check the availability
of the "length field" i.e XmlDataLen(212) in the BODY fields, ignoring
the HEADER fields.

Please correct me if I'm wrong.

Thanks,
wh

--------------START Code Excerpt--------------------------
    if ( pDD && pDD->isDataField(field) )
    {
      std::string fieldLength;
      // Assume length field is 1 less.
      int lenField = field - 1;
      // Special case for Signature which violates above assumption.
      if ( field == 89 ) lenField = 93;

      if ( pGroup && pGroup->isSetField( lenField ) )
      {
        fieldLength = pGroup->getField( lenField );
        soh = equalSign + 1 + atol( fieldLength.c_str() );
      }
      else if ( isSetField( lenField ) )
      {
        fieldLength = getField( lenField );
        soh = equalSign + 1 + atol( fieldLength.c_str() );
      }
    ///****NO LOGIC TO LOOK INTO the HEADER FIELDS****
--------------END Code Excerpt --------------------------


DISCLAIMER:

This e-mail (including any attachments) may contain confidential information. If you are not the intended recipient, you are hereby notified that any review, distribution, printing, copying or use of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the sender or Bursa Malaysia immediately and delete the original message. Opinions, conclusions and other information in this e-mail that do not relate to the official business of Bursa Malaysia and/or its group of companies ("Bursa Malaysia Group") shall be understood as neither given nor endorsed by Bursa Malaysia Group and Bursa Malaysia Group accepts no responsibility for the same. All liability arising from or in connection with computer viruses and/or corrupted e-mails is excluded to the fullest extent permitted by law.

Re: [Quickfix-developers] Re play

[Mikhail V. <mve...@gm...>]

Does not make a difference.  The replay happens if the sequence numbers
do not match between the parties.
-  
Regards,

Mikhail Veygman


-----Original Message-----
From: marksasson <ma...@at...>
To: qui...@li...
Subject: [Quickfix-developers] Re play
Date: Thu, 19 Nov 2009 13:13:49 -0800 (PST)

QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html


This is a simple question. Does a replay happen only after application closed
in an orderly fashion with a logout or does it happen also when the
connection is terminated abruptly?

TIA

[Quickfix-developers] Re play

[marksasson <ma...@at...>]

This is a simple question. Does a replay happen only after application closed
in an orderly fashion with a logout or does it happen also when the
connection is terminated abruptly?

TIA
-- 
View this message in context: http://old.nabble.com/Replay-tp26421482p26421482.html
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.

Re: [Quickfix-developers] 4.2 MessageCracker/MessageFactory efficiency

[Igor S. <se...@tb...>]

Hi Rich,

Yes, not a single crash so far. We are using it in production.

I'll put it to QuickFIX GIT hub soon.

Regards,
Igor


-----Original Message-----
From: Rich Holm [mailto:rh...@wo...] 
Sent: Thursday, November 19, 2009 5:52 PM
To: Igor Seleznev
Cc: 'Kenny Stone'; qui...@li...
Subject: Re: [Quickfix-developers] 4.2 MessageCracker/MessageFactory
efficiency



Igor,

Are those releases stable? Would you recommend them for production use?

Cheers,
Rich



Igor Seleznev wrote:
> QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>   
>
> ------------------------------------------------------------------------
>
> Hi,
>
> We made a significant performance improvement of QuickFIX a time ago 
> by replacing std::string objects with C strings - it turned out that 
> std::string from stlport under Solaris was performing allocations 
> through some internal lock, which was a bottle-neck in a such 
> configuration.
>
> Anyway, such a change showed a performance improvement under other 
> platforms (like Linux) where there was no issue with std::string's 
> internal lock. That is, we eventually eliminated most of unnecessary 
> alloc/free which std::string was a reason of.
>
> With GIT it is now easier for us to share these quite big changes, if 
> anyone is interested, of course.
>
> Regards,
>
> Igor
>
> *From:* Kenny Stone [mailto:ks...@co...]
> *Sent:* Thursday, November 19, 2009 3:16 AM
> *To:* qui...@li...
> *Subject:* Re: [Quickfix-developers] 4.2 MessageCracker/MessageFactory 
> efficiency
>
> If you decide to make some changes, we would be interested to see what 
> you find out. There are already a few interesting branches 
> <http://github.com/jaubrey/quickfix/network> on the quickfix github 
> page, one of which is performance related that will probably get 
> merged at some point.
>
> --
> Kenny Stone
> Connamara Systems, LLC
>
> On Wed, Nov 18, 2009 at 5:02 PM, Dale Wilson <wi...@oc... 
> <mailto:wi...@oc...>> wrote:
>
> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi Rick,
>
> Rick Lane wrote:
> > We were recently taking a look through the FIX42_MessageCracker and
> > MessageFactory code (we're using the .NET wrapper for Quickfix) to
> > see if we could make some improvements in our order routing internal
> > latency. We noticed that in both crack() and create()
> >
> > 1) it was doing string comparisons for the message type (when for FIX
> > 4.2 all message types are a single character)
> > 2) it was doing if-statements rather than a switch statement
> > 3) the if-statement for ExecutionReport (which is the most frequent
> > type of message) was 30th in this list!
> >
> > So we figured we could speed this up substantially by:
> >
> > 1) creating a switch() statement (that is constant time) instead of 60
> > or so if-statements and
> > 2) simply switch on the int value of the character (since we know it's
> > only 1 character)
> >
> > However, in practice, we haven't noticed any speed gains and we almost
> > seem to think we're seeing /slower /performance (this is tough to
> > measure because we have to measure in conjunction with WireShark to
> > see how long the message was outside our server (transit latency) and
> > subtract that from the measured time in code).
> >
> > We're wondering if perhaps we aren't doing something correctly at
> > compile time, if anyone has seen these if-statements and thought the
> > same thing we thought, and if anyone has any input in general here.
> >
> > Any help is greatly appreciated.
> I recently spent several months reducing the latency in the QuickFAST
> (not QuickFIX) decoder by two orders of magnitude (i.e. a factor of
> 100) These observations are based on that work:
>
> With the complexity of C++ and the sometimes remarkable ability of
> modern compilers to optimize code, inspecting the C++ source code to
> improve performance is rarely effective. For example, there are some
> compilers that generate exactly the same code for a switch statement and
> a chain of if-else's. As you pointed out, if the possible values are
> sufficiently constrained it is possible to decide which code to execute
> in constant time. Trying to improve performance by rearranging source
> code with a compiler like that can be an exercise in futility.
>
> A similar argument applies to the string comparison. If the comparison
> is inline and the values being compared to are constant literals (like,
> for example FIX tags) then the compiler may very well generate that
> single character comparison for you!
>
> The first step in improving performance should ALWAYS be to measure.
> You need to run a profiler and watch the system under load. If you
> work on a section of the code that is responsible for, say 1% of the
> overall latency, and you find the perfect optimization, the best result
> you could hope for is a 1% improvement in the overall system.
>
> The next step in improving performance is to eliminate the noise.
> Admittedly in the real world you need to be concerned with network
> transmission time and efficiency of the communication stack, etc. but
> if you're trying to improve the latency introduced by QuickFIX, you need
> to get rid of these variables altogether, not just factor them out..
> Otherwise trivial variations in the behavior of the network will totally
> swamp the performance differences you are trying to measure. [Which
> brings up a different point. The payoff in improving the network can
> be far higher than the payoff in improving code at the QuickFIX level,
> but I'll assume that's already done and you still want better 
> performance..]
>
> When the profiler directs your attention to a particular portion of the
> code and you very carefully hand-optimize that section of code to
> squeeze every possible CPU cycle out of it, run the profiler again!
> Don't assume that just because the code looks faster, that it will
> actually run faster. During the QuickFAST optimization process I spent
> a lot of time creating a cache of very commonly used objects that could
> be reused rather than being "new" ed and "deleted" every time. Net
> result -- the performance was worse. I ended up throwing all that work
> away, and trying a different approach.
>
> And lastly, I hope you'll share the results of your efforts. I am very
> interested in what works and what doesn't work when trying to improve
> program performance.
>
> Regards,
>
> Dale
>
> --
> Dale Wilson
> Principal Software Engineer
> Object Computing, Inc. (www.ociweb.com <http://www.ociweb.com>)
> Lead developer for QuickFAST (http:www.quickfast.org 
> <http://www.quickfast.org>)
>
>
>
>
>
>
>
>
>
> >
> > Rick
> >
> > P.S. I'm not sure what the process is (it's been so long now) but if
> > you could add dan...@ti... <mailto:dan...@ti...> 
> <mailto:dan...@ti... <mailto:dan...@ti...>> to
> > the mailing list so it will accept emails from him. Thanks again.
> > ------------------------------------------------------------------------
> >
> > 
>
----------------------------------------------------------------------------
--
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 
> 30-Day
> > trial. Simplify your report design, integration and deployment - and 
> focus on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now. http://p.sf.net/sfu/bobj-july
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Quickfix-developers mailing list
> > Qui...@li... 
> <mailto:Qui...@li...>
> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
>
----------------------------------------------------------------------------
--
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 
> 30-Day
> trial. Simplify your report design, integration and deployment - and 
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li... 
> <mailto:Qui...@li...>
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
> ------------------------------------------------------------------------
>
>
----------------------------------------------------------------------------
--
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day 
> trial. Simplify your report design, integration and deployment - and focus
on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ------------------------------------------------------------------------
>
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers



This message is intended only for the personal and confidential use of the
recipients named above. 
If the reader of this email is not the intended recipient, you have received
this email in error and any review, 
dissemination, distribution or copying is strictly prohibited. If you have
received this email in error, 
please notify the sender immediately by return email and permanently delete
the copy you received. 

This message is provided for informational purposes and should not be
construed as a solicitation or offer 
to buy or sell any securities or related financial instruments. Wolverine is
not responsible for any 
recommendation, solicitation, offer or agreement or any information about
any transaction, customer account 
or account activity that may be attached to or contained in this
communication. Wolverine accepts no 
liability for any content contained in the email, or any errors or omissions
arising as a result of 
email transmission. Any opinions contained in this email constitute the
sender's best judgment at this 
time and are subject to change without notice.

Re: [Quickfix-developers] 4.2 MessageCracker/MessageFactory efficiency

[Rich H. <rh...@wo...>]

Igor,

Are those releases stable? Would you recommend them for production use?

Cheers,
Rich



Igor Seleznev wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>   
>
> ------------------------------------------------------------------------
>
> Hi,
>
> We made a significant performance improvement of QuickFIX a time ago 
> by replacing std::string objects with C strings – it turned out that 
> std::string from stlport under Solaris was performing allocations 
> through some internal lock, which was a bottle-neck in a such 
> configuration.
>
> Anyway, such a change showed a performance improvement under other 
> platforms (like Linux) where there was no issue with std::string’s 
> internal lock. That is, we eventually eliminated most of unnecessary 
> alloc/free which std::string was a reason of.
>
> With GIT it is now easier for us to share these quite big changes, if 
> anyone is interested, of course.
>
> Regards,
>
> Igor
>
> *From:* Kenny Stone [mailto:ks...@co...]
> *Sent:* Thursday, November 19, 2009 3:16 AM
> *To:* qui...@li...
> *Subject:* Re: [Quickfix-developers] 4.2 MessageCracker/MessageFactory 
> efficiency
>
> If you decide to make some changes, we would be interested to see what 
> you find out. There are already a few interesting branches 
> <http://github.com/jaubrey/quickfix/network> on the quickfix github 
> page, one of which is performance related that will probably get 
> merged at some point.
>
> --
> Kenny Stone
> Connamara Systems, LLC
>
> On Wed, Nov 18, 2009 at 5:02 PM, Dale Wilson <wi...@oc... 
> <mailto:wi...@oc...>> wrote:
>
> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi Rick,
>
> Rick Lane wrote:
> > We were recently taking a look through the FIX42_MessageCracker and
> > MessageFactory code (we're using the .NET wrapper for Quickfix) to
> > see if we could make some improvements in our order routing internal
> > latency. We noticed that in both crack() and create()
> >
> > 1) it was doing string comparisons for the message type (when for FIX
> > 4.2 all message types are a single character)
> > 2) it was doing if-statements rather than a switch statement
> > 3) the if-statement for ExecutionReport (which is the most frequent
> > type of message) was 30th in this list!
> >
> > So we figured we could speed this up substantially by:
> >
> > 1) creating a switch() statement (that is constant time) instead of 60
> > or so if-statements and
> > 2) simply switch on the int value of the character (since we know it's
> > only 1 character)
> >
> > However, in practice, we haven't noticed any speed gains and we almost
> > seem to think we're seeing /slower /performance (this is tough to
> > measure because we have to measure in conjunction with WireShark to
> > see how long the message was outside our server (transit latency) and
> > subtract that from the measured time in code).
> >
> > We're wondering if perhaps we aren't doing something correctly at
> > compile time, if anyone has seen these if-statements and thought the
> > same thing we thought, and if anyone has any input in general here.
> >
> > Any help is greatly appreciated.
> I recently spent several months reducing the latency in the QuickFAST
> (not QuickFIX) decoder by two orders of magnitude (i.e. a factor of
> 100) These observations are based on that work:
>
> With the complexity of C++ and the sometimes remarkable ability of
> modern compilers to optimize code, inspecting the C++ source code to
> improve performance is rarely effective. For example, there are some
> compilers that generate exactly the same code for a switch statement and
> a chain of if-else's. As you pointed out, if the possible values are
> sufficiently constrained it is possible to decide which code to execute
> in constant time. Trying to improve performance by rearranging source
> code with a compiler like that can be an exercise in futility.
>
> A similar argument applies to the string comparison. If the comparison
> is inline and the values being compared to are constant literals (like,
> for example FIX tags) then the compiler may very well generate that
> single character comparison for you!
>
> The first step in improving performance should ALWAYS be to measure.
> You need to run a profiler and watch the system under load. If you
> work on a section of the code that is responsible for, say 1% of the
> overall latency, and you find the perfect optimization, the best result
> you could hope for is a 1% improvement in the overall system.
>
> The next step in improving performance is to eliminate the noise.
> Admittedly in the real world you need to be concerned with network
> transmission time and efficiency of the communication stack, etc. but
> if you're trying to improve the latency introduced by QuickFIX, you need
> to get rid of these variables altogether, not just factor them out..
> Otherwise trivial variations in the behavior of the network will totally
> swamp the performance differences you are trying to measure. [Which
> brings up a different point. The payoff in improving the network can
> be far higher than the payoff in improving code at the QuickFIX level,
> but I'll assume that's already done and you still want better 
> performance..]
>
> When the profiler directs your attention to a particular portion of the
> code and you very carefully hand-optimize that section of code to
> squeeze every possible CPU cycle out of it, run the profiler again!
> Don't assume that just because the code looks faster, that it will
> actually run faster. During the QuickFAST optimization process I spent
> a lot of time creating a cache of very commonly used objects that could
> be reused rather than being "new" ed and "deleted" every time. Net
> result -- the performance was worse. I ended up throwing all that work
> away, and trying a different approach.
>
> And lastly, I hope you'll share the results of your efforts. I am very
> interested in what works and what doesn't work when trying to improve
> program performance.
>
> Regards,
>
> Dale
>
> --
> Dale Wilson
> Principal Software Engineer
> Object Computing, Inc. (www.ociweb.com <http://www.ociweb.com>)
> Lead developer for QuickFAST (http:www.quickfast.org 
> <http://www.quickfast.org>)
>
>
>
>
>
>
>
>
>
> >
> > Rick
> >
> > P.S. I'm not sure what the process is (it's been so long now) but if
> > you could add dan...@ti... <mailto:dan...@ti...> 
> <mailto:dan...@ti... <mailto:dan...@ti...>> to
> > the mailing list so it will accept emails from him. Thanks again.
> > ------------------------------------------------------------------------
> >
> > 
> ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 
> 30-Day
> > trial. Simplify your report design, integration and deployment - and 
> focus on
> > what you do best, core application coding. Discover what's new with
> > Crystal Reports now. http://p.sf.net/sfu/bobj-july
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Quickfix-developers mailing list
> > Qui...@li... 
> <mailto:Qui...@li...>
> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 
> 30-Day
> trial. Simplify your report design, integration and deployment - and 
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li... 
> <mailto:Qui...@li...>
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ------------------------------------------------------------------------
>
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers



This message is intended only for the personal and confidential use of the recipients named above. 
If the reader of this email is not the intended recipient, you have received this email in error and any review, 
dissemination, distribution or copying is strictly prohibited. If you have received this email in error, 
please notify the sender immediately by return email and permanently delete the copy you received. 

This message is provided for informational purposes and should not be construed as a solicitation or offer 
to buy or sell any securities or related financial instruments. Wolverine is not responsible for any 
recommendation, solicitation, offer or agreement or any information about any transaction, customer account 
or account activity that may be attached to or contained in this communication. Wolverine accepts no 
liability for any content contained in the email, or any errors or omissions arising as a result of 
email transmission. Any opinions contained in this email constitute the sender's best judgment at this 
time and are subject to change without notice.

Re: [Quickfix-developers] 4.2 MessageCracker/MessageFactory efficiency

[Igor S. <se...@tb...>]

Hi,

 

We made a significant performance improvement of QuickFIX a time ago by
replacing std::string objects with C strings - it turned out that
std::string from stlport under Solaris was performing allocations through
some internal lock, which was a bottle-neck in a such configuration.

 

Anyway, such a change showed a performance improvement under other platforms
(like Linux) where there was no issue with std::string's internal lock. That
is, we eventually eliminated most of unnecessary alloc/free which
std::string was a reason of.

 

With GIT it is now easier for us to share these quite big changes, if anyone
is interested, of course.

 

Regards,

Igor

 

 

From: Kenny Stone [mailto:ks...@co...] 
Sent: Thursday, November 19, 2009 3:16 AM
To: qui...@li...
Subject: Re: [Quickfix-developers] 4.2 MessageCracker/MessageFactory
efficiency

 

If you decide to make some changes, we would be interested to see what you
find out.  There are already a few interesting branches
<http://github.com/jaubrey/quickfix/network>  on the quickfix github page,
one of which is performance related that will probably get merged at some
point.

--
Kenny Stone
Connamara Systems, LLC



On Wed, Nov 18, 2009 at 5:02 PM, Dale Wilson <wi...@oc...> wrote:

QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Hi Rick,

Rick Lane wrote:
> We were recently taking a look through the FIX42_MessageCracker and
> MessageFactory code (we're using the .NET wrapper for Quickfix)  to
> see if we could make some improvements in our order routing internal
> latency.  We noticed that in both crack() and create()
>
> 1) it was doing string comparisons for the message type (when for FIX
> 4.2 all message types are a single character)
> 2) it was doing if-statements rather than a switch statement
> 3) the if-statement for ExecutionReport (which is the most frequent
> type of message) was 30th in this list!
>
> So we figured we could speed this up substantially by:
>
> 1) creating a switch() statement (that is constant time) instead of 60
> or so if-statements and
> 2) simply switch on the int value of the character (since we know it's
> only 1 character)
>
> However, in practice, we haven't noticed any speed gains and we almost
> seem to think we're seeing /slower /performance (this is tough to
> measure because we have to measure in conjunction with WireShark to
> see how long the message was outside our server (transit latency) and
> subtract that from the measured time in code).
>
> We're wondering if perhaps we aren't doing something correctly at
> compile time, if anyone has seen these if-statements and thought the
> same thing we thought, and if anyone has any input in general here.
>
> Any help is greatly appreciated.
I recently spent several months reducing the latency in the QuickFAST
(not QuickFIX) decoder by two orders of magnitude (i.e. a factor of
100)  These observations are based on that work:

With the complexity of C++ and the sometimes remarkable ability of
modern compilers to optimize code, inspecting the C++ source code to
improve performance is rarely effective.  For example, there are some
compilers that generate exactly the same code for a switch statement and
a chain of if-else's. As you pointed out, if the possible values are
sufficiently constrained it is possible to decide which code to execute
in constant time.   Trying to improve performance by rearranging source
code with a compiler like that can be an exercise in futility.

A similar argument applies to the string comparison.  If the comparison
is inline and the values being compared to are constant literals (like,
for example FIX tags) then the compiler may very well generate that
single character comparison for you!

The first step in improving performance should ALWAYS be to measure.
You need to run a profiler and watch the system under load.   If you
work on a section of the code that is responsible for, say 1% of the
overall latency, and you find the perfect optimization, the best result
you could hope for is a 1% improvement in the overall system.

The next step in improving performance is to eliminate the noise.
Admittedly in the real world you need to be concerned with network
transmission time and efficiency of the communication stack, etc.  but
if you're trying to improve the latency introduced by QuickFIX, you need
to get rid of these variables altogether, not just factor them out..
Otherwise trivial variations in the behavior of the network will totally
swamp the performance differences you are trying to measure.   [Which
brings up a different point.   The payoff in improving the network can
be far higher than the payoff in improving code at the QuickFIX level,
but I'll assume that's already done and you still want better performance..]

When the profiler directs your attention to a particular portion of the
code and you very carefully hand-optimize that section of code to
squeeze every possible CPU cycle out of it, run the profiler again!
Don't assume that just because the code looks faster, that it will
actually run faster.  During the QuickFAST optimization process I spent
a lot of time creating a cache of very commonly used objects that could
be reused rather than being "new" ed and "deleted" every time.  Net
result -- the performance was worse.  I ended up throwing all that work
away, and trying a different approach.

And lastly, I hope you'll share the results of your efforts.  I am very
interested in what works and what doesn't work when trying to improve
program performance.

Regards,

Dale

--
Dale Wilson
Principal Software Engineer
Object Computing, Inc. (www.ociweb.com)
Lead developer for QuickFAST (http:www.quickfast.org)









>
> Rick
>
> P.S.  I'm not sure what the process is (it's been so long now) but if
> you could add dan...@ti... <mailto:dan...@ti...> to
> the mailing list so it will accept emails from him.  Thanks again.
> ------------------------------------------------------------------------
>
>
----------------------------------------------------------------------------
--
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day
> trial. Simplify your report design, integration and deployment - and focus
on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ------------------------------------------------------------------------
>
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers


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