quickfix-developers — QuickFIX developers forum

Re: [Quickfix-developers] Re: monitor the FIX connection failure programmatically?

[Oren M. <or...@qu...>]

You can use Session::isSessionTime() to determine if you are within the =
start and end times.  The hearbeat interval has nothing to do with when =
the session disconnects.

--oren
  ----- Original Message -----=20
  From: Alvin Wang=20
  To: Caleb Epstein=20
  Cc: Oren Miller ; qui...@li... ; =
qui...@li...=20
  Sent: Friday, November 04, 2005 1:48 PM
  Subject: Re: [Quickfix-developers] Re: monitor the FIX connection =
failure programmatically?



  Caleb, we want to differentiate the normal logout/disconnect at the =
end of day, and the abnormal logout/disconnect during the session. (is =
it safe to assume that onLogout will not be called between Endtime and =
StartTime?) So my question is, can we use isLoggedOn method inside =
onLogout to make above judgement? If isLoggedOn=3Dtrue, it is abnormal.=20

  Or, what is the algorithm to decide exact when the initiator will =
disconnect at (around) the EndTime? For example, the EndTime is 22:00:00 =
and heartbeat interval is 30 seconds. Now the initiator sends a =
heartbeat at 21:59:10.  will the initiator disconnect at 21:59:40 or =
22:00:10?=20

  Many thanks=20
  Alvin=20




       Caleb Epstein <cal...@gm...>=20
        Sent by: qui...@li...=20
        11/04/2005 10:35 AM=20

              =20
                To:        Alvin Wang <AW...@ff...>=20
                cc:        Oren Miller <or...@qu...>, =
qui...@li..., =
qui...@li...=20
                bcc:        =20
                Subject:        Re: [Quickfix-developers] Re: monitor =
the FIX connection failure    programmatically?=20



  On 11/4/05, Alvin Wang <AW...@ff...> wrote:=20

  So does it mean even when the physics connection is down and we did =
not receive logout msg, onLogout will still be invoked? If so, how can =
we tell if it is an abnormal logout/disconnection?=20

  Not trying to argue, but what if the FIX session is not never setup =
from beginning due to network problem? Will onLogout be called?=20


  I wouldn't call asking questions being argumentative :)=20

  No, if a connection never comes up you'll never get an onLogout =
callback.

  I have implemented some monitoring of QuickFIX connections by making =
use of the onLogon/onLogout callback (for immediate notification when a =
connection comes up or goes down) coupled with a thread that iterates =
through all known sessions and uses FIX::Session::lookupSession + =
Session::isLoggedOn to capture those connections that either never come =
up or are outside their StartTime/EndTime windows.=20

  Pseudocode:

  foreach (SessionID as id)
  {
    Session* sess =3D Session::lookupSession (id);
    if (!sess) continue;
    send_connection_status (id, sess->isLoggedOn () ? "UP" : "DOWN");=20
  }=20

  --=20
  Caleb Epstein
  caleb dot epstein at gmail dot com=20

  ********************************************************************** =
This e-mail message is intended solely for the use of the addressee. The =
message may contain information that is privileged and confidential. =
Disclosure to anyone other than the intended recipient is prohibited. If =
you are not the intended recipient, please do not disseminate, =
distribute or copy this communication, by e-mail or otherwise. Instead, =
please notify us immediately by return e-mail (including the original =
message with your reply) and then delete and discard all copies of the =
message. We have taken precautions to minimize the risk of transmitting =
software viruses but nevertheless advise you to carry out your own virus =
checks on any attachment to this message. We accept no liability for any =
loss or damage caused by software viruses. =
********************************************************************** 

Re: [Quickfix-developers] Re: monitor the FIX connection failure programmatically?

[Caleb E. <cal...@gm...>]

On 11/4/05, Alvin Wang <AW...@ff...> wrote:

So does it mean even when the physics connection is down and we did not
> receive logout msg, onLogout will still be invoked? If so, how can we tel=
l
> if it is an abnormal logout/disconnection?
>
> Not trying to argue, but what if the FIX session is not never setup from
> beginning due to network problem? Will onLogout be called?



I wouldn't call asking questions being argumentative :)

No, if a connection never comes up you'll never get an onLogout callback.

I have implemented some monitoring of QuickFIX connections by making use of
the onLogon/onLogout callback (for immediate notification when a connection
comes up or goes down) coupled with a thread that iterates through all know=
n
sessions and uses FIX::Session::lookupSession + Session::isLoggedOn to
capture those connections that either never come up or are outside their
StartTime/EndTime windows.

Pseudocode:

foreach (SessionID as id)
{
Session* sess =3D Session::lookupSession (id);
if (!sess) continue;
send_connection_status (id, sess->isLoggedOn () ? "UP" : "DOWN");
}

--
Caleb Epstein
caleb dot epstein at gmail dot com

Re: [Quickfix-developers] monitor the FIX connection failure programmatically?

[Caleb E. <cal...@gm...>]

On 11/4/05, Francis Gingras <fr...@at...> wrote:
>
> Isn't that what the heartbeat is for?
>

Well, it can be useful for an Application to be notified of the status of a
connection when it comes up/goes down. For example, you might want to alert
users, change the routing behavior of a trading engine, etc. Heartbeats are
just a protocol level detail.


--
Caleb Epstein
caleb dot epstein at gmail dot com

RE: [Quickfix-developers] monitor the FIX connection failure programmatically?

[Francis G. <fr...@at...>]

Isn't that what the heartbeat is for?
 
Francis

  _____  

From: Alvin Wang [mailto:AW...@FF...] 
Sent: Friday, November 04, 2005 14:54
To: Oren Miller
Cc: qui...@li...;
qui...@li...
Subject: [Quickfix-developers] Re: monitor the FIX connection failure
programmatically?



Oren, thanks! 
So does it mean even when the physics connection is down and we did not
receive logout msg, onLogout will still be invoked? If so, how can we tell
if it is an abnormal logout/disconnection? 

Not trying to argue, but what if the FIX session is not never setup from
beginning due to network problem? Will onLogout be called? 

Thanks 
Alvin 





	"Oren Miller" <or...@qu...> 


11/04/2005 09:38 AM 


        
        To:        <qui...@li...>,
<qui...@li...>, "Alvin Wang"
<AW...@FF...> 
        cc:         
        bcc:         
        Subject:        Re: monitor the FIX connection failure
programmatically?



The onLogout callback would tell you anytime a sessions connection is lost. 
  
--oren 
----- Original Message ----- 
From:  <mailto:AW...@FF...> Alvin Wang 
To:  <mailto:qui...@li...>
qui...@li... ;
<mailto:qui...@li...>
qui...@li... ;
<mailto:or...@qu...> Oren Miller 
Sent: Friday, November 04, 2005 1:40 PM 
Subject: monitor the FIX connection failure programmatically? 


Hi, 

How can I monitor the FIX connection failure? I know I can tell from
quickfix event log. But is there a way that my code can be notified
programmatically such as "onEvent()"? The problem we are experiencing is
that we did not know the connection was down in production for 2 hours until
a trader tried to send an order via FIX. 

many thanks! 
Alvin **********************************************************************
This e-mail message is intended solely for the use of the addressee. The
message may contain information that is privileged and confidential.
Disclosure to anyone other than the intended recipient is prohibited. If you
are not the intended recipient, please do not disseminate, distribute or
copy this communication, by e-mail or otherwise. Instead, please notify us
immediately by return e-mail (including the original message with your
reply) and then delete and discard all copies of the message. We have taken
precautions to minimize the risk of transmitting software viruses but
nevertheless advise you to carry out your own virus checks on any attachment
to this message. We accept no liability for any loss or damage caused by
software viruses.
********************************************************************** 

[Quickfix-developers] use of fromAdmin callback

[Shankar K. <skr...@jw...>]

 

I am sending back a test request or a resend request as requested by the
acceptor application,

 

I am coding the fromAdmin handler and checking for msgType(35)  value = 1
and act on it similarily for value = 2

act on it.

 

Is this the right approach ?

 

-

Thanks

 

[Quickfix-developers] Re: monitor the FIX connection failure programmatically?

[Alvin W. <AW...@FF...>]

Oren, thanks!
So does it mean even when the physics connection is down and we did not 
receive logout msg, onLogout will still be invoked? If so, how can we tell 
if it is an abnormal logout/disconnection?

Not trying to argue, but what if the FIX session is not never setup from 
beginning due to network problem? Will onLogout be called?

Thanks
Alvin






"Oren Miller" <or...@qu...>
11/04/2005 09:38 AM

 
        To:     <qui...@li...>, 
<qui...@li...>, "Alvin Wang" 
<AW...@FF...>
        cc: 
        bcc: 
        Subject:        Re: monitor the FIX connection failure programmatically?


The onLogout callback would tell you anytime a sessions connection is 
lost.
 
--oren
----- Original Message ----- 
From: Alvin Wang 
To: qui...@li... ; qui...@li... ; Oren Miller 
Sent: Friday, November 04, 2005 1:40 PM
Subject: monitor the FIX connection failure programmatically?


Hi, 

How can I monitor the FIX connection failure? I know I can tell from 
quickfix event log. But is there a way that my code can be notified 
programmatically such as "onEvent()"? The problem we are experiencing is 
that we did not know the connection was down in production for 2 hours 
until a trader tried to send an order via FIX. 

