Thread: [Quickfix-developers] Week Long Sessions
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-developers
|
From: Michael H. <mh...@li...> - 2005-11-01 11:00:38
|
I am using QuickFix 1.94 to connect to SFE. They use a week long = session. Here is my settings configuration file: =20 [DEFAULT] ConnectionType=3Dinitiator HeartBtInt=3D5 FileStorePath=3D/var/reactor/prd/sfeprice/store FileLogPath=3D/var/reactor/prd/sfeprice/logs UseDataDictionary=3DN ValidateFieldsOutOfOrder=3DN ValidateFieldsHaveValues=3DN CheckLatency=3DN SocketConnectHost=3D192.168.14.149 SocketConnectPort=3D2000 ReconnectInterval=3D5 StartDay=3DSunday StartTime=3D21:00:00 EndDay=3DFriday EndTime=3D21:00:00 =20 [SESSION] BeginString=3DFIX.4.0 TargetCompID=3DSFE SenderCompID=3DFCS =20 SFE is base in Sydney and uses EST (UTC+11). At midnight and 1pm UTC = QuickFix disconnects and reconnects every morning. It also resets the = sequence numbers back to 1. This causes me about one minute down time = because it has to download all of the contracts etc... before trading = can start again. It also has to re-sync the sequence numbers.=20 =20 Do I have something wrong in the configuration file? Does anyone use = QuickFix past midnight UTC? Is this a known issue? =20 Thanks =20 Michael Holm Liquid Capital Markets Ltd 11 Old Jewry London EC2R 8DU Tel:020 7726 3028 =20 --=20 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.12.6/152 - Release Date: = 31/10/2005 =20 |
|
From: Brian E. <azz...@ya...> - 2005-11-03 17:39:24
|
I have a new C# FIX application that requires a manual login/logout process. Users need to be able to login to my test server and logout multiple times, so I have two big buttons to do this. The problem is that logging in takes a very long time. The C# version of the library seems to have problems with repeated calls to the threaded initiator's start() and stop() methods, so I start() the initiator at application start up and immediately logout the created session (during the onCreate() callback). I then use the session's logon() and logout() methods to log the session on and off. Logging off is nearly instantaneous, but logging on is generally slow. Looking at the code, both methods simply set the value of m_enabled on the session. Presumably, logging off is quick because next() is constantly being called while a session is active and the m_enabled flag change is being picked up quickly. Logging on, however, can take upwards of 30 seconds. Again, this is presumably because while a session is logged out there is some sort of timeout or delay between checks of the m_enabled flag. Considering that prior to each login, I see the "Connecting to [IP address] on port [#]", it would appear it is some sort of delay prior to spawning the socketThread (the first time) and then the use of m_reconnectInterval and process_sleep (subsequent times). Aside from fixing the .NET code so that initiator start/stop cycles don't cause the code to hang, is there any way of speeding up the logon process? My sneaking suspicion is no, but it doesn't hurt to ask... I would also suggest that the use of process_sleep is a bad idea - whenever I need to code a sleep-type function, I use a mutex and a WaitForSingleObject with the sleep time as the timeout. That way, I can interrupt the sleep (by triggering the mutex) if the reason for the sleep has gone away (or so I don't have to wait 30 seconds to bring my application down if I'm sleeping). Makes things much more responsive. - Brian Erst Thynk Software, Inc. |
|
From: Dale W. <wil...@oc...> - 2005-11-03 18:54:57
|
Brian Erst wrote: ><SNIP> >I would also suggest that the use of process_sleep is a bad idea - >whenever I need to code a sleep-type function, I use a mutex and a >WaitForSingleObject with the sleep time as the timeout. That way, I can >interrupt the sleep (by triggering the mutex) if the reason for the >sleep has gone away (or so I don't have to wait 30 seconds to bring my >application down if I'm sleeping). Makes things much more responsive. > > An excellent idea with one very important drawback. WaitForSingleObject with a timeout is a WIN32 concept. It is possible, but not necessarily easy, to code an equivalent functionality on a posix system using |pthread_cond_timedwait. If QuickFIX were going to use this technique someone would have to beef up its cross-platform thread synchronization support. Dale | >- Brian Erst >Thynk Software, Inc. > > > > -- ----------------------------------------------------- Dale Wilson, Senior Software Engineer Object Computing, Inc. (OCI) http://www.ociweb.com/ http://www.theaceorb.com/ ---------------------------------------------------- |
|
From: Oren M. <or...@qu...> - 2005-11-03 19:00:39
|
We actually do have a cross platform Event object that should do the = trick with a little modification: = http://cvs.sourceforge.net/viewcvs.py/quickfix/quickfix/src/C%2B%2B/Event= .h?rev=3D1.4&view=3Dmarkup It uses WaitForSingleObject and pthread_cond_timedwait. It is hardcoded = to wait for 100 milliseconds. If we just add a wait() signature where = we can pass in a value for the time, this class would probably be = perfect. --oren ----- Original Message -----=20 From: Dale Wilson=20 Cc: qui...@li...=20 Sent: Thursday, November 03, 2005 12:54 PM Subject: Re: [Quickfix-developers] Faster logons Brian Erst wrote:=20 <SNIP> I would also suggest that the use of process_sleep is a bad idea - whenever I need to code a sleep-type function, I use a mutex and a WaitForSingleObject with the sleep time as the timeout. That way, I can interrupt the sleep (by triggering the mutex) if the reason for the sleep has gone away (or so I don't have to wait 30 seconds to bring my application down if I'm sleeping). Makes things much more responsive. An excellent idea with one very important drawback. = WaitForSingleObject with a timeout is a WIN32 concept.=20 It is possible, but not necessarily easy, to code an equivalent = functionality on a posix system using pthread_cond_timedwait. If QuickFIX were going to use this technique someone would have to = beef up its cross-platform thread synchronization support. Dale - Brian Erst Thynk Software, Inc. --=20 ----------------------------------------------------- Dale Wilson, Senior Software Engineer Object Computing, Inc. (OCI) http://www.ociweb.com/ http://www.theaceorb.com/ ---------------------------------------------------- |
|
From: Dale W. <wil...@oc...> - 2005-11-03 19:05:24
|
Oren Miller wrote: > We actually do have a cross platform Event object that should do the > trick with a little modification: > http://cvs.sourceforge.net/viewcvs.py/quickfix/quickfix/src/C%2B%2B/Event.h?rev=1.4&view=markup > <http://cvs.sourceforge.net/viewcvs.py/quickfix/quickfix/src/C%2B%2B/Event.h?rev=1.4&view=markup> Cool. You're ahead of us. And in that case, I second Brian's suggestion about sleeping with a timeout. The session::login process could nudge the sleeping thread to say "Hey, look what I just did!" Dale > > It uses WaitForSingleObject and pthread_cond_timedwait. It is > hardcoded to wait for 100 milliseconds. If we just add a wait() > signature where we can pass in a value for the time, this class would > probably be perfect. > > --oren > > ----- Original Message ----- > *From:* Dale Wilson <mailto:wil...@oc...> > *Cc:* qui...@li... > <mailto:qui...@li...> > *Sent:* Thursday, November 03, 2005 12:54 PM > *Subject:* Re: [Quickfix-developers] Faster logons > > Brian Erst wrote: > >><SNIP> >>I would also suggest that the use of process_sleep is a bad idea - >>whenever I need to code a sleep-type function, I use a mutex and a >>WaitForSingleObject with the sleep time as the timeout. That way, I can >>interrupt the sleep (by triggering the mutex) if the reason for the >>sleep has gone away (or so I don't have to wait 30 seconds to bring my >>application down if I'm sleeping). Makes things much more responsive. >> >> > An excellent idea with one very important drawback. > WaitForSingleObject with a timeout is a WIN32 concept. > It is possible, but not necessarily easy, to code an equivalent > functionality on a posix system using |pthread_cond_timedwait. > If QuickFIX were going to use this technique someone would have to > beef up its cross-platform thread synchronization support. > > Dale > > | > >>- Brian Erst >>Thynk Software, Inc. >> >> >> >> > -- > >----------------------------------------------------- > Dale Wilson, Senior Software Engineer > Object Computing, Inc. (OCI) > http://www.ociweb.com/ http://www.theaceorb.com/ >---------------------------------------------------- > -- ----------------------------------------------------- Dale Wilson, Senior Software Engineer Object Computing, Inc. (OCI) http://www.ociweb.com/ http://www.theaceorb.com/ ---------------------------------------------------- |
|
From: Brian E. <azz...@ya...> - 2005-11-03 19:11:03
|
Well, then, just ignore my last message. Sounds like a tweaked Event object will do the trick perfectly! - Brian Erst --- Oren Miller <or...@qu...> wrote: > We actually do have a cross platform Event object that should do the > trick with a little modification: > http://cvs.sourceforge.net/viewcvs.py/quickfix/quickfix/src/C%2B%2B/Event.h?rev=1.4&view=markup > > It uses WaitForSingleObject and pthread_cond_timedwait. It is > hardcoded to wait for 100 milliseconds. If we just add a wait() > signature where we can pass in a value for the time, this class would > probably be perfect. > > --oren > ----- Original Message ----- > From: Dale Wilson > Cc: qui...@li... > Sent: Thursday, November 03, 2005 12:54 PM > Subject: Re: [Quickfix-developers] Faster logons > > > Brian Erst wrote: > <SNIP> > I would also suggest that the use of process_sleep is a bad idea - > whenever I need to code a sleep-type function, I use a mutex and a > WaitForSingleObject with the sleep time as the timeout. That way, I > can > interrupt the sleep (by triggering the mutex) if the reason for the > sleep has gone away (or so I don't have to wait 30 seconds to bring > my > application down if I'm sleeping). Makes things much more responsive. > An excellent idea with one very important drawback. > WaitForSingleObject with a timeout is a WIN32 concept. > It is possible, but not necessarily easy, to code an equivalent > functionality on a posix system using pthread_cond_timedwait. > If QuickFIX were going to use this technique someone would have to > beef up its cross-platform thread synchronization support. > > Dale > > > - Brian Erst > Thynk Software, Inc. > > > -- > > ----------------------------------------------------- > Dale Wilson, Senior Software Engineer > Object Computing, Inc. (OCI) > http://www.ociweb.com/ http://www.theaceorb.com/ > ---------------------------------------------------- |
|
From: Oren M. <or...@qu...> - 2005-11-03 19:18:59
|
Yeah, we've been using this to pass messages around with our thread safe queue: http://cvs.sourceforge.net/viewcvs.py/quickfix/quickfix/src/C%2B%2B/Queue.h?view=markup This was being used to pass buffers between the two threads that belong to a ThreadedSocketConnection. With Caleb's latest contribution, we got rid of one of the threads and are no longer using it. Needless to say it's gotten a good production workout over the years. This request comes just in time for us to find another use for it :) --oren ----- Original Message ----- From: "Brian Erst" <azz...@ya...> To: <qui...@li...> Sent: Thursday, November 03, 2005 1:10 PM Subject: Re: [Quickfix-developers] Faster logons QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html QuickFIX Support: http://www.quickfixengine.org/services.html Well, then, just ignore my last message. Sounds like a tweaked Event object will do the trick perfectly! - Brian Erst --- Oren Miller <or...@qu...> wrote: > We actually do have a cross platform Event object that should do the > trick with a little modification: > http://cvs.sourceforge.net/viewcvs.py/quickfix/quickfix/src/C%2B%2B/Eventh?rev=1.4&view=markup. > > It uses WaitForSingleObject and pthread_cond_timedwait. It is > hardcoded to wait for 100 milliseconds. If we just add a wait() > signature where we can pass in a value for the time, this class would > probably be perfect. > > --oren > ----- Original Message ----- > From: Dale Wilson > Cc: qui...@li... > Sent: Thursday, November 03, 2005 12:54 PM > Subject: Re: [Quickfix-developers] Faster logons > > > Brian Erst wrote: > <SNIP> > I would also suggest that the use of process_sleep is a bad idea - > whenever I need to code a sleep-type function, I use a mutex and a > WaitForSingleObject with the sleep time as the timeout. That way, I > can > interrupt the sleep (by triggering the mutex) if the reason for the > sleep has gone away (or so I don't have to wait 30 seconds to bring > my > application down if I'm sleeping). Makes things much more responsive. > An excellent idea with one very important drawback. > WaitForSingleObject with a timeout is a WIN32 concept. > It is possible, but not necessarily easy, to code an equivalent > functionality on a posix system using pthread_cond_timedwait. > If QuickFIX were going to use this technique someone would have to > beef up its cross-platform thread synchronization support. > > Dale > > > - Brian Erst > Thynk Software, Inc. > > > -- > > ----------------------------------------------------- > Dale Wilson, Senior Software Engineer > Object Computing, Inc. (OCI) > http://www.ociweb.com/ http://www.theaceorb.com/ > ---------------------------------------------------- ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Brian E. <azz...@ya...> - 2005-11-03 19:08:33
|
Dale - I figured pthreads (Posix threads) would probably have some issues there, but there are several ways to work around it. One way is to do the heavy lifting of writing the proper Posix code to do it. It certainly isn't as clean as the equivalent Win32 code, but I believe it is doable. Another way is to use a phony mutex. Make a minor modification of the Posix code to loop around a smaller timeout (1 second or less). The "interrupt" method for the Posix port could set a variable (posixSleepInterruptPhonyMutex=true) that is checked at the top of the loop and drop out if it has been set. Reset the variable to false when you drop out of the loop. Simple to code, but not nearly as "elegant". Lastly, you could simply NOP the "interrupt" method for the Posix port until we decide on a good solution. The Posix port would be less optimal than the Win32 version, but no worse than the current version. - Brian Erst Thynk Software, Inc. --- Dale Wilson <wil...@oc...> wrote: > Brian Erst wrote: > > ><SNIP> > >I would also suggest that the use of process_sleep is a bad idea - > >whenever I need to code a sleep-type function, I use a mutex and a > >WaitForSingleObject with the sleep time as the timeout. That way, I > can > >interrupt the sleep (by triggering the mutex) if the reason for the > >sleep has gone away (or so I don't have to wait 30 seconds to bring > my > >application down if I'm sleeping). Makes things much more > responsive. > > > > > An excellent idea with one very important drawback. > WaitForSingleObject > with a timeout is a WIN32 concept. > It is possible, but not necessarily easy, to code an equivalent > functionality on a posix system using |pthread_cond_timedwait. > If QuickFIX were going to use this technique someone would have to > beef > up its cross-platform thread synchronization support. > > Dale > > | > > >- Brian Erst > >Thynk Software, Inc. > > > > > > > > > -- > > ----------------------------------------------------- > Dale Wilson, Senior Software Engineer > Object Computing, Inc. (OCI) > http://www.ociweb.com/ http://www.theaceorb.com/ > ---------------------------------------------------- > > |
|
From: Oren M. <or...@qu...> - 2005-11-03 19:05:28
|
The session is probably waiting for the ReconnectInterval to pass before attempting the logon. We should probably force the session to connect at the following next() call in this scenario. --oren ----- Original Message ----- From: "Brian Erst" <azz...@ya...> To: <qui...@li...> Sent: Thursday, November 03, 2005 11:39 AM Subject: [Quickfix-developers] Faster logons QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html QuickFIX Support: http://www.quickfixengine.org/services.html I have a new C# FIX application that requires a manual login/logout process. Users need to be able to login to my test server and logout multiple times, so I have two big buttons to do this. The problem is that logging in takes a very long time. The C# version of the library seems to have problems with repeated calls to the threaded initiator's start() and stop() methods, so I start() the initiator at application start up and immediately logout the created session (during the onCreate() callback). I then use the session's logon() and logout() methods to log the session on and off. Logging off is nearly instantaneous, but logging on is generally slow. Looking at the code, both methods simply set the value of m_enabled on the session. Presumably, logging off is quick because next() is constantly being called while a session is active and the m_enabled flag change is being picked up quickly. Logging on, however, can take upwards of 30 seconds. Again, this is presumably because while a session is logged out there is some sort of timeout or delay between checks of the m_enabled flag. Considering that prior to each login, I see the "Connecting to [IP address] on port [#]", it would appear it is some sort of delay prior to spawning the socketThread (the first time) and then the use of m_reconnectInterval and process_sleep (subsequent times). Aside from fixing the .NET code so that initiator start/stop cycles don't cause the code to hang, is there any way of speeding up the logon process? My sneaking suspicion is no, but it doesn't hurt to ask... I would also suggest that the use of process_sleep is a bad idea - whenever I need to code a sleep-type function, I use a mutex and a WaitForSingleObject with the sleep time as the timeout. That way, I can interrupt the sleep (by triggering the mutex) if the reason for the sleep has gone away (or so I don't have to wait 30 seconds to bring my application down if I'm sleeping). Makes things much more responsive. - Brian Erst Thynk Software, Inc. ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
