Thread: [Quickfix-developers] ThreadedSocketInitiator vs SocketInitiator
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-developers
|
From: Nick V. <ni...@ad...> - 2006-05-09 14:24:52
|
Can anyone tell me pros/cons of using a ThreadedSocketInitiator versus a Socket Initiator? I c an't seem to find much in the documentation or the mailing list archives. Any help would be greatly appreciated. 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. ************************************************************************************************************** |
|
From: Hei C. <str...@ya...> - 2011-03-24 00:44:39
|
Hi, I am trying to make sure that I understand the differences between those 2 (may I assume that 1.13.x and 1.12.x behavor the same for those 2 classes?). I have searched online, and read this post: http://permalink.gmane.org/gmane.comp.finance.quickfix.devel/3536 It seems like they behave IF I put multiple session settings in one file and pass it to ThreadedSocketInitiator, or I put each session setting into individual file (hence, individual SessionConfig object) and pass it to a different SocketInitiator. Is there any other difference? Thanks in advance. Cheers, Hei |
|
From: Dale W. <wil...@oc...> - 2006-05-09 15:18:43
|
Nick Volpe wrote: > > Can anyone tell me pros/cons of using a ThreadedSocketInitiator versus > a Socket Initiator? I c an't seem to find much in the documentation > or the mailing list archives. Any help would be greatly appreciated. If you are connecting to a single counterparty (for example a trader connecting to one exchange), use SocketInitiator. If you are connecting to more than one exchange then ThreadedSocketInitiator might make your program more responsive. With SocketInitiator every incoming FIX message has to be completely processed -- including any application level message processing which might take a long time -- before any other connections are serviced. With ThreadedSocketInitiator messages from separate sources can be processed in parallel. In *either* case you must write thread-safe code because incoming messages are processed on a separate thread (or threads) from outgoing messages (i.e if your main thread generates an order, the execution report(s) for that order will arrive courtesy of a different thread so if you have a common "Order Management" component in your application it needs to be thread-safe.) HTH, Dale > > Thanks. > Nik |
|
From: Caleb E. <cal...@gm...> - 2006-05-09 16:08:29
|
I don't think this made it through the first time. On 5/9/06, Nick Volpe <ni...@ad...> wrote: > > Can anyone tell me pros/cons of using a ThreadedSocketInitiator versus a > Socket Initiator? I c an't seem to find much in the documentation or the > mailing list archives. Any help would be greatly appreciated. The non-threaded SocketInitiator can actually get into a deadlock situation whereby your application will block forever. I would recommend against anyone ever using it. This deadlock will happen if your application fills up a socket's sending buffer while the other side is doing the same (e.g. two non-threaded QuickFIX apps generating heavy traffic). Neither side will end up reading from its side of the socket, being blocked in a send() call, and both sides will deadlock. -- Caleb Epstein caleb dot epstein at gmail dot com |
|
From: Staffan U. <sta...@mu...> - 2006-05-10 11:36:09
|
"Caleb Epstein" <cal...@gm...> writes: > The non-threaded SocketInitiator can actually get into a deadlock > situation whereby your application will block forever. I would > recommend against anyone ever using it. > > This deadlock will happen if your application fills up a socket's > sending buffer while the other side is doing the same (e.g. two > non-threaded QuickFIX apps generating heavy traffic). Neither side > will end up reading from its side of the socket, being blocked in a > send() call, and both sides will deadlock. Maybe I'm missing something obvious, but why won't the same deadlock happen with the threaded version, if all it does is have one thread per session? I guess the above can also be asked as a question: Does ThreadedSocketInitiator work differently from SocketInitiator in the case where there is only one session? Staffan |
|
From: Oren M. <or...@qu...> - 2006-05-10 16:01:45
|
Yeah, I'm reading that in unix it is typical to do a fork and have each process treat it as unidirectional to avoid deadlocks. So we would have to have a thread for sending and a thread for receiving. This is actually something we had talked about in the past to prevent deadlocks when sending from callbacks. Essentially creating a sending queue. I am wondering however if we really do need the SocketInitiator/Acceptor or if it should be deprecated in favor of the threaded versions. I think the precense of both of them has been one of the more confusing aspects of QuickFIX and not sure it really is advantageous to have both at this point. Any thoughts on this? --oren ----- Original Message ----- From: "Caleb Epstein" <cal...@gm...> To: "Nick Volpe" <ni...@ad...> Cc: "quickfix-developers" <qui...@li...> Sent: Tuesday, May 09, 2006 11:08 AM Subject: Re: [Quickfix-developers] ThreadedSocketInitiator vs SocketInitiator QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html QuickFIX Support: http://www.quickfixengine.org/services.html I don't think this made it through the first time. On 5/9/06, Nick Volpe <ni...@ad...> wrote: > > Can anyone tell me pros/cons of using a ThreadedSocketInitiator versus a > Socket Initiator? I c an't seem to find much in the documentation or the > mailing list archives. Any help would be greatly appreciated. The non-threaded SocketInitiator can actually get into a deadlock situation whereby your application will block forever. I would recommend against anyone ever using it. This deadlock will happen if your application fills up a socket's sending buffer while the other side is doing the same (e.g. two non-threaded QuickFIX apps generating heavy traffic). Neither side will end up reading from its side of the socket, being blocked in a send() call, and both sides will deadlock. -- Caleb Epstein caleb dot epstein at gmail dot com ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=k&kid0709&bid&3057&dat1642 _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Brian E. <azz...@ya...> - 2006-05-10 16:22:43
|
Oren - From a simplicity viewpoint, I would vote for scrapping the "single-threaded" version of SocketInitiator. As the QF callbacks are inherently multithreaded, any QF user should be coding things in a thread-safe manner anyway. Granted, currently a SocketInitiator user only needs to make sure that the sending thread does not share a code path with the receive callback, but I've never seen the point of attempting to save the little bit of coding required to use ThreadedSocketInitiator - does anyone who has multiple active sessions at a time really rely on SocketAcceptor queuing the separate message streams? The problems that come using a single thread to satisfy multiple readers are so much more pervasive than handling a few more inbound threads. Currently, if you are only dealing with a single session, there doesn't appear to be a lick of difference between the behavior of the "threaded" vs. "unthreaded" classes. The question becomes how to go forward? Do you deprecate SocketInitiator/Acceptor or simply make it a facade for ThreadedSocketInitiator/Acceptor? Deprecation highlights the fact that you will need to make code changes, but a lot of people using SocketInitiator are probably in that one-session-only mode that would be unaffected (and require no coding changes) if you went the facade route. I also think it would be a very good idea to decouple the reads and writes - I was unaware that ThreadedXXX classes had the same deadlock issues as the nonthreaded versions. - Brian Erst Thynk Software, Inc. p.s. Speaking of confusion, is there a QuickFIX wiki? While the existing documentation is sufficient for getting started, in order to really understand a lot of QF you have to read the mailing list archives. If we had a wiki, I'd be tempted to transfer at least some of the mailing list knowledge to the wiki, if only from an ongoing basis. ----- Original Message ---- From: Oren Miller <or...@qu...> To: Caleb Epstein <cal...@gm...>; Nick Volpe <ni...@ad...> Cc: quickfix-developers <qui...@li...> Sent: Wednesday, May 10, 2006 11:01:28 AM Subject: Re: [Quickfix-developers] ThreadedSocketInitiator vs SocketInitiator QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html QuickFIX Support: http://www.quickfixengine.org/services.html Yeah, I'm reading that in unix it is typical to do a fork and have each process treat it as unidirectional to avoid deadlocks. So we would have to have a thread for sending and a thread for receiving. This is actually something we had talked about in the past to prevent deadlocks when sending from callbacks. Essentially creating a sending queue. I am wondering however if we really do need the SocketInitiator/Acceptor or if it should be deprecated in favor of the threaded versions. I think the precense of both of them has been one of the more confusing aspects of QuickFIX and not sure it really is advantageous to have both at this point. Any thoughts on this? --oren ----- Original Message ----- From: "Caleb Epstein" <cal...@gm...> To: "Nick Volpe" <ni...@ad...> Cc: "quickfix-developers" <qui...@li...> Sent: Tuesday, May 09, 2006 11:08 AM Subject: Re: [Quickfix-developers] ThreadedSocketInitiator vs SocketInitiator QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html QuickFIX Support: http://www.quickfixengine.org/services.html I don't think this made it through the first time. On 5/9/06, Nick Volpe <ni...@ad...> wrote: > > Can anyone tell me pros/cons of using a ThreadedSocketInitiator versus a > Socket Initiator? I c an't seem to find much in the documentation or the > mailing list archives. Any help would be greatly appreciated. The non-threaded SocketInitiator can actually get into a deadlock situation whereby your application will block forever. I would recommend against anyone ever using it. This deadlock will happen if your application fills up a socket's sending buffer while the other side is doing the same (e.g. two non-threaded QuickFIX apps generating heavy traffic). Neither side will end up reading from its side of the socket, being blocked in a send() call, and both sides will deadlock. -- Caleb Epstein caleb dot epstein at gmail dot com ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=k&kid0709&bid&3057&dat1642 _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Oren M. <or...@qu...> - 2006-05-10 16:56:43
|
There was, however it was overrun by WikiSpam and I never got around to researching solutions to the problem. --oren > p.s. Speaking of confusion, is there a QuickFIX wiki? While the existing > documentation is sufficient for getting started, in order to really > understand a lot of QF you have to read the mailing list archives. If we > had a wiki, I'd be tempted to transfer at least some of the mailing list > knowledge to the wiki, if only from an ongoing basis. |
|
From: Caleb E. <cal...@gm...> - 2006-05-11 12:32:41
|
Resending this as it bounced yesterday. Sorry if you see a dupe. GMail has been giving me fits lately. On 5/10/06, Oren Miller <or...@qu...> wrote: > Yeah, I'm reading that in unix it is typical to do a fork and have each > process treat it as unidirectional to avoid deadlocks. So we would have = to I think using non-blocking I/O and select is much more common. I believe I submitted a patch about 18 months ago that made the Socket* classes use non-blocking sockets and did I/O multiplexing with select to handle both read- and write-readiness, but I never pushed hard enough to get this into QF. > have a thread for sending and a thread for receiving. This is actually > something we had talked about in the past to prevent deadlocks when sendi= ng > from callbacks. Essentially creating a sending queue. I am wondering > however if we really do need the SocketInitiator/Acceptor or if it should= be > deprecated in favor of the threaded versions. I think the precense of bo= th > of them has been one of the more confusing aspects of QuickFIX and not su= re > it really is advantageous to have both at this point. Any thoughts on th= is? I think ditching the non-threaded Socket* classes would be a win, because it would reduce the overall surface area of the library and simplify the new-user experience by eliminating the descision about which type of Acceptor/Connector to use. Some folks are very anti-thread, though, so they may want to have a non-MT choice, but the implementation should be improved if it is going to be kept around. As far as design questions go, I think it might make sense to come up with an something that exists somewhere between the current non-threaded Socket* classes and the thread-per-connection ThreadedSocket* classes. I am of the mind that a thread per connection is almost always a waste of resources, and that I/O multiplexing with select/poll/WFMO and a thread pool might be a better option. As an aside, it would also be nice if the user didn't need to choose specific Acceptor/Connector implementations in their application at all, but if there was some central "Dispatcher" that handled both types of functions. -- Caleb Epstein caleb dot epstein at gmail dot com |
|
From: Hozaifa A. A. <hoz...@ve...> - 2008-02-06 09:55:25
|
I want to know that how can i manage sessions and connect to Market data server on one port and order server on other port. Ho do i create configuration and handle my application to get market data and also have order processing to it. Dale Wilson wrote: > > Nick Volpe wrote: >> >> Can anyone tell me pros/cons of using a ThreadedSocketInitiator versus >> a Socket Initiator? I c an't seem to find much in the documentation >> or the mailing list archives. Any help would be greatly appreciated. > If you are connecting to a single counterparty (for example a trader > connecting to one exchange), use SocketInitiator. > > If you are connecting to more than one exchange then > ThreadedSocketInitiator might make your program more responsive. With > SocketInitiator every incoming FIX message has to be completely > processed -- including any application level message processing which > might take a long time -- before any other connections are serviced. > With ThreadedSocketInitiator messages from separate sources can be > processed in parallel. > > In *either* case you must write thread-safe code because incoming > messages are processed on a separate thread (or threads) from outgoing > messages (i.e if your main thread generates an order, the execution > report(s) for that order will arrive courtesy of a different thread so > if you have a common "Order Management" component in your application it > needs to be thread-safe.) > > HTH, > > Dale >> >> Thanks. >> Nik > > > -- View this message in context: http://www.nabble.com/ThreadedSocketInitiator-vs-SocketInitiator-tp4300945p15306348.html Sent from the QuickFIX - Dev mailing list archive at Nabble.com. |
|
From: azmat <azm...@gm...> - 2008-02-06 21:48:44
|
Hozaifa, >From what I understand this is what you need to do. Basically you'll need to create two sessions (based off of the config files). These connections will have their own set of COMP IDs. When you send a market data request, you'll need to send it via the session that is attributed to the market data connection information. Oren helped me understand it in my post below. http://www.nabble.com/Market-Data-Request-tt15279801.html Hope that helps! Azmat On Feb 6, 2008 3:55 AM, Hozaifa Akber Ali <hoz...@ve...> wrote: > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX Support: http://www.quickfixengine.org/services.html > > > I want to know that how can i manage sessions and connect to Market data > server on one port and order server on other port. Ho do i create > configuration and handle my application to get market data and also have > order processing to it. > > > > Dale Wilson wrote: > > > > Nick Volpe wrote: > >> > >> Can anyone tell me pros/cons of using a ThreadedSocketInitiator versus > >> a Socket Initiator? I c an't seem to find much in the documentation > >> or the mailing list archives. Any help would be greatly appreciated. > > If you are connecting to a single counterparty (for example a trader > > connecting to one exchange), use SocketInitiator. > > > > If you are connecting to more than one exchange then > > ThreadedSocketInitiator might make your program more responsive. With > > SocketInitiator every incoming FIX message has to be completely > > processed -- including any application level message processing which > > might take a long time -- before any other connections are serviced. > > With ThreadedSocketInitiator messages from separate sources can be > > processed in parallel. > > > > In *either* case you must write thread-safe code because incoming > > messages are processed on a separate thread (or threads) from outgoing > > messages (i.e if your main thread generates an order, the execution > > report(s) for that order will arrive courtesy of a different thread so > > if you have a common "Order Management" component in your application it > > needs to be thread-safe.) > > > > HTH, > > > > Dale > >> > >> Thanks. > >> Nik > > > > > > > > -- > View this message in context: > http://www.nabble.com/ThreadedSocketInitiator-vs-SocketInitiator-tp4300945p15306348.html > Sent from the QuickFIX - Dev mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > |
×
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