many thanks! 
Alvin ********************************************************************** 
This e-mail message is intended solely for the use of the addressee. The 
message may contain information that is privileged and confidential. 
Disclosure to anyone other than the intended recipient is prohibited. If 
you are not the intended recipient, please do not disseminate, distribute 
or copy this communication, by e-mail or otherwise. Instead, please notify 
us immediately by return e-mail (including the original message with your 
reply) and then delete and discard all copies of the message. We have 
taken precautions to minimize the risk of transmitting software viruses 
but nevertheless advise you to carry out your own virus checks on any 
attachment to this message. We accept no liability for any loss or damage 
caused by software viruses. 
********************************************************************** 

[Quickfix-developers] Re: monitor the FIX connection failure programmatically?

[Oren M. <or...@qu...>]

The onLogout callback would tell you anytime a sessions connection is =
lost.

--oren
  ----- Original Message -----=20
  From: Alvin Wang=20
  To: qui...@li... ; =
qui...@li... ; Oren Miller=20
  Sent: Friday, November 04, 2005 1:40 PM
  Subject: monitor the FIX connection failure programmatically?



  Hi,=20

  How can I monitor the FIX connection failure? I know I can tell from =
quickfix event log. But is there a way that my code can be notified =
programmatically such as "onEvent()"? The problem we are experiencing is =
that we did not know the connection was down in production for 2 hours =
until a trader tried to send an order via FIX.=20

  many thanks!=20
  Alvin =
********************************************************************** =
This e-mail message is intended solely for the use of the addressee. The =
message may contain information that is privileged and confidential. =
Disclosure to anyone other than the intended recipient is prohibited. If =
you are not the intended recipient, please do not disseminate, =
distribute or copy this communication, by e-mail or otherwise. Instead, =
please notify us immediately by return e-mail (including the original =
message with your reply) and then delete and discard all copies of the =
message. We have taken precautions to minimize the risk of transmitting =
software viruses but nevertheless advise you to carry out your own virus =
checks on any attachment to this message. We accept no liability for any =
loss or damage caused by software viruses. =
********************************************************************** 

[Quickfix-developers] monitor the FIX connection failure programmatically?

[Alvin W. <AW...@FF...>]

Hi,

How can I monitor the FIX connection failure? I know I can tell from 
quickfix event log. But is there a way that my code can be notified 
programmatically such as "onEvent()"? The problem we are experiencing is 
that we did not know the connection was down in production for 2 hours 
until a trader tried to send an order via FIX.

many thanks!
Alvin
                                                                                                                                                                                                                                                                                                    **********************************************************************
This e-mail message is intended solely for the use of the addressee.
The message may contain information that is privileged and confidential.  
Disclosure to anyone other than the intended recipient is
prohibited. If you are not the intended recipient, please do not
disseminate, distribute or copy this communication, by e-mail or
otherwise. Instead, please notify us immediately by return e-mail
(including the original message with your reply) and then delete
and discard all copies of the message. We have taken precautions to
minimize the risk of transmitting software viruses but nevertheless
advise you to carry out your own virus checks on any attachment to
this message.  We accept no liability for any loss or damage caused
by software viruses.
**********************************************************************

Re: [Quickfix-developers] Faster logons

[Oren M. <or...@qu...>]

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

Re: [Quickfix-developers] Faster logons

[Brian E. <azz...@ya...>]

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

Re: [Quickfix-developers] Faster logons

[Brian E. <azz...@ya...>]

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

Re: [Quickfix-developers] Faster logons

[Oren M. <or...@qu...>]

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

Re: [Quickfix-developers] Faster logons

[Dale W. <wil...@oc...>]

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

Re: [Quickfix-developers] Faster logons

[Oren M. <or...@qu...>]

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

Re: [Quickfix-developers] Faster logons

[Dale W. <wil...@oc...>]

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

Re: [Quickfix-developers] Re: Week Long Sessions

[Caleb E. <cal...@gm...>]

On 11/3/05, Michael Holm <mh...@li...> wrote:
>
> I am using the week long session functionality. Our client QuickFix
> application machine is set to EST (UTC+11) and the Fix Engine which I
> connect to is set to UTC. So at 11am (UTC midnight) QuickFix will
> disconnect our connection and we experience ~1 minute downtime while we
> re-sync with the exchange. Our session crosses the UTC midnight barrier.
>
> This line is what is causing the problem:
>
> *return tm1.tm_year =3D=3D tm2.tm_year && tm1.tm_yday =3D=3D tm2.tm_yday;=
*
>

With the latest code in CVS, the following tests pass:

// Michael Holm's test case:

// StartTime and EndTime are 21:00 UTC
start =3D UtcTimeOnly (21, 0, 0);
end =3D UtcTimeOnly (21, 0, 0);

