Re: [Quickfix-developers] Server Thread

[Joerg T. <Joe...@ma...>]

Hi all,

now I am at the point that the below discussion gets interesting for me:

> Thanks for your input on these. I'm sure that as we begin getting more 
> and more input like this on how QF is commonly used, we will begin to 
> see some patterns develop.  It would be interesting to hear from more 
> people as to how QF is integrated into different applications and what 
> sort of integration challenges they have.

We receive FIX messages, process them and forwards them vi JMS to our
JBoss Application Server. (Some guy actually used FIX as a MBean deployed
into JBoss -- that would be interesting for us.) Therefore I support
Davids ideas fully: some sort of JMS-like API would be great, and listeners
to get events and messages.

> For the short term I think that we will focus on getting rid of onRun 
> and making the start call asynchronous.  Then we should revisit any 
> other major architectural changes and see if we will want to work them 
> in to a 2.0 release. 

I see from the repository that you have already done it. Can I check it out,
e.g. using BUILD_...-50?

> The biggest challenge here is keeping all the API's (C++, java and .NET) 
> in synch.  Before making to many significant changes to the architecture 
> I want to make sure that all of these are fully synchronized.  I also 
> think it is long overdue to put together a testsuite for Java and .NET 
> like we have for C++.  We are going to be adding more and more API's, so 
> we need to have an automated system to verify that they all work in the 
> same manner.

Agreed. How about to use JUnit for Java? We use it for more than 2 years now.
In addition, I generated Java docs from the Java classes. OK, I had to increase
the memory of my JVM and got a 50Mbytes HTML trees, but it's really nice to
navigate. Should be part of the build script.

> 
>  */David Monheit <Dav...@mo...>/* wrote:
> 
>     Hi guys,
> 
>     Continuing to learn the system.
> 
>     I agree with getting rid of onRun!!!   I was wondering, Oren, if it
>     does not pay to think of quickfix in terms of something like JMS
>     (just an analogy).  Basically you have some class which, when
>     started, generates callbacks on some known interface and to which
>     you can send messages ( quickfixObject.Sessions(SessionID).send(...)
>     ) when so desired.
> 
>     The main app would be responsible for instantiating the Manager and
>     starting (and perhaps pausing/stopping) it at will (as you mentioned
>     below).
> 
>     This would allow quickfix to have all kinds of goodies hidden from
>     the main app.  For instance the threading model (ie single, thread
>     per Session or pool).   In the current library, the basic app
>     derives from Application etc.  If a manager is used, we can refactor
>     the code in Application into the said Manager and just have the main
>     app register listeners (which implement the basic onApp, toApp etc
>     interface).
> 
>     Another thing that would be nice is for the quickfix class to accept
>     multiple listeners for a given Session.  It then becomes very easy
>     to write classes which do different things to the same set of
>     messsages.  For instance main registers some basic trading class
>     (perhaps based on market data which it gets from somewhere), another
>     class performs limit monitoring and publishes it to the network on
>     its own thread, another class can send alerts to some trading desk
>     etc etc etc.  Each listener may or may not have its own thread.  The
>     Manager will call all registered listeners (for a given Session)
>     upon each callback...


But you have to make sure that hanging or exception-throwing listeners do not
stop the distribution of the message. Here are several threads or some sort
of queue plus a thread pool needed.


> 
>     Anyways, my 5 pence worth.
> 
>     Thanks
>     David
> 
>     PS Turns out that I just need to send my encrypted password as an
>     MD5 digest during logon.  I don't think that it will contains
>     NULL or 0x01...  Thanks.
>      
>      
>      
> 
>     Oren Miller wrote:
> 
>>     Yeah.  This behavior is probably going to change soon.  QuickFIX
>>     was originally designed with a certain type of application in
>>     mind, and is very good for quickly building thos kinds of
>>     applications (event based servers).  More and more people are
>>     using it for other things, so a better approach is needed.  Here
>>     is how it currently works.
>>
>>     When you call start(), the acceptor or initiator will use the
>>     current thread to drive the socket events, and then spawns a new
>>     thread to call onRun.  In retrospect, doing it the other way
>>     around probably would have made more sense.
>>
>>     The original intent was that the start() thread would drive the
>>     fix engine (or spawn off a series of threads to drive it), and the
>>     onRun thread would drive non-FIX related events.  Unfortunately,
>>     in the context of a larger application (such as GUIs), this is
>>     rather constrictive and forces you to do some architectural
>>     workarounds.
>>
>>     The way that I want it to work is to get rid of the entire onRun
>>     concept, and make start() and asynchronous call.  Then we could
>>     also provide a symetrical stop() call. I was planning on putting
>>     this into the 1.5 release.  I'm debating whether to change over,
>>     or have a version that supports the new and old systems, and
>>     marking the old onRun as deprecated.


-- 
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen