Thread: [Quickfix-developers] Server Thread
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-developers
|
From: Rob K. <ro...@ri...> - 2003-03-24 22:23:51
|
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. |
|
From: Oren M. <ore...@ya...> - 2003-03-24 22:53:29
|
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/listinfo/quickfix-developers --------------------------------- Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! |
|
From: David M. <Dav...@mo...> - 2003-03-25 09:40:52
|
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. |
|
From: Oren M. <ore...@ya...> - 2003-03-26 19:23:20
|
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. 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. 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. 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... 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/listinfo/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. --------------------------------- Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! |
|
From: Joerg T. <Joe...@ma...> - 2003-04-11 13:39:16
|
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
|
|
From: Oren M. <ore...@ya...> - 2003-04-11 16:01:12
|
>> I see from the repository that you have already done it. Can I check it >> out, >> e.g. using BUILD_...-50? Yeah, any labeled build should be useable. If the compile fails or any tests fails the build won't get a label. >> 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. This is probably what we will use. There are already some minimal junit tests in the quickfix/src/java/test directory. These were originally used as the proof of concept to get the JNI stuff working, but they should be expanded to be more comprehensive and should be run with the build. This will also make a future port to pure java much much easier if the need arises. Will probablly use NUnit for the .NET API. JavaDoc's would be good as well. We can also run Doxygen, which is already being used for C++, against the java code (which supports javadoc syntax). --------------------------------- Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more |
|
From: Joerg T. <Joe...@ma...> - 2003-04-11 16:06:50
|
> Yeah, any labeled build should be useable. If the compile fails or any
> tests fails the build won't get a label.
OK, then I will start to beta test...
> This is probably what we will use. There are already some minimal junit
> tests in the quickfix/src/java/test directory. These were originally
> used as the proof of concept to get the JNI stuff working, but they
> should be expanded to be more comprehensive and should be run with the
> build.
I will have a look at them.
> This will also make a future port to pure java much much easier
> if the need arises.
Do you have concrete plans to do it? There is the util.concurrent package also used in JBoss
which would make the threading even more flexible using Java.
> Will probablly use NUnit for the .NET API.
>
> JavaDoc's would be good as well. We can also run Doxygen, which is
> already being used for C++, against the java code (which supports
> javadoc syntax).
OK, this would be more consistent. Can Doxygen do the transition from Java over
JNI to C++? That would be great.
Cheers, Jörg
--
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
|
|
From: Oren M. <ore...@ya...> - 2003-03-24 22:53:30
|
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/listinfo/quickfix-developers --------------------------------- Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! |
|
From: Nicholas P. <nic...@sl...> - 2003-03-26 08:40:00
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am attempting to get a connection going from my QuickFIX application to another vendor. The problem I am having is that all messages from the other vendor are being rejected with the message: (Message # Rejected: SendingTime accuracy problem) The clock on their machine seems to be about four and one half minutes slow. We are using NTP, so I am pretty damn sure our time is right. Is there any way to disable this feature of QuickFIX in the config if they won't fix the clock on their machine? Thanks, - -Nick -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+gWdWR42/Somtp0QRAnTtAJsF0+dkcgkNpLLLasBWIox30o+aLwCdEo+3 249AjhcQNpmoxsAzSv4zxFQ= =i/Of -----END PGP SIGNATURE----- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X