// Sunday -> Friday
int startDay =3D 1; // Sunday
int endDay =3D 6; // Friday

// Check Mon 2005-10-31 00:00:00Z vs. Thu 2005-11-03 00:00:00Z
time1 =3D UtcTimeStamp (0, 0, 0, 31, 10, 2005);
time2 =3D UtcTimeStamp (0, 0, 0, 3, 11, 2005);

assert (SessionTime::isSameSession (start, end, startDay, endDay,
time1, time2));

// Check Mon 2005-10-31 00:00:00Z vs. Thu 2005-11-04 21:00:00Z
time2 =3D UtcTimeStamp (21, 0, 0, 3, 11, 2005);

assert (SessionTime::isSameSession (start, end, startDay, endDay,
time1, time2));

// Check Mon 2005-10-31 00:00:00Z vs. Thu 2005-11-04 21:00:01Z
time2 =3D UtcTimeStamp (21, 0, 1, 3, 11, 2005);

assert (SessionTime::isSameSession (start, end, startDay, endDay,
time1, time2));

// Check Mon 2005-10-31 00:00:00Z vs. Fri 2005-11-04 21:00:00Z
time2 =3D UtcTimeStamp (21, 0, 0, 4, 11, 2005);

assert (SessionTime::isSameSession (start, end, startDay, endDay,
time1, time2));

// Check Mon 2005-10-31 00:00:00Z vs. Fri 2005-11-04 21:00:01Z
time2 =3D UtcTimeStamp (21, 0, 1, 4, 11, 2005);

assert (!SessionTime::isSameSession (start, end, startDay, endDay,
time1, time2));


--
Caleb Epstein
caleb dot epstein at gmail dot com

[Quickfix-developers] Faster logons

[Brian E. <azz...@ya...>]

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.

[Quickfix-developers] Re: Week Long Sessions

[Michael H. <mh...@li...>]

QuickFix Version: 1.94

=20

Problem Summary:

=20

I am using the week long session functionality. Our client QuickFix =
application machine is set to EST (UTC+11) and the Fix Engine which I =
connect to is set to UTC. So at 11am (UTC midnight) QuickFix will =
disconnect our connection and we experience ~1 minute downtime while we =
re-sync with the exchange. Our session crosses the UTC midnight barrier. =


=20

Solution:

=20

In the SessionTime.cpp file you need to modify this method:=20

bool SessionTime::isSameSession( const UtcTimeOnly& startTime, const =
UtcTimeOnly& endTime, int startDay, int endDay, const UtcTimeStamp& =
time1, const UtcTimeStamp& time2 )

=20

This line is what is causing the problem:

return tm1.tm_year =3D=3D tm2.tm_year && tm1.tm_yday =3D=3D tm2.tm_yday;

=20

Since we cross over the UTC midnight mark tm2.tm_yday is 1 day greater =
then tm1.tm_yday. This causes QuickFix to disconnect because it assumes =
it=92s a different session. This problem does not occur if both =
applications run on a machine with both time zones set to UTC. I changed =
the time_localtime function to use gmtime instead of localtime and this =
fix my problem.=20

=20

I believe this case should be added to the test scripts.=20

=20

Thanks

Michael Holm

=20


--=20
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.12.7/157 - Release Date: =
02/11/2005
=20

[Quickfix-developers] ThreadedSocketAcceptor Segmentation Faults

[Guillermo A. A. <gar...@vi...>]

Hi all,

Since I upgraded to Quickfix 1.10.2 (prior we were using 1.9.4) i'm =
getting
a random segmentation fault when sessions log off. I couldn't find a =
pattern
to reproduce it, or even a "more probable" scenario, it just happens =
from
time to time.

Before entering a bug report, i'd like to know if someone has faced this =
(or
similar) problem, or if someone thinks the problem is on my side.

All the dumped cores from this segmentation fault read the same:

#0  0x00cb8b60 in pthread_detach () from /lib/tls/libpthread.so.0
#1  0x00870b97 in FIX::thread_detach (thread=3D0) at Utility.cpp:344
#2  0x0081d4c8 in FIX::ThreadedSocketAcceptor::removeThread =
(this=3D0x8f596c8,
    s=3D19) at stl_map.h:221
#3  0x0081d5e7 in FIX::ThreadedSocketAcceptor::socketThread =
(p=3D0xf6a8a10)
    at ThreadedSocketConnection.h:51
#4  0x00cb7dec in start_thread () from /lib/tls/libpthread.so.0
#5  0x006f0a2a in clone () from /lib/tls/libc.so.6

At Level #2, the Acceptor member m_threads shows a suspicious =
"_M_node_count
=3D 0" which can lead to the thread=3D0 passed to thread_detach and =
causes the
segfault

