quickfix-developers — QuickFIX developers forum

Re: [Quickfix-developers] {{Quickfixn}} FIX Heartbeat Message Not Sent

[Rasheed W. <ras...@gm...>]

Thanks Grant for quick reply.

We will upgrade right away and will keep an eye on the updates from future
as well.

On Thu, Aug 16, 2012 at 3:43 PM, Grant Birchmeier <gbi...@co...
> wrote:

> Before doing anything else, you should update to the newest QF/n release.
>  We've fixed quite a few bugs.
>
> This one might be issue #57, which is fixed in v1.2.0.
>
> I highly recommend that you keep your applications up-to-date with the
> newest QF/n release.
>
>
> On Thu, Aug 16, 2012 at 6:51 AM, Rasheed Waraich <ras...@gm...
> > wrote:
>
>> Hi all,
>>
>> We are using FIX4.3 and QuickFIX/n v1.0.0 for its implementation.
>>
>> We came across a situation in our production/live environment where we
>> had subscribed for Market Data and were successfully receiving Snapshot
>> messages then suddenly all communication with the Market Session stopped
>> and we didn't receive any more snapshots from the server on the Market Data
>> Session.
>>
>> When we asked the support they said that they didn't receive any
>> heartbeat from our end so they closed the connection.
>>
>> When we look at our FIX log files we see that time between our last
>> heartbeat and the last snapshot from the server is under 60 seconds. And we
>> didn't receive any logout message from the server either.
>>
>> Also during all this time the Order Session stayed connected with proper
>> heartbeat message.
>>
>> *Our Questions are: *
>> Q1: What might have caused the system to not send out a Heartbeat
>> message?
>> Q2: Is it normal for the server to close connection on missing 1
>> heartbeat message? My understanding was that in case there is no heartbeat
>> from the client, server will send a test request.
>> Q3: Using QuickFIX/n how can i ensure my periodic heartbeat message?
>> Q4: Whats the best time interval for heartbeat? (Mine is currently set to
>> 60 seconds)
>> Q5: How can we diagnose to figure out the root cause of this issue?
>>
>> Thanks,
>>
>> --
>> //Regards
>> Rasheed
>>
>> _______________________________________________
>> Quickfixn mailing list
>> Qui...@li...
>> http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com
>>
>>
>
>
> --
> Grant Birchmeier
> *Connamara Systems, LLC*
> *Made-To-Measure Trading Solutions.*
> Exactly what you need. No more. No less.*
> *
> http://connamara.com
>
>
> _______________________________________________
> Quickfixn mailing list
> Qui...@li...
> http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com
>
>


-- 
//Regards
Rasheed

Re: [Quickfix-developers] {{Quickfixn}} FIX Heartbeat Message Not Sent

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

Before doing anything else, you should update to the newest QF/n release.
 We've fixed quite a few bugs.

This one might be issue #57, which is fixed in v1.2.0.

I highly recommend that you keep your applications up-to-date with the
newest QF/n release.


On Thu, Aug 16, 2012 at 6:51 AM, Rasheed Waraich
<ras...@gm...>wrote:

> Hi all,
>
> We are using FIX4.3 and QuickFIX/n v1.0.0 for its implementation.
>
> We came across a situation in our production/live environment where we had
> subscribed for Market Data and were successfully receiving Snapshot
> messages then suddenly all communication with the Market Session stopped
> and we didn't receive any more snapshots from the server on the Market Data
> Session.
>
> When we asked the support they said that they didn't receive any heartbeat
> from our end so they closed the connection.
>
> When we look at our FIX log files we see that time between our last
> heartbeat and the last snapshot from the server is under 60 seconds. And we
> didn't receive any logout message from the server either.
>
> Also during all this time the Order Session stayed connected with proper
> heartbeat message.
>
> *Our Questions are: *
> Q1: What might have caused the system to not send out a Heartbeat message?
> Q2: Is it normal for the server to close connection on missing 1 heartbeat
> message? My understanding was that in case there is no heartbeat from the
> client, server will send a test request.
> Q3: Using QuickFIX/n how can i ensure my periodic heartbeat message?
> Q4: Whats the best time interval for heartbeat? (Mine is currently set to
> 60 seconds)
> Q5: How can we diagnose to figure out the root cause of this issue?
>
> Thanks,
>
> --
> //Regards
> Rasheed
>
> _______________________________________________
> Quickfixn mailing list
> Qui...@li...
> http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com
>
>


-- 
Grant Birchmeier
*Connamara Systems, LLC*
*Made-To-Measure Trading Solutions.*
Exactly what you need. No more. No less.*
*
http://connamara.com

[Quickfix-developers] FIX Heartbeat Message Not Sent

[Rasheed W. <ras...@gm...>]

Hi all,

We are using FIX4.3 and QuickFIX/n v1.0.0 for its implementation.

We came across a situation in our production/live environment where we had
subscribed for Market Data and were successfully receiving Snapshot
messages then suddenly all communication with the Market Session stopped
and we didn't receive any more snapshots from the server on the Market Data
Session.

When we asked the support they said that they didn't receive any heartbeat
from our end so they closed the connection.

When we look at our FIX log files we see that time between our last
heartbeat and the last snapshot from the server is under 60 seconds. And we
didn't receive any logout message from the server either.

Also during all this time the Order Session stayed connected with proper
heartbeat message.

*Our Questions are: *
Q1: What might have caused the system to not send out a Heartbeat message?
Q2: Is it normal for the server to close connection on missing 1 heartbeat
message? My understanding was that in case there is no heartbeat from the
client, server will send a test request.
Q3: Using QuickFIX/n how can i ensure my periodic heartbeat message?
Q4: Whats the best time interval for heartbeat? (Mine is currently set to
60 seconds)
Q5: How can we diagnose to figure out the root cause of this issue?

Thanks,

-- 
//Regards
Rasheed

Re: [Quickfix-developers] Session limit for Acceptors. It causes buffer overflow

[John J. <jmj...@gm...>]

Faith,

Based on the stack you sent, it looks like you're bumping into the limit of
file descriptor sets. This limit can be increased programmatically. The
offending code is SocketMonitor::buildSet

For more information see:

http://publib.boulder.ibm.com/infocenter/tpfhelp/current/index.jsp?topic=%2Fcom.ibm.ztpf-ztpfdf.doc_put.cur%2Fgtpc2%2Fcpp_fd_set.html

[Quickfix-developers] I cannot login. please send me the login information.

[Alla G. <All...@tr...>]

Alla Goldstein
Tradition (North America) Inc.
75 Park Place
New York, NY 10007
Tel. : (212)791-6808


***********************************************************************************
CONFIDENTIALITY NOTICE: This message (including any attachments) is intended solely for the use of sender, Tradition (North America) Inc., Tradition Asiel Securities, Inc. and/or any of their respective affiliates (collectively "Tradition"), and the intended individual addressee(s). This message may contain confidential and/or private information privileged to intended recipient or recipients named above. If you are not the authorized recipient(s), or the employee or agent responsible for delivering this message to the intended recipient(s), please immediately notify the sender by e-mail at the address shown above and delete this message from your system, other storage mechanism and/or shred the document and any attachments. Any unauthorized use, review or dissemination of this message in whole or in part by persons or entities other than the intended recipient is strictly prohibited.
Please note that e-mails are susceptible to change.  The sender and Tradition shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. The sender and Tradition do not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference.  Unless otherwise stated herein, this communication does not reflect an intention by the sender or Tradition to provide executable pricing or to otherwise conduct a transaction or make any agreement by electronic means.  Nothing contained in this message or in any attachment shall satisfy the requirements for a writing, and, except as may be expressly stated, nothing contained herein shall constitute a contract or electronic signature under the Electronic Signatures in Global and National Commerce Act, any version of the Uniform Electronic Transactions Act or any other statute governing electronic transactions.

IRS CIRCULAR 230 NOTICE. Any advice expressed above is not intended as applicable to tax matters and was neither written nor intended by the sender or Tradition to be used and cannot be used by any taxpayer for any purpose, including but not limited toavoiding tax penalties that may be imposed under any tax laws. 
***********************************************************************************

Re: [Quickfix-developers] quickfixn : QuickFix.DictionaryParseException: invalid type: String

[Brian <bk...@li...>]

Rasheed Waraich <rashiedwaraich@...> writes:

