FIX Session Dropped

[Nick Volpe]

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



I'm using QF 1.11.0 for Java.  I've implemented a class that extends quickfix.MessageCracker and implements quickfix.Application.  In my implementation, each FIX application message I receive needs to update certain records in the DB behind my investment management system.  I've noticed that on rare occasions, this can take up to a minute and prevents my application from sending heartbeat messages.  This results in my counterparty sending a test request, which I'm unable to process, since my application is still busy trying to update my database, which then causes the counterparty to drop the FIX session.

Does anyone have any suggestions how to manage this?  I thought of spawning a new thread for each FIX application message I receive, which would process the message, but is there a better way?

Thanks

Nik

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

This email and any files transmitted with it are confidential and

intended solely for the use of the individual or entity to whom they

are addressed. Any unauthorized use of the information contained

in this email or its attachments is prohibited. If this email is received in

error, please contact the sender and delete the material from your

computer systems. Do not use, copy, or disclose the contents of this

email or any attachments.

Abu Dhabi Investment Authority (ADIA) accepts no responsibility for

the content of this email to the extent that the same consists of

statements and opinions made which are the senders own and not

made on behalf of ADIA. Nor does ADIA accept any liability for any

errors or omissions in the content of this email caused by electronic

and technical failures.

Although ADIA has taken reasonable precautions to ensure that no

viruses are present in this email, ADIA accepts no responsibility for

any loss or damage arising from the use of this email or its

attachments.

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

 

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Quickfix-developers mailing list
Quickfix-developers@...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Nick Fortescue-3]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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

A simpler way of doing this would be for the Fix application to hand each message on to a queue, which is then fetched from by a worker thread which does the work. That way you only need one extra thread. Be aware this will add a bit of latency to your application, it isn't a no brainer.

 

If you are using java 5 there are some nice classes in java.util.concurrent to help you manage the concurrency issues. Try looking at LinkedBlockingQueue or ConcurrentLinkedQueue depending on your design.
 

Nick
 

On 12/4/06, Nick Volpe <niv.tr@...> wrote:

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


 

I'm using QF 1.11.0 for Java.  I've implemented a class that extends quickfix.MessageCracker and implements quickfix.Application.  In my implementation, each FIX application message I receive needs to update certain records in the DB behind my investment management system.  I've noticed that on rare occasions, this can take up to a minute and prevents my application from sending heartbeat messages.  This results in my counterparty sending a test request, which I'm unable to process, since my application is still busy trying to update my database, which then causes the counterparty to drop the FIX session.

Does anyone have any suggestions how to manage this?  I thought of spawning a new thread for each FIX application message I receive, which would process the message, but is there a better way?

Thanks

Nik

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

This email and any files transmitted with it are confidential and

intended solely for the use of the individual or entity to whom they

are addressed. Any unauthorized use of the information contained

in this email or its attachments is prohibited. If this email is received in

error, please contact the sender and delete the material from your

computer systems. Do not use, copy, or disclose the contents of this

email or any attachments.

Abu Dhabi Investment Authority (ADIA) accepts no responsibility for

the content of this email to the extent that the same consists of

statements and opinions made which are the senders own and not

made on behalf of ADIA. Nor does ADIA accept any liability for any

errors or omissions in the content of this email caused by electronic

and technical failures.

Although ADIA has taken reasonable precautions to ensure that no

viruses are present in this email, ADIA accepts no responsibility for

any loss or damage arising from the use of this email or its

attachments.

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

 

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
Quickfix-developers mailing list
Quickfix-developers@...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Quickfix-developers mailing list
Quickfix-developers@...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[gm-mrktc]

Nick Volpe wrote:

In my
implementation, each FIX application message I receive needs to update
certain records in the DB behind my investment management system.  I've
noticed that on rare occasions, this can take up to a minute and prevents
my application from sending heartbeat messages.

Nick, for applications like this, we have become quite enamored of the idea of a Staged Event Driven Architecture, SEDA (http://www.eecs.harvard.edu/~mdw/proj/seda/).  When it comes down to it, it really is a matter of passing messages through a queue as Nick Fortescue suggested, but it's a useful abstraction that you can implement yourself, or there are many frameworks that implement it in one way or another.

The basic idea is that you break up your message processing into a number of "stages", and in the most basic setup, you have one thread per stage that are connected by a thread-safe queue like the ones found in java.util.concurrent.  It requires a little bit of a change in how you think about coding your application, because you need to start thinking in "message passing" terms rather than "method invoking" terms.  So returning values and throwing exceptions from your stages become harder.  However we find it to be a logical construct that likely has good scaling characteristics.

There are several projects and libraries that will manage the staging framework for you, allowing you to implement just the "stage" logic.  We were using a project called JCyclone for a while, which provided a basic framework.  However we now use a "message-driven POJO" setup using ActiveMQ and Spring (a good--if a little out of date--tutorial is here: http://blog.interface21.com/main/2006/08/11/message-driven-pojos/).  Other libraries like Mule, and MINA implement SEDA in their own way, but we found neither of these really fit our needs.

It may be the fact that these frameworks are overkill for what you need, and you really just want to implement a simple queue-and-two-threads solution that does exactly what you need.  But feel free to see how we do it. All the code for our order routing server is here http://trac.marketcetera.org/trac.fcgi/browser/platform/trunk/oms/src/main/java/org/marketcetera/oms.  OutgoingMessageHandler.java implements our main "stage", with its entry point, "handleMessage".  Then Spring and ActiveMQ do the heavy lifting.  A sample Spring configuration can be found here http://trac.marketcetera.org/trac.fcgi/browser/platform/trunk/oms/src/main/resources/oms.xml (it includes some of the other xml files in the same directory).

Anyway, hope this helps.

graham