I'm not sure if faulty code on my side can lead to that errors, but i've
found that problem in all my developments using a ThreadAcceptor, =
ranging
from a single FIX logger to a monstrous routing system.

I'm compiling QFix with mysql support (MySQL ver 4.14) on RedHat =
Enterprise
3 servers.
Some system libs:
glibc-devel-2.3.2.-95.3x (pthreads)
libstdc++-devel-3.2.3-52 (stl)

Thanks in advance and cheers (again) for your great work

Guillermo


****************************** AVISO LEGAL =
******************************
La informaci=F3n contenida en este mensaje es para uso exclusivo de su =
destinatario. No debe copiarse, transmitirse a terceros ni guardarse por =
estos =FAltimos, salvo autorizaci=F3n del remitente.
Puede contener informaci=F3n confidencial o legalmente protegida cuyo =
r=E9gimen legal de utilizaci=F3n no se ve afectado por el hecho de que =
haya sido enviada por correo electr=F3nico.
Su env=EDo por error a una persona distinta de su destinatario real no =
implica que se haya modificado tal destinatario ni supone renuncia a su =
eventual car=E1cter confidencial o al r=E9gimen legal que rija su =
utilizaci=F3n.
Cualquier opini=F3n expresada en este mensaje vincular=E1 exclusivamente =
a la persona que lo haya remitido, excepto cuando el mensaje establezca =
lo contrario y el remitente est=E9 autorizado para establecer que dichas =
opiniones vincular=E1n a esta entidad.
En el supuesto de que este correo se recibiera por error, rogamos =
procedan a borrarlo, sin reenviarlo a terceros ni conservarlo en =
cualquier soporte y nos informen inmediatamente llamando al tel=E9fono =
34 91 5892123 o a la direcci=F3n de correo electr=F3nico remitente. =
Gracias.
****************************** DISCLAIMER ******************************
The information contained in this message is for the exclusive use of =
the named person. It can not be copied, transmitted to third parties or =
stored by the latter, except if authorised by the sender.
It may contain confidential or legally privileged information whose =
legal regime is not affected by the fact that this information has been =
sent by e-mail.=20
Its erroneous transmission to a person other than the real named person =
neither implies any modification of this named person nor a renunciation =
of the eventual confidentiality or legal regime affecting the use of =
concerned message.
Any views expressed in this message are binding exclusively upon the =
individual sender, except where the message states otherwise and the =
sender is authorised to bind this entity.=20
If you receive this message in error, please delete it without =
transmitting it to any third party or keeping it in any form and notify =
us immediately either by phone (34 91 5892123) or using the e- mail =
address of the sender. Thank You.

[Quickfix-developers] Week Long Sessions

[Michael H. <mh...@li...>]

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

Re: [Quickfix-developers] How to implement the QF/J failover sulotion.

[Lin L. <le...@gm...>]

Hi,Steve
  The solution which I implemented has not modify any code of QF/J
excluding the JdbcStore code.So,when the active instance disconnected
cause by network or other server errors,the client will create a new
connection with TCP switch and connect to the another server instance
IP address actually.And the relogining action is required.These don't
base on the TCP level,but fix session level.
  The TCP level failover should be a better choice and also maybe
cause more codes changing.Maybe it require a private protocol about
server notification.If the first connection of active instance failed
in errors,the TCP switch maybe return a fix reject or fail fix message
to client(Maybe the client fix request is succed and the server fix
reply fail in error,but the client don't know). And the client is
connected to another server by TCP switch in TCP level(The connection
of client and TCP switch does not disconnect so the client consider
all are OK but only a reject or fail fix session message reply
return.).The idle server instance copy(or read from db) all the active
instance states and start up to service.
  Is above OK?We should make the TCP swich knowing fix protocol,I
think,named FIX switch(Of couse,as now,I take some java codes as a TCP
switch simulator).
My first failover solution is not perfect but easy to be
implemented.Making it working is the first step,I think:)
  Also,there are some problems in my first simple failover
solution.When client failover from server1 to server2,it succeed.Next,
client failover from server2 to server1,it cause error in server1
'Invalid state'(Is the client not clear session sate after
disconneced?).And If I restart the client appliction,it get to work. I
don't know why now.

Lin Lejiang