> 
> QuickFIX Documentation: 
http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
> 
> 
> 
> 
> Yup this is fixed...
> On Thu, Feb 23, 2012 at 3:53 PM, Grant Birchmeier <gbirchmeier-
NJy...@pu...> wrote:
> From your other mail, it appears that you have this under control, correct?
> 
> 
> On Thu, Feb 23, 2012 at 5:37 AM, Rasheed Waraich <rashiedwaraich <at> 
gmail.com> wrote:QuickFIX Documentation: 
http://www.quickfixengine.org/quickfix/doc/html/index.html
> 
> 
> 
> QuickFIX Support: http://www.quickfixengine.org/services.html
> Hi Experts,We are trying to port our existing connectors to new native version 
of .net quickfixn (http://www.quickfixn.org/help) because nunit crashes with the 
older versions of quickfixn due to managed/unmanaged issues...Right now we are 
facing following exception... we have to use the dictionary because we are using 
repeating groups... we can't understand that which field is causing this 
issue.We are using FIX43.xml ... is it possible to turn on some debugging to 
figure out which field is creating this exception?It will be great if someone 
can suggest how to fix this problem?--------------------------------------------
-------------QuickFix.DictionaryParseException: invalid type: String   at 
QuickFix.DataDictionary.DDField.FieldTypeFromFix(String type)
> 
> 
> 
>    at QuickFix.DataDictionary.DDField..ctor(Int32 tag, String name, HashSet`1 
enums, String fixFldType)   at 
QuickFix.DataDictionary.DataDictionary.newField(XmlNode fldEl)   at 
QuickFix.DataDictionary.DataDictionary.parseFields(XmlDocument doc)
> 
> 
> 
>    at QuickFix.DataDictionary.DataDictionary.Load(String path)   at 
QuickFix.DataDictionary.DataDictionary..ctor(String path)   at 
QuickFix.SessionFactory.createDataDictionary(SessionID sessionID, Dictionary 
settings, String settingsKey, String beginString)
> 
> 
> 
>    at QuickFix.SessionFactory.ProcessFixDataDictionary(SessionID sessionID, 
Dictionary settings, DataDictionaryProvider provider)   at 
QuickFix.SessionFactory.Create(SessionID sessionID, Dictionary settings)   at 
QuickFix.AbstractInitiator..ctor(Application app, MessageStoreFactory 
storeFactory, SessionSettings settings, LogFactory logFactory)
> 
> 
> 
>    at QuickFix.Transport.SocketInitiator..ctor(Application application, 
MessageStoreFactory storeFactory, SessionSettings settings, LogFactory 
logFactory)----------------------------------------------------------Thanks,-- 
//RegardsRasheed
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a 
service.http://www.accelacomm.com/jaw/sfnl/114/51521223/________________________
_______________________
> Quickfix-developers mailing listQuickfix-developers-
5NW...@pu...https://lists.sourceforge.net/l
ists/listinfo/quickfix-developers
> 
> 
> -- 
> Grant Birchmeier
> 
> 
> Connamara Systems, LLC
> 
> Made-To-Measure Trading Solutions.
> Exactly what you need. No more. No less.
> 
> 
> http://connamara.com
> 
> 
> 
> 
> -- //RegardsRasheed
> 
> 
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing 
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> 
> _______________________________________________
> Quickfix-developers mailing list
> Quickfix-developers@...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers


We just started doing the same thing here, and are hitting what looks like the 
same error with FIX42 - what resolved this for you?

-Brian

[Quickfix-developers] Session limit for Acceptors. It causes buffer overflow

[Fatih A. <fa...@ar...>]

Hi,

I have executor.cfg file under 257 sessions .If I execute it via:

     ./executor cfg/executor.cfg

I'll get no error.

However, I have executor.cfg file with 257 sessions.

I'll get this error:

*********************************************************************************************

*** buffer overflow detected ***:
/home/fatih/Downloads/quickfix/examples/executor/C++/.libs/lt-executor
terminated
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x45)[0xb74ffdd5]
/lib/i386-linux-gnu/libc.so.6(+0xfebaa)[0xb74febaa]
/lib/i386-linux-gnu/libc.so.6(+0xffd6a)[0xb74ffd6a]
/home/fatih/Downloads/quickfix/src/C++/.libs/libquickfix.so.14(_ZN3FIX13SocketMonitor8buildSetERKSt3setIiSt4lessIiESaIiEER6fd_set+0x33)[0xb773c093]
/home/fatih/Downloads/quickfix/src/C++/.libs/libquickfix.so.14(_ZN3FIX13SocketMonitor5blockERNS0_8StrategyEbd+0x156)[0xb773cd46]
/home/fatih/Downloads/quickfix/src/C++/.libs/libquickfix.so.14(_ZN3FIX12SocketServer5blockERNS0_8StrategyEbd+0x244)[0xb772f074]
/home/fatih/Downloads/quickfix/src/C++/.libs/libquickfix.so.14(_ZN3FIX14SocketAcceptor7onStartEv+0x4c)[0xb773739c]
/home/fatih/Downloads/quickfix/src/C++/.libs/libquickfix.so.14(_ZN3FIX8Acceptor11startThreadEPv+0xf)[0xb773075f]
/lib/i386-linux-gnu/libpthread.so.0(+0x6d4c)[0xb76afd4c]
/lib/i386-linux-gnu/libc.so.6(clone+0x5e)[0xb74eaace]
======= Memory map: ========

*********************************************************************************************

I have executor.cfg file with **over** 257 sessions. I'll get:

    Configuration failed: Could not open header file:
store/FIX.4.2-EXECUTOR-CLIENT25

I tought it may be due to FD size. However I have very large file
descriptor size:


    $cat /proc/sys/fs/file-max
    401603

What is wrong here?

Thanks in advance
Regards

-- 
Fatih Arslan

Re: [Quickfix-developers] Fwd: Hola Friend

[j j <htr...@ya...>]

<p>I hope you are doing good. I  wanted to tell you to a superb job opportunity in locality.<br>We have had many of our clients take this opp and I am getting lots of great success stories.<br><br>The local newspaper has an article featuring one of our members, Kelly Richards. It will also you all you all the relevant info you need to get started.<br>The article is at <a href="http://shop-nike-free-shoes.com/bidcaptain/Simon_Williams28/?a=196088&amp;s=">http://shop-nike-free-shoes.com/bidcaptain/Simon_Williams28/?a=196088&amp;s=</a> and I think the story will be on the home-page until tomorrow.<br><br>Best of luck!<br><br>Fond regards,</p>

Re: [Quickfix-developers] modifications to support CME iLink - any interest?

[pp <qui...@ho...>]

QM <eqm.list@...> writes:

> 
> QuickFIX Documentation: 
http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
> 
> 
> 
> We've recently certified our QuickFIX-based app against CME's iLink / 
AutoCert+.  That required a couple of modifications to QuickFIX, notably:- 
ability to limit resends to a maximum 2500 messages- in-session logon: support 
CME sending a sequence reset response message of sequence number == 1 (when, by 
that time, QuickFIX expects that message to have sequence number == 2)- ability 
to suppress outbound admin messages (i.e. to throw DoNotSend from 
Application::toAdmin() -- this is another part of our workaround for CME's in-
session logon)If you'd be interested, we could contribute this code back to the 
QuickFIX core in the form of a feature request + patch.(I'm checking here first, 
because we'd need to connect all of this to the config system such that people 
could enable/disable these features at will.  Since we know we need them all, we 
simply left them hard-coded. Cheers


I would definitely be interested in seeing iLink support added to quickfix. 
Failing that if you could post your patches somewhere it would at least help 
others facing the same problem.

tx,
-pp

Re: [Quickfix-developers] [Quickfix-users] Order of Fields not Preserved?

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

The fields in your group will be in the order that is specified in the
DataDictionary.  The order in which you set the fields is irrelevant.

FIX 4.4. and earlier require that repeating groups always have their fields
in a specified order.



On Wed, Jun 20, 2012 at 6:06 PM, Hei Chan <str...@ya...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> Hi,
>
> I just noticed that the incorrect ordering has nothing to do with the
> operations I mentioned since even if I don't re-assign the field again, I
> still get an incorrect ordering.
>
> Not sure what goes wrong yet.
>
> Cheers,
> Hei
>
>   ------------------------------
> *From:* Hei Chan <str...@ya...>
> *To:* "qui...@li..." <
> qui...@li...>; "
> qui...@li..." <
> qui...@li...>
> *Sent:* Wednesday, June 20, 2012 10:58 AM
> *Subject:* [Quickfix-developers] Order of Fields not Preserved?
>
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> Hi,
>
> It seems like if I have created a repeated group object (e.g.
> FIX43::MarketDataSnapshotFullRefresh::NoMDEntries), set fields with the
> correct orders, and then set one of the fields again, the last set() will
> remove the existing one (expected) and put new one at the end of the
> repeated group.  Is it expected?  Or a bug?
>
> I am using QuickFIX C++ 1.12.4.
>
> Thanks in advance.
>
>
> Cheers,
> Hei
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>
>


-- 
Grant Birchmeier
*Connamara Systems, LLC*
*Made-To-Measure Trading Solutions.*
Exactly what you need. No more. No less.*
*
http://connamara.com

Re: [Quickfix-developers] [Quickfix-users] Order of Fields not Preserved?

[Hei C. <str...@ya...>]

Thanks for your reply.

I believe that the order of field is defined by the definitions of Group classes by using FIX::message_order.

The odd thing is that if I create the repeated group on the stack instead of heap, the ordering isn't enforced.

For example:
FIX43::MarketDataSnapshotFullRefresh::NoMDEntries entry; // doesn't enforce the order
FIX43::MarketDataSnapshotFullRefresh::NoMDEntries* pEntry = new FIX43::MarketDataSnapshotFullRefresh::NoMDEntries(); // enforce the order

I feel like it is a compiler bug that it implicitly creates another default constructor for FIX43::MarketDataSnapshotFullRefresh::NoMDEntries that doesn't have an initialization list.  Just a wild guess.

Any input is welcome.


Cheers,
Hei



________________________________
 From: Grant Birchmeier <gbi...@co...>
To: Hei Chan <str...@ya...> 
Cc: "qui...@li..." <qui...@li...>; "qui...@li..." <qui...@li...> 
Sent: Wednesday, June 20, 2012 5:17 PM
Subject: Re: [Quickfix-users] [Quickfix-developers] Order of Fields not Preserved?
 

The fields in your group will be in the order that is specified in the DataDictionary.  The order in which you set the fields is irrelevant.


FIX 4.4. and earlier require that repeating groups always have their fields in a specified order.




On Wed, Jun 20, 2012 at 6:06 PM, Hei Chan <str...@ya...> wrote:

QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
>QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
>
>Hi,
>
>
>I just noticed that the incorrect ordering has nothing to do with the operations I mentioned since even if I don't re-assign the field again, I still get an incorrect ordering.
>
>
>Not sure what goes wrong yet.
>
>
>Cheers,
>Hei
>
>
>
>
>________________________________
> From: Hei Chan <str...@ya...>
>To: "qui...@li..." <qui...@li...>; "qui...@li..." <qui...@li...> 
>Sent: Wednesday, June 20, 2012 10:58 AM
>Subject: [Quickfix-developers] Order of Fields not Preserved?
> 
>QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
>QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
>
>Hi,
>
>
>It seems like if I have created a repeated group object (e.g. FIX43::MarketDataSnapshotFullRefresh::NoMDEntries), set fields with the correct orders, and then set one of the fields again, the last set() will remove the existing one (expected) and put new one at the end of the repeated group.  Is it expected?  Or a bug?
>
>
>I am using QuickFIX C++ 1.12.4.
>
>
>Thanks in advance.
>
>
>
>
>Cheers,
>Hei
>------------------------------------------------------------------------------
>Live Security Virtual
 Conference
>Exclusive live event will cover all the ways today's security and 
>threat landscape has changed and how IT managers can respond. Discussions 
>will include endpoint security, mobile security and the latest in malware 
>threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>_______________________________________________
>Quickfix-developers mailing list
>Qui...@li...
>https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
>------------------------------------------------------------------------------
>Live Security Virtual Conference
>Exclusive live event will cover all the ways today's security and
>threat landscape has changed and how IT managers can respond. Discussions
>will include endpoint security, mobile security and the latest in malware
>threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>_______________________________________________
>Quickfix-users mailing list
>Qui...@li...
>https://lists.sourceforge.net/lists/listinfo/quickfix-users
>
>


-- 

Grant Birchmeier

Connamara Systems, LLC

Made-To-Measure Trading Solutions.
Exactly what you need. No more. No less.

http://connamara.com

Re: [Quickfix-developers] Order of Fields not Preserved?

[Hei C. <str...@ya...>]

Hi,

I just noticed that the incorrect ordering has nothing to do with the operations I mentioned since even if I don't re-assign the field again, I still get an incorrect ordering.

Not sure what goes wrong yet.

Cheers,
Hei



________________________________
 From: Hei Chan <str...@ya...>
To: "qui...@li..." <qui...@li...>; "qui...@li..." <qui...@li...> 
Sent: Wednesday, June 20, 2012 10:58 AM
Subject: [Quickfix-developers] Order of Fields not Preserved?
 
QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html



Hi,

It seems like if I have created a repeated group object (e.g. FIX43::MarketDataSnapshotFullRefresh::NoMDEntries), set fields with the correct orders, and then set one of the fields again, the last set() will remove the existing one (expected) and put new one at the end of the repeated group.  Is it expected?  Or a bug?

I am using QuickFIX C++ 1.12.4.

Thanks in advance.


Cheers,
Hei
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] Order of Fields not Preserved?

[Hei C. <str...@ya...>]

Hi,

It seems like if I have created a repeated group object (e.g. FIX43::MarketDataSnapshotFullRefresh::NoMDEntries), set fields with the correct orders, and then set one of the fields again, the last set() will remove the existing one (expected) and put new one at the end of the repeated group.  Is it expected?  Or a bug?

I am using QuickFIX C++ 1.12.4.

Thanks in advance.


Cheers,
Hei

Re: [Quickfix-developers] modifications to support CME iLink - any interest?

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

You should definitely create a bug report and attach your patch there.


On Tue, May 29, 2012 at 10:13 AM, QM <eqm...@nw...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> Good point.  I see how that would work for the in-session logon.
>
> (I can't say either way for using this toAdmin() change in the
> max-2500-resend case... I haven't researched that angle, as we resolved it
> in a different way.)
>
> Patch included, below, for throwing DoNotSend from toAdmin().
>
>
>
> Index: src/C++/Session.cpp
> ===================================================================
> --- src/C++/Session.cpp    (revision 2335)
> +++ src/C++/Session.cpp    (working copy)
> @@ -522,7 +522,10 @@
>
>      if ( Message::isAdminMsgType( msgType ) )
>      {
> -      m_application.toAdmin( message, m_sessionID );
> +      try{
> +        m_application.toAdmin( message, m_sessionID );
> +      }
> +      catch ( DoNotSend& ) { return false; }
>
>        if( msgType == "A" && !m_state.receivedReset() )
>        {
>
>
>
>
>
> On Tue, May 22, 2012 at 4:03 PM, Natala, Benjamin J <
> ben...@jp...> wrote:
>
>> The ability to throw DoNotSend in toAdmin would be very useful and
>> presumably would not require config changes. With that alone, the other
>> features you added could be hacked in without modifying quickfix source.
>>
>> -Ben
>>
>> -----Original Message-----
>> From: QM [mailto:eqm...@nw...]
>> Sent: Tuesday, May 22, 2012 4:28 PM
>> To: qui...@li...
>> Subject: [Quickfix-developers] modifications to support CME iLink - any
>> interest?
>>
>> QuickFIX Documentation:
>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>> This email is confidential and subject to important disclaimers and
>> conditions including on offers for the purchase or sale of
>> securities, accuracy and completeness of information, viruses,
>> confidentiality, legal privilege, and legal entity disclaimers,
>> available at http://www.jpmorgan.com/pages/disclosures/email.
>>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>



-- 
Grant Birchmeier
*Connamara Systems, LLC*
*Made-To-Measure Trading Solutions.*
Exactly what you need. No more. No less.*
*
http://connamara.com

Re: [Quickfix-developers] modifications to support CME iLink - any interest?

[QM <eqm...@nw...>]

Good point.  I see how that would work for the in-session logon.

(I can't say either way for using this toAdmin() change in the
max-2500-resend case... I haven't researched that angle, as we resolved it
in a different way.)

Patch included, below, for throwing DoNotSend from toAdmin().



Index: src/C++/Session.cpp
===================================================================
--- src/C++/Session.cpp    (revision 2335)
+++ src/C++/Session.cpp    (working copy)
@@ -522,7 +522,10 @@

     if ( Message::isAdminMsgType( msgType ) )
     {
-      m_application.toAdmin( message, m_sessionID );
+      try{
+        m_application.toAdmin( message, m_sessionID );
+      }
+      catch ( DoNotSend& ) { return false; }

       if( msgType == "A" && !m_state.receivedReset() )
       {





On Tue, May 22, 2012 at 4:03 PM, Natala, Benjamin J <
ben...@jp...> wrote:

> The ability to throw DoNotSend in toAdmin would be very useful and
> presumably would not require config changes. With that alone, the other
> features you added could be hacked in without modifying quickfix source.
>
> -Ben
>
> -----Original Message-----
> From: QM [mailto:eqm...@nw...]
> Sent: Tuesday, May 22, 2012 4:28 PM
> To: qui...@li...
> Subject: [Quickfix-developers] modifications to support CME iLink - any
> interest?
>
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> This email is confidential and subject to important disclaimers and
> conditions including on offers for the purchase or sale of
> securities, accuracy and completeness of information, viruses,
> confidentiality, legal privilege, and legal entity disclaimers,
> available at http://www.jpmorgan.com/pages/disclosures/email.
>

Re: [Quickfix-developers] modifications to support CME iLink - any interest?

[Natala, B. J <ben...@jp...>]

The ability to throw DoNotSend in toAdmin would be very useful and presumably would not require config changes. With that alone, the other features you added could be hacked in without modifying quickfix source.

-Ben

-----Original Message-----
From: QM [mailto:eqm...@nw...] 
Sent: Tuesday, May 22, 2012 4:28 PM
To: qui...@li...
Subject: [Quickfix-developers] modifications to support CME iLink - any interest?

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

This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  

[Quickfix-developers] modifications to support CME iLink - any interest?

[QM <eqm...@nw...>]

We've recently certified our QuickFIX-based app against CME's iLink /
AutoCert+.  That required a couple of modifications to QuickFIX, notably:

- ability to limit resends to a maximum 2500 messages

- in-session logon: support CME sending a sequence reset response message
of sequence number == 1 (when, by that time, QuickFIX expects that message
to have sequence number == 2)

- ability to suppress outbound admin messages (i.e. to throw DoNotSend from
Application::toAdmin() -- this is another part of our workaround for CME's
in-session logon)


If you'd be interested, we could contribute this code back to the QuickFIX
core in the form of a feature request + patch.

(I'm checking here first, because we'd need to connect all of this to the
config system such that people could enable/disable these features at
will.  Since we know we need them all, we simply left them hard-coded. ;-)

Cheers

Re: [Quickfix-developers] Limiting ResendRequests

[Natala, B. J <ben...@jp...>]

As far as I am aware, it's possible to stop quickfix from sending admin messages as you can with application messages. You may however be able to hack something together to change the requested sequence number in the automatically generated resend and then generate your own additional resends if the first is over the limit. The tricky part would be managing the state of the resend. 

-Ben

-----Original Message-----
From: djmob [mailto:dan...@bl...] 
Sent: Monday, May 07, 2012 2:12 PM
To: qui...@li...
Subject: [Quickfix-developers] Limiting ResendRequests

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


One exchange that we interface with has a requirement that we do not send ResendRequests larger than 2500 messages and if we need to request more than 2500 messages we should send multiple ResendRequests i.e. 1-2499, 2500-3999 etc...  Is there a way to tell QuickFIX to do this?  Currently there is very little I do with session level messaging and not sure what kind of control I have here without modify the source myself.

Thanks,
--
View this message in context: http://old.nabble.com/Limiting-ResendRequests-tp33763541p33763541.html
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  

[Quickfix-developers] Limiting ResendRequests

[djmob <dan...@bl...>]

One exchange that we interface with has a requirement that we do not send
ResendRequests larger than 2500 messages and if we need to request more than
2500 messages we should send multiple ResendRequests i.e. 1-2499, 2500-3999
etc...  Is there a way to tell QuickFIX to do this?  Currently there is very
little I do with session level messaging and not sure what kind of control I
have here without modify the source myself.

Thanks,
-- 
View this message in context: http://old.nabble.com/Limiting-ResendRequests-tp33763541p33763541.html
Sent from the QuickFIX - Dev mailing list archive at Nabble.com.

Re: [Quickfix-developers] raising DoNotSend from python is not caught

[Natala, B. J <ben...@jp...>]

Upon further testing and looking at the c++ code, I realized I was making a mistake. Raising DoNotSend only works in toApp. Earlier I was trying to raise the exception in toAdmin.

I also thought the exceptions were not reaching the try block in c++ but I can confirm throwing DoNotSend in toApp from python does indeed work. I would still like to be able to stop admin messages from being sent but at the moment, I'm not sure how to achieve that.

Thanks,
Ben

-----Original Message-----
From: Natala, Benjamin J 
Sent: Thursday, April 26, 2012 10:11 AM
To: qui...@li...
Subject: [Quickfix-developers] raising DoNotSend from python is not caught

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

This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  

[Quickfix-developers] raising DoNotSend from python is not caught

[Natala, B. J <ben...@jp...>]

Hi,

I'm using the python version of quickfix 1.13.3. It seems that throwing a DoNotSend exception from python does not prevent messages from being sent. I'm guessing the exceptions are contained in python and do not reach the c++ layer.

Can anyone confirm this? Is there another way I can prevent messages from being sent?

Thanks,
Ben


This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.  

[Quickfix-developers] Memory corruption?

[Hei C. <str...@ya...>]

Hi,

I am running valgrind on my application, and I saw some warning about gnu allocator?

Here is the partial trace:
==31998== Thread 19:
==31998== Invalid read of size 8

==31998==    at 0x35D56532CB: __gnu_cxx::__pool<true>::_M_get_thread_id() (in /usr/lib64/libstdc++.so.6.0.8)

==31998==    by 0x44F732: __gnu_cxx::__mt_alloc<std::_Rb_tree_node<std::pair<int const, FIX::FieldBase> >, __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate(unsigned long, void const*) (mt_allocator.h:682)

==31998==    by 0x44F811: 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_get_node() (stl_tree.h:358)

==31998==    by 0x44F82D: 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_create_node(std::pair<int const, FIX::FieldBase> const&) (stl_tree.h:367)

==31998==    by 0x44F938: 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_insert(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::pair<int const, FIX::FieldBase> const&) (stl_tree.h:819)

==31998==    by 0x44FA22: 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> > >::insert_equal(std::pair<int const, FIX::FieldBase> const&) (stl_tree.h:860)

==31998==    by 0x44FA46: std::multimap<int, FIX::FieldBase, FIX::message_order, __gnu_cxx::__mt_alloc<std::pair<int const, FIX::FieldBase>, __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> > >::insert(std::pair<int const, FIX::FieldBase> const&) (stl_multimap.h:355)

==31998==    by 0x44FB0A: FIX::FieldMap::setField(FIX::FieldBase const&, bool) (FieldMap.h:85)

==31998==    by 0x44FD49: FIX::Message::Message(FIX::BeginString const&, FIX::MsgType const&) (Message.h:118)

==31998==    by 0x45B8BF: FIX44::Message::Message(FIX::MsgType const&) (Message.h:62)

==31998==    by 0x45B98A: FIX44::MassQuote::MassQuote(FIX::QuoteID const&) (MassQuote.h:20)


The most similar trace I found in google search is this one:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604 


I turned off boost allocator in config.h.

Any idea?

Thanks in advance.


Cheers,
Hei

Re: [Quickfix-developers] unsubscribe

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

To unsubscribe, click that link at the bottom of every list email.  At the
bottom of that page is a form you can use to unsubscribe.


On Sun, Apr 1, 2012 at 12:13 AM, Daniel Geppert <da...@gm...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
> unsubscribe
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>



-- 
Grant Birchmeier
*Connamara Systems, LLC*
*Made-To-Measure Trading Solutions.*
Exactly what you need. No more. No less.*
*
http://connamara.com

[Quickfix-developers] unsubscribe

[Daniel G. <da...@gm...>]

unsubscribe

[Quickfix-developers] Stop/Start Doesn't Work?

[Hei C. <str...@ya...>]

Hi,

I am using QuickFIX C++ version 1.12.4 on Linux.

I noticed that SocketInitiator::start() won't try to connect after the following sequence:
- SocketInitiator::start() is called and I successfully connects
- at some point Application::onLogout() is called (don't know why, but probably doesn't matter)
- I try to create another thread to call SocketInitiator::stop()
- With that thread, I call SocketInitiator::start() again, but it doesn't connect.

Did I use start/stop() incorrectly?

Thanks in advance.


Cheers,
Hei