Re: [Quickfix-developers] Server Thread

[David M. <Dav...@mo...>]

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...

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.
>
>  Rob Kulseth <ro...@ri...> wrote:
>
>      I am creating a GUI application to forward orders to a
>      counterparty, from another counterparty. Everything is
>      working fine, I just have one question. My application
>      creates both an Acceptor and an Initiator. I noticed that
>      when I tried to start the Acceptor with Acceptor.start() my
>      application would hang. I soon realized that the start
>      method claims the thread you use to call the method. To fix
>      that I spawned another thread to invoke the start method. my
>      GUI began to behave properly, but the thread that began
>      looping in the onRun was not the same thread that I used to
>      invoke the start method. Am I missing some basic concept
>      here, or is this how it is supposed to work. I just don't
>      want random threads laying around doing nothing.
>
>
>      -------------------------------------------------------
>      This sf.net email is sponsored by:ThinkGeek
>      Welcome to geek heaven.
>      http://thinkgeek.com/sf
>      _______________________________________________
>      Quickfix-developers mailing list
>      Qui...@li...
>      https://lists.sourceforge.net/lists/listi
>      fo/quickfix-developers
>
>
> -----------------------------------------------------------------------
> Do you Yahoo!?
> Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!

--
NOTICE: If received in error, please destroy and notify sender.  Sender does not waive confidentiality or privilege, and use is prohibited.