On 10/29/05, Steve Bate <st...@te...> wrote:
> Hello Lin,
>
> I'd like to hear more about how you are implementing the
> failover. Maybe we could add more direct support in the
> code for it.
>
> Are you saying the reconnect to the idle instance would happen
> at the TCP level (rather than a reconnect, relogon by the client)?
> If so, your strategy for disabling the caching may work, but I'm
> wondering about the other transient state in the session. For example,
> information about whether a logon has been received for a specific
> session instance. The failover Session instance may have problems
> if some of this transient state data is not consistent with what
> the client expects. This may cause problems with behaviors
> like session logout since it expects to have seen a logon
> at some point in the session history.
>
> Does your idle server receive an explicit notification when it
> becomes active? If so, maybe the transient state could be
> set up correctly at that time.
>
> Have you built a prototype of your failover solution?
>
> Regards,
>
> Steve
>
> > -----Original Message-----
> > From: qui...@li...
> > [mailto:qui...@li...] On
> > Behalf Of Lin Lejiang
> > Sent: Thursday, October 27, 2005 6:13 AM
> > To: qui...@li...
> > Subject: [Quickfix-developers] How to implement the QF/J
> > failover sulotion.
> >
> > QuickFIX Documentation:
> > http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> >
> > Hi,
> >   I try to deploy qf/j as fix engine in my project.I need
> > double servers redundantly for failover.I have seen the topic
> > about load balance and qf not support now.
> >   The two qf/j instances share the same store data(same jdbc
> > data source).The client connected to one of them throgh a TCP
> > switch,e.g.F5.And another instance is in idle state.The fix
> > messages and SeqNum could have the right value when the
> > client connection reconnect switching to the another qf/j
> > instance.This is the process of qf/j failover in my project plan.
> >   The qf/j default JdbcStore/MysqlStore cache the session
> > data in memory but not direct read from db.So the qf/j
> > instances initialize the state and cache the state data from
> > db after start up.The SeqNum of qf/j instance  increase in
> > service,but the another one cache the old SeqNum in memory
> > because not in service.
> >   So,I implement my JdbcSybaseStore to remove the cache
> > feature.And then the qf/j failover start to work OK.Of
> > cause,I lost little perfomance in read/write db.
> >   I want to deploy this qf/j failover solution in my real
> > project.Is it OK?Can someone have a better solution for failover?
> >
> > --
> > Lin Lejiang
> >
> >
> >
> > quote:
> > Session management in load balanced situation?
> > http://sourceforge.net/mailarchive/message.php?msg_id=3D11104323
> >  On Tue, 8 Mar 2005 12:57:38 -0600, David Kuik
> > <david.kuik@pr...> wrote:
> >
> >  > I"m wondering how the engine manages sessions and message
> > sequencing in a  > load balanced environment.  Does each
> > server in the farm to manage a  > separate session or do they
> > somehow share a session?
> >  >
> >  > I"m trying to understand how this will work in a
> > fault-tolerant 7x24  > environment that supports 1000"s of
> > users.  Can someone offer some comments?
> >
> >  You could load balance sessions across multiple machines
> > using a  database-backed message store (e.g.
> > MysqlStoreFactory).  All of the  session state is persisted
> > to the database.  You could run a number of  Acceptors in
> > parallel on different machines, each configured to accept
> > all of your MySQL-backed sessions (e.g. same config file).
> >
> >  However I don"t think there is currently a facility in QF
> > for  "locking" a session across multiple engines.  In other
> > words, if  client A connects to server 1, that session should
> > be "locked" in some  way so any attempt to use it on servers
> > 2 through n would result in an  error in the same way that
> > connecting to that session a second time on  server 1 would.
> >
> >  A similar approach would be to use the FileStoreFactory and
> > share all  the session state on an NFS mounted filesystem.
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by the JBoss Inc.
> > Get Certified Today * Register for a JBoss Training Course
> > Free Certification Exam for All Training Attendees Through
> > End of 2005 Visit http://www.jboss.com/services/certification
> > for more information _______________________________________________
> > Quickfix-developers mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> >
>
>


--
Lin Lejiang

Re: [Quickfix-developers] ThreadedSocketConnection: fix for memory growth under heavy load

[Oren M. <or...@qu...>]

I checked in your patch.  I did reintroduce the second thread so that it =
can call the next() method every second.  The queue processing is gone.  =
Since recv block indefinately I'm not sure if there is another solution =
without having a second thread.  Can you think of anything?  Another =
possibility would be to have just one thread for the Acceptor/Initiator =
which will call next on all of its sessions.  This way where n =3D =
number of sessions, we can cut the number of threads down from 2*n to n =
+ 1.

--oren

--oren
  ----- Original Message -----=20
  From: Oren Miller=20
  To: Caleb Epstein=20
  Cc: qui...@li...=20
  Sent: Friday, October 28, 2005 9:19 PM
  Subject: Re: [Quickfix-developers] ThreadedSocketConnection: fix for =
memory growth under heavy load


  I was testing this and a problem I noticed is that there is nothing =
calling Session::next().  Previously the thread waiting on the queue =
would timeout every second and this method would get called (via =
processStream).  This processes heartbeats and such.  With this patch, =
none of this is occuring, causing many acceptance tests to fail.

  --oren
    ----- Original Message -----=20
    From: Caleb Epstein=20
    To: Oren Miller=20
    Cc: qui...@li...=20
    Sent: Wednesday, October 19, 2005 2:12 PM
    Subject: Re: [Quickfix-developers] ThreadedSocketConnection: fix for =
memory growth under heavy load


    On 10/19/05, Caleb Epstein <cal...@gm...> wrote:


      Attached is a complete patch which removes the extra thread from =
ThreadedSocketConnection as well as the functions and members which are =
no longer needed once its gone.

    Here's a slightly revised patch (one line change).  I needed to move =
the call to processStream before the recv call otherwise Initiators =
would not logon correctly.  I've now tested this code with both =
Initiators and Acceptors.


    --=20
    Caleb Epstein
    caleb dot epstein at gmail dot com 

[Quickfix-developers] QuickFix/J Disconnection error, termination questions, message crack

[Andrew W. <awi...@ca...>]

Item 1)  After a successful connection and heartbeats established, a
initiator.stop(true)  causes an exception.  See short logs and messages
below.  I can successfully Is this something to be concerned about?  See the
logs below...

Item 2)  If the initiator does not successfully establish a connection -
what I mean by this is that a logon is rejected because a seqnum is
incorrect, I cannot gracefully exit my application because it appears that
the underlying quickfix process does not respond to initiator.stop() and
gracefully terminate.  I must force a System.exit() call to terminate.  I am
only concerned that "something" in the quickfix application may fail to
cleanly shutdown and prevent subsequent reconnections.

Item 3) In the QuickFix documentation there appears to be a "crack" method
that is the "Best" implementation of interpretting FromAdmin messages.  Does
the QuickFix/J lib have no equivalent at the moment?

I am using Sun's JDK 1.5.0_04 on Linux.

Thanks,

Andrew


<20051029-18:37:20, FIX.4.2:CLIENT->PROVIDER, outgoing>
(8=FIX.4.2~9=70~35=A~34=26~49=CLIENT~52=20051029-18:37:20.864~56=PROVIDER~98
=0~108=30~10=112~)
<20051029-18:37:20, FIX.4.2:CLIENT->PROVIDER, event> (Initiated logon
request)
<20051029-18:37:20, FIX.4.2:CLIENT->PROVIDER, incoming>
(8=FIX.4.2~9=77~35=A~49=PROVIDER~56=CLIENT~43=N~34=44~52=20051029-18:35:40~9
8=0~108=30~141=N~10=188~)
<20051029-18:37:20, FIX.4.2:CLIENT->PROVIDER, event> (Received logon
response)
<20051029-18:37:51, FIX.4.2:CLIENT->PROVIDER, incoming>
(8=FIX.4.2~9=59~35=0~49=PROVIDER~56=CLIENT~43=N~34=45~52=20051029-18:36:10~1
0=111~)
<20051029-18:37:51, FIX.4.2:CLIENT->PROVIDER, outgoing>
(8=FIX.4.2~9=58~35=0~34=27~49=CLIENT~52=20051029-18:37:51.321~56=PROVIDER~10
=069~)
Terminate requested
<20051029-18:37:58, FIX.4.2:CLIENT->PROVIDER, event> (Initiated logout
request)
<20051029-18:37:58, FIX.4.2:CLIENT->PROVIDER, outgoing>
(8=FIX.4.2~9=58~35=5~34=28~49=CLIENT~52=20051029-18:37:58.823~56=PROVIDER~10
=089~)
Exception in thread "Timer-0" java.lang.IllegalStateException: IoProcessor
is not started.
        at
net.gleamynode.netty2.IoProcessor.ensureStarted(IoProcessor.java:303)
        at
net.gleamynode.netty2.IoProcessor.notifyWriteRequest(IoProcessor.java:292)
        at net.gleamynode.netty2.Session.write(Session.java:319)
        at net.gleamynode.netty2.Session.write(Session.java:302)
        at
quickfix.netty.AbstractSocketInitiator$SessionConnection$QuickFixSessionResp
onder.send(AbstractSocketInitiator.java:415)
        at quickfix.Session.send(Session.java:1426)
        at quickfix.Session.sendRaw(Session.java:1386)
        at quickfix.Session.generateLogout(Session.java:749)
        at quickfix.Session.generateLogout(Session.java:740)
        at quickfix.Session.next(Session.java:1056)
        at
quickfix.netty.AbstractSocketInitiator.processTimerEvent(AbstractSocketIniti
ator.java:210)
        at quickfix.SocketInitiator.onTimerEvent(SocketInitiator.java:109)
        at
quickfix.netty.AbstractSocketInitiator$SessionConnection.onTimerEvent(Abstra
ctSocketInitiator.java:322)
        at
quickfix.netty.AbstractSocketInitiator$SessionTimerTask.run(AbstractSocketIn
itiator.java:150)
        at java.util.TimerThread.mainLoop(Timer.java:512)
        at java.util.TimerThread.run(Timer.java:462)

Re: [Quickfix-developers] ThreadedSocketConnection: fix for memory growth under heavy load

[Oren M. <or...@qu...>]

I was testing this and a problem I noticed is that there is nothing =
calling Session::next().  Previously the thread waiting on the queue =
would timeout every second and this method would get called (via =
processStream).  This processes heartbeats and such.  With this patch, =
none of this is occuring, causing many acceptance tests to fail.

--oren
  ----- Original Message -----=20
  From: Caleb Epstein=20
  To: Oren Miller=20
  Cc: qui...@li...=20
  Sent: Wednesday, October 19, 2005 2:12 PM
  Subject: Re: [Quickfix-developers] ThreadedSocketConnection: fix for =
memory growth under heavy load


  On 10/19/05, Caleb Epstein <cal...@gm...> wrote:


    Attached is a complete patch which removes the extra thread from =
ThreadedSocketConnection as well as the functions and members which are =
no longer needed once its gone.

  Here's a slightly revised patch (one line change).  I needed to move =
the call to processStream before the recv call otherwise Initiators =
would not logon correctly.  I've now tested this code with both =
Initiators and Acceptors.


  --=20
  Caleb Epstein
  caleb dot epstein at gmail dot com 

[Quickfix-developers] custom repeating group or custom tag in standard repeating group

[Alvin W. <AW...@FF...>]

Hi,

I wonder if QF can be more lenient towards custom repeating group or=20
custom tag in standard repeating group? Currently, because the dictionary=20
does not have the corresponding descriptions, QF will reject the msg since =

it thinks those custom tags appear more than once.=20

My suggestion is that QF should escape checking custom repeating group or=20
custom tag in standard repeating group, if ValidateUserDefinedFields=3DN

Many thanks
Alvin






Oren Miller <or...@qu...>
Sent by: qui...@li...
08/02/2005 11:54 AM

=20
        To:     Alvin Wang <AW...@FF...>
        cc:     Joerg Thoennes <Joe...@ma...>,=20
qui...@li...,=20
qui...@li...
        bcc:=20
        Subject:        Re: [Quickfix-developers] UseDataDictionary and rep=
eating groups


QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/ind=
ex.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Dale explained the technical reason why the first field must be in=20
order.  The main reason the rest of them must be in order is because=20
the specification requires it:

"Message Format

...

4. Fields within repeating data groups must be specified in the order=20
that the fields are
specified in the message definition within the FIX specification=20
document.  The NoXXX field
where XXX is the field being counted specifies the number of=20
repeating group instances that
must immediately precede the repeating group contents.

..."

On Aug 2, 2005, at 9:31 PM, Alvin Wang wrote:

>
> Why is the order of the fields in a repeating groups important?
>
>
>
> Joerg Thoennes <Joe...@ma...>
> Sent by: qui...@li...
> 08/02/2005 10:37 AM
>
>
>         To:        Alvin Wang <AW...@FF...>
>         cc:        qui...@li...,=20
> qui...@li...
>         bcc:
>         Subject:        Re: [Quickfix-developers] UseDataDictionary=20
> and repeating groups
>
>
>
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/=20
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Alvin Wang wrote:
> > Hi, I just wonder why UseDataDictionary has to be set as Y in=20
> order to use
> > repeating groups? This is not very convenient...
>
> To parse repeating groups correctly, the order of fields is=20
> important. Without a data
> dictionary, QF does not know anything about the field order.
>
> Cheers, J=F6rg
>
> --=20
> 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
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad=5Fid=3D7477&alloc=5Fid=3D16492&op=3D=
click
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
> **********************************************************************=20
>  This e-mail message is intended solely for the use of the=20
> addressee. The message may contain information that is privileged=20
> and confidential. Disclosure to anyone other than the intended=20
> recipient is prohibited. If you are not the intended recipient,=20
> please do not disseminate, distribute or copy this communication,=20
> by e-mail or otherwise. Instead, please notify us immediately by=20
> return e-mail (including the original message with your reply) and=20
> then delete and discard all copies of the message. We have taken=20
> precautions to minimize the risk of transmitting software viruses=20
> but nevertheless advise you to carry out your own virus checks on=20
> any attachment to this message. We accept no liability for any loss=20
> or damage caused by software viruses.=20
> **********************************************************************



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad=5Fidt77&alloc=5Fid=16492&op=3Dclick
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers