quickfix-developers — QuickFIX developers forum

Re: [Quickfix-developers] QuickFIX 1.12.2 is 1 second slower than 1.11.1 on Logon turn-around and I do not know why

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

Leonid,

This is basically what should be done.  I think this is a side effect  
of the non-blocking socket implementation.  The socket is being added  
to the select statement which results in a call to  
SocketInitiator::OnConnect.  The socket is then placed in as a read  
statement, but since it is an initiator it has nothing to read and  
doesn't do anything until the timeout interval forces a logon to go  
out.  Since the select statement can timeout anywhere between 0 and 1  
seconds, I can see how the connection time might vary.

What should be done is in the SocketInitiator::OnConnect call, their  
should be a call to pSocketConnection->onTimeout() which will force  
the logon to be sent out immediately.  You're hack is essentially  
doing this in a more roundabout way, but this approach is more direct  
and would be done directly in the QuickFIX thread.  Below is the full  
method with the change.  Let me know if there is an improvement.

Also, any reason why you are doing the 2 second check at the  
application level?  QuickFIX has a LogonTimeout setting that you  
could set for 2 seconds and would have taken into account the timing  
discrepency.

void SocketInitiator::onConnect( SocketConnector&, int s )
{ QF_STACK_PUSH(SocketInitiator::onConnect)

   SocketConnections::iterator i = m_pendingConnections.find( s );
   if( i == m_pendingConnections.end() ) return;
   SocketConnection* pSocketConnection = i->second;

   m_connections[s] = pSocketConnection;
   m_pendingConnections.erase( i );
   setConnected( pSocketConnection->getSession()->getSessionID() );
   pSocketConnection->onTimeout();

   QF_STACK_POP
}

> I was able to shorten Logon turn-around time significantly when I  
> call onTimeout() directly (and consequently generateLogon()) on the  
> application's main thread and so far it works great, but I am  
> afraid that this may cause some nasty concurrency problem. It seems  
> to me that asynchronous Logon() in the unmodified QuickFIX makes  
> full sense because it seems to be done only once per day/week.  
> Because I have modified QuickFIX to create/logon/logout session on  
> demand to me it rather waste of time
>
> Thank you
>
> Len.

Re: [Quickfix-developers] What should be done if ResendRequest generated by doTargetTooHigh have never been received or acted upon

[len <le...@fa...>]

Hi,

I have tested 1.12.2 in regards of the bug when Session was not timing =
out
when no messages in the right order were coming (although messages with =
too
high sequence number kept coming) 1.11.1 version in such condition stuck =
in
the loop insisting that it already sent ResendRequest.

In regards of testing: I have simulated the same conditions and it DID =
work
as advertised. After two-something heartbeats the session was =
automatically
logged of with event "Timed out waiting for heartbeat". Thank you guys =
you
have saved me from putting in na=EFve hack.

By the way I also have posted a question about delayed logon and pending
connections under different name - I have a hard time to reply to this =
news
group - even though I have registered with it.

Len.

-----Original Message-----
From: Caleb Epstein [mailto:cal...@gm...]=20
Sent: Monday, August 21, 2006 4:26 PM
To: Joerg Thoennes
Cc: len; qui...@li...
Subject: Re: [Quickfix-developers] What should be done if ResendRequest
generated by doTargetTooHigh have never been received or acted upon

On 8/21/06, Joerg Thoennes <Joe...@ma...> wrote:
> > We recently encounter the situation when remote FIX engine seems to
ignore
> > ResendRequest message generated by our QuickFix engine. =
Unfortunately
that
> > ultimately blocked our running QuickFix engine because remote party =
was
keep
> > sending messages with higher and higher sequence numbers and =
QuickFix
simply
> > queue the message and just log ""Already sent ResendRequest FROM:.".
> > Therefore Application code was not aware about problem and QuickFix =
did
not
> > try to resolve it.
> >
> > Did anyone have experience with it? What solution should be? I am
inclining
> > to add some time-out check (basically add time when resendRequest =
was
sent
> > into m_state and resend the message after certain period of time). =
May
be
> > upcoming QuickFix releases address this problem?
>
> reading the discussion in the FIX Protocol forums, I would like to =
support
John Prewetts suggestion
> to force a logout (or disconnect) after a time-out. Oren, do you think =
it
is worth to add
> configuration option as "ResendTimeout" to support this?

What version of QF are people testing this behavior with?  I think the
very latest release 1.12.2 (and anything built from the SVN sources
after 4/29/06 (r1437)) will timeout the connection when this happens
and no new code or configuration should be necessary to support it.
It would be great if someone could test this.

There *was* a bug where the Session's lastReceived timestamp was being
updated before the sequence number checking was done, which caused
test requests never to go out and the connection to stay alive in this
scenario.  this bug was fixed in April, but there haven't been any
QuickFIX releases since then ((until last week).

See my email about this from July 20.

http://sourceforge.net/mailarchive/message.php?msg_id=3D32260466

--=20
Caleb Epstein

Re: [Quickfix-developers] Logon after several attempts

[Shepheard, T. \(London\) <Tob...@ml...>]

After talking with Reg directly (we work at the same place) and trying a
few things, it turned out the other party was sending back a custom tag
in every single message. Adding this to the data-dictionary allowed me
to connect without problems from my system; Reg I've sent an email
direct to you with some more details.
=20
I'm not totally convinced that there's not some other problem too though
- the above should have been fairly apparent in the logs and doesn't
explain why it worked intermitently rather than not at all. Time to go
to the pub now though :)
=20
Toby
=20
=20
-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Oren Miller
Sent: 24 August 2006 14:37
To: Myers, Reg (London)
Cc: qui...@li...
Subject: Re: [Quickfix-developers] Logon after several attempts



	Ok but do you have the QuickFIX logs?=20

	--oren

	On Aug 24, 2006, at 7:53 AM, Myers, Reg (London) wrote:


		QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
		QuickFIX Support:
http://www.quickfixengine.org/services.html

		Hi Oren,
		=20
		 unfortunately our own FixEngine only logs FIX messages
that are successfully accepted through the port / socket.
		It confuses me why QuickFix does eventually logon after
a few attempts.
		=20
		rgds
		=20
		Reg
		=20

			-----Original Message-----
			From: Oren Miller
[mailto:or...@qu...]=20
			Sent: 24 August 2006 13:30
			To: Myers, Reg (London)
			Cc: qui...@li...
			Subject: Re: [Quickfix-developers] Logon after
several attempts
		=09
		=09
			Do you have any log files?=20

			--oren

			On Aug 24, 2006, at 6:46 AM, Myers, Reg (London)
wrote:


				QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
				QuickFIX Support:
http://www.quickfixengine.org/services.html


				Hi,=20

				I'm trying to connect QuickFix to an
externally written Fix Engine.=20
				QuickFix only seems to be able to logon
after about 7 or 8 attempts.=20
				The number of attempts changes and is
not related to seqNum.=20
				I've taken failed attempt
messages...used my own socket to send them=20
				to my Fix Engine and they'vs logged on
first time. I'm beginning to think there=20
				may something funny in the way QuickFix
handles messages over sockets.=20

				Has this happened to anyone before??=20
				Can anyone help?=20

				NB QuickFix ver 1.12.2 on linux=20
				FIX.4.2=20
				In house Fix-engine can only see the
successful logon messages and seems to ignore failed attempts.=20

  _____ =20

				If you are not an intended recipient of
this e-mail, please notify the sender, delete it and do not read, act
upon, print, disclose, copy, retain or redistribute it. Click here
<http://www.ml.com/email_terms/> for important additional terms relating
to this e-mail.     http://www.ml.com/email_terms/
  _____ =20

=09
------------------------------------------------------------------------
-
				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
=09
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
121642
_______________________________________________
				Quickfix-developers mailing list
=09
Qui...@li...
=09
https://lists.sourceforge.net/lists/listinfo/quickfix-developers


=09
------------------------------------------------------------------------
-
		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
=09
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
121642
_______________________________________________
		Quickfix-developers mailing list
		Qui...@li...
=09
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [Quickfix-developers] QuickFIX 1.12.2 is 1 second slower than 1.11.1 on Logon turn-around and I do not know why

[iglen <ig...@ho...>]

Hi,=20

I seem to found at least partial possible explanation. One of the =
crucial
differences of two versions is that new version miss at least one beat =
of
blocked call because it first put connection object in the list of =
pending
connection (m_pendingConnections) which promoted to the connected =
connection
(m_connections) list only after first SocketMonitor::block() call.=20

Moreover when I have replace code in the SocketInitiator::doConnect()

From:
    setPending( s );

    m_pendingConnections[ result ]=20
          =3D new SocketConnection( *this, s, result,
&m_connector.getMonitor() );

To=20
    setConnected(s);

    m_connections[ result ]=20
          =3D new SocketConnection( *this, s, result,
&m_connector.getMonitor() );

It started to behave as old version at least as far as timing of Logon
turn-around is concerned.

It would be very interesting to learn the reason behind of pending
connections.

Thank you.

Len.

________________________________________
From: Leonid Gamburg [mailto:ig...@ho...]=20
Sent: Thursday, August 24, 2006 10:04 AM
To: qui...@li...
Subject: QuickFIX 1.12.2 is 1 second slower than 1.11.1 on Logon =
turn-around
and I do not know why

Hi,
=A0
I am trying to switch from=A0QuickFIX version 1.11.1=A0to QuickFIX =
version
1.12.2 because that version fixed bug when session could not timeout =
even if
remote engine never send messages in right order. When I switch to new
version I found that our Application every other connection timeout. =
After
debugging I have found that we impose on ourselves application's 2 =
second
timeout and disconnect immediately if no Logon message from remote party
been delivered to us. And new version of QuicFIX sometimes take bit less
than 2 seconds and sometimes more. When I have return previous engine =
back
it turn-around time (more on my definition of this term later) was =
around 1
second. I did a little bit more debugging but was not able to pinpoint =
the
reason for that discrepancy, but I am publishing information if other
developers have more clues.
=A0
=A0
The turn-around time for logon I would define as a=A0time it took to =
(and I
have modified QuickFIX a bit to be able to do it on demand) from enable
session and call Initiator::connect() and when the remote site send
FIX::Application::onLogon() propagated back to=A0our application code. =
The
mater here is bit complicated due to asynchronous nature of Logon() =
message
generation. Although enabling session and socket connection happens on =
the
invoking clinet thread Logon message generation sending happens on the
different thread.=20
=A0
On that different=A0thread (different from an Application's main thread) =
there
is a SocketMonitor::block() method which is being=A0invoked in the loop. =
If
there no activity on the sockets it will be blocked for for
SocketMonitor::getTimeval() microseconds which in both version returns =
the
same value equal to 1 second. After "select" invocation =
strategy.onTimeout()
is being called which eventually call Session::generateLogon() etc. The
bazaar part is that although SocketMonitor::block() methods (and other
SocketMonitor methods)=A0are very similar that select() call takes =
exactly 1
second on the 1.12.2 version and almost always 0.6 seconds on the =
1.11.1.
=A0
Although I do not know why this happens (may be there some sockets in =
the
1.11.1 version signal prior to 1 second timeout) that explains 0.4 =
seconds
difference. Where is other 0.6 second difference I do not know.
=A0
I was able to shorten Logon turn-around time significantly when I call
onTimeout() directly (and consequently generateLogon())=A0on the =
application's
main thread and so far it works great, but I am afraid that this may =
cause
some nasty concurrency problem. It seems to me that asynchronous Logon() =
in
the unmodified QuickFIX makes full sense because it seems to be done =
only
once per day/week. Because I have modified QuickFIX to =
create/logon/logout
session on demand to me it rather waste of time
=A0
Thank you
=A0
Len.
________________________________________
Search from any Web page with powerful protection. Get the FREE Windows =
Live
Toolbar Today! Try it now!

Re: [Quickfix-developers] QuickFIX 1.12.2 is 1 second slower than 1.11.1 on Logon turn-around and I do not know why

[iglen <ig...@ho...>]

Hi, I seem to found at least partial possible explanation. One of the
crucial differences of two versions is that new version miss at least one
beat of blocked call because it first put connection object in the list of
pending connection (m_pendingConnections) which promoted to the connected
connection (m_connections) list only after first SocketMonitor::block()
call. 
 
Moreover when I have replace code in the SocketInitiator::doConnect()
 
From:
    setPending( s );
 
    m_pendingConnections[ result ] 
          = new SocketConnection( *this, s, result,
&m_connector.getMonitor() );
 
To 
    setConnected(s);
 
    m_connections[ result ] 
          = new SocketConnection( *this, s, result,
&m_connector.getMonitor() );
 
It started to behave as old version at least as far as timing of Logon
turn-around is concerned.
 
It would be very interesting to learn the reason behind of pending
connections.
 
Thank you.
 
Len.
 
  _____  

From: Leonid Gamburg [mailto:ig...@ho...] 
Sent: Thursday, August 24, 2006 10:04 AM
To: qui...@li...
Subject: QuickFIX 1.12.2 is 1 second slower than 1.11.1 on Logon turn-around
and I do not know why
 
Hi,
 
I am trying to switch from QuickFIX version 1.11.1 to QuickFIX version
1.12.2 because that version fixed bug when session could not timeout even if
remote engine never send messages in right order. When I switch to new
version I found that our Application every other connection timeout. After
debugging I have found that we impose on ourselves application's 2 second
timeout and disconnect immediately if no Logon message from remote party
been delivered to us. And new version of QuicFIX sometimes take bit less
than 2 seconds and sometimes more. When I have return previous engine back
it turn-around time (more on my definition of this term later) was around 1
second. I did a little bit more debugging but was not able to pinpoint the
reason for that discrepancy, but I am publishing information if other
developers have more clues.
 
 
The turn-around time for logon I would define as a time it took to (and I
have modified QuickFIX a bit to be able to do it on demand) from enable
session and call Initiator::connect() and when the remote site send
FIX::Application::onLogon() propagated back to our application code. The
mater here is bit complicated due to asynchronous nature of Logon() message
generation. Although enabling session and socket connection happens on the
invoking clinet thread Logon message generation sending happens on the
different thread. 
 
On that different thread (different from an Application's main thread) there
is a SocketMonitor::block() method which is being invoked in the loop. If
there no activity on the sockets it will be blocked for for
SocketMonitor::getTimeval() microseconds which in both version returns the
same value equal to 1 second. After "select" invocation strategy.onTimeout()
is being called which eventually call Session::generateLogon() etc. The
bazaar part is that although SocketMonitor::block() methods (and other
SocketMonitor methods) are very similar that select() call takes exactly 1
second on the 1.12.2 version and almost always 0.6 seconds on the 1.11.1.
 
Although I do not know why this happens (may be there some sockets in the
1.11.1 version signal prior to 1 second timeout) that explains 0.4 seconds
difference. Where is other 0.6 second difference I do not know.
 
I was able to shorten Logon turn-around time significantly when I call
onTimeout() directly (and consequently generateLogon()) on the application's
main thread and so far it works great, but I am afraid that this may cause
some nasty concurrency problem. It seems to me that asynchronous Logon() in
the unmodified QuickFIX makes full sense because it seems to be done only
once per day/week. Because I have modified QuickFIX to create/logon/logout
session on demand to me it rather waste of time
 
Thank you
 
Len.
  _____  

Search from any Web page with powerful protection. Get the FREE Windows Live
Toolbar Today! Try it now! <http://get.live.com/toolbar/overview> 

[Quickfix-developers] QuickFIX 1.12.2 is 1 second slower than 1.11.1 on Logon turn-around and I do not know why

[Leonid G. <ig...@ho...>]

Hi,
=20
I am trying to switch from QuickFIX version 1.11.1 to QuickFIX version 1.12=
.2 because that version fixed bug when session could not timeout even if re=
mote engine never send messages in right order. When I switch to new versio=
n I found that our Application every other connection timeout. After debugg=
ing I have found that we impose on ourselves application's 2 second timeout=
 and disconnect immediately if no Logon message from remote party been deli=
vered to us. And new version of QuicFIX sometimes take bit less than 2 seco=
nds and sometimes more. When I have return previous engine back it turn-aro=
und time (more on my definition of this term later) was around 1 second. I =
did a little bit more debugging but was not able to pinpoint the reason for=
 that discrepancy, but I am publishing information if other developers have=
 more clues.
=20
=20
The turn-around time for logon I would define as a time it took to (and I h=
ave modified QuickFIX a bit to be able to do it on demand) from enable sess=
ion and call Initiator::connect() and when the remote site send FIX::Applic=
ation::onLogon() propagated back to our application code. The mater here is=
 bit complicated due to asynchronous nature of Logon() message generation. =
Although enabling session and socket connection happens on the invoking cli=
net thread Logon message generation sending happens on the different thread=
.=20
=20
On that different thread (different from an Application's main thread) ther=
e is a SocketMonitor::block() method which is being invoked in the loop. If=
 there no activity on the sockets it will be blocked for for SocketMonitor:=
:getTimeval() microseconds which in both version returns the same value equ=
al to 1 second. After "select" invocation strategy.onTimeout() is being cal=
led which eventually call Session::generateLogon() etc. The bazaar part is =
that although SocketMonitor::block() methods (and other SocketMonitor metho=
ds) are very similar that select() call takes exactly 1 second on the 1.12.=
2 version and almost always 0.6 seconds on the 1.11.1.
=20
Although I do not know why this happens (may be there some sockets in the 1=
.11.1 version signal prior to 1 second timeout) that explains 0.4 seconds d=
ifference. Where is other 0.6 second difference I do not know.
=20
I was able to shorten Logon turn-around time significantly when I call onTi=
meout() directly (and consequently generateLogon()) on the application's ma=
in thread and so far it works great, but I am afraid that this may cause so=
me nasty concurrency problem. It seems to me that asynchronous Logon() in t=
he unmodified QuickFIX makes full sense because it seems to be done only on=
ce per day/week. Because I have modified QuickFIX to create/logon/logout se=
ssion on demand to me it rather waste of time
=20
Thank you
=20
Len.
_________________________________________________________________
Search from any Web page with powerful protection. Get the FREE Windows Liv=
e Toolbar Today!
http://get.live.com/toolbar/overview=

Re: [Quickfix-developers] Logon after several attempts

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

Ok but do you have the QuickFIX logs?

--oren

On Aug 24, 2006, at 7:53 AM, Myers, Reg (London) wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/=20
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi Oren,
>
>  unfortunately our own FixEngine only logs FIX messages that are =20
> successfully accepted through the port / socket.
> It confuses me why QuickFix does eventually logon after a few =20
> attempts.
>
> rgds
>
> Reg
>
> -----Original Message-----
> From: Oren Miller [mailto:or...@qu...]
> Sent: 24 August 2006 13:30
> To: Myers, Reg (London)
> Cc: qui...@li...
> Subject: Re: [Quickfix-developers] Logon after several attempts
>
> Do you have any log files?
>
> --oren
>
> On Aug 24, 2006, at 6:46 AM, Myers, Reg (London) wrote:
>
>> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/=20=

>> html/index.html
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>> Hi,
>>
>> I'm trying to connect QuickFix to an externally written Fix Engine.
>> QuickFix only seems to be able to logon after about 7 or 8 attempts.
>> The number of attempts changes and is not related to seqNum.
>> I've taken failed attempt messages=85used my own socket to send them
>> to my Fix Engine and they'vs logged on first time. I'm beginning =20
>> to think there
>> may something funny in the way QuickFix handles messages over =20
>> sockets.
>>
>> Has this happened to anyone before??
>> Can anyone help?
>>
>> NB QuickFix ver 1.12.2 on linux
>> FIX.4.2
>> In house Fix-engine can only see the successful logon messages and =20=

>> seems to ignore failed attempts.
>>
>> If you are not an intended recipient of this e-mail, please notify =20=

>> the sender, delete it and do not read, act upon, print, disclose, =20
>> copy, retain or redistribute it. Click here for important =20
>> additional terms relating to this e-mail.     http://www.ml.com/=20
>> email_terms/
>> ---------------------------------------------------------------------=20=

>> ----
>> Using Tomcat but need to do more? Need to support web services, =20
>> security?
>> Get stuff done quickly with pre-integrated technology to make your =20=

>> job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache =20
>> Geronimo
>> http://sel.as-us.falkag.net/sel?=20
>> cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D121642_______________________=
______=20
>> __________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
> ----------------------------------------------------------------------=20=

> ---
> Using Tomcat but need to do more? Need to support web services, =20
> security?
> Get stuff done quickly with pre-integrated technology to make your =20
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache =20
> Geronimo
> http://sel.as-us.falkag.net/sel?=20
> cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D121642________________________=
______=20
> _________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [Quickfix-developers] Logon after several attempts

[Shepheard, T. \(London\) <Tob...@ml...>]

Hi Reg,
=20
Could it be to do with clock synchronization? If so, set the QuickFIX
config setting CheckLatency to N (default is Y). If the clocks are just
on the verge of the default limit (120s) that could explain the
intermittent behaviour.
=20
A next step could be to run a network snoop, something like ethereal
(http://www.ethereal.com/) is very handy for doing this. Then you can
get a log of the failed and successful messages and try to find some
common link.
=20
I know you say it's not seqNum related, but maybe try setting ResetOnxxx
settings all to Y just in case. See
http://www.quickfixengine.org/quickfix/doc/html/configuration.html for
the various options.
=20
PS: If you want to discuss, I'm over in POB 1st floor, x54188.
=20
HTH,
Toby

	-----Original Message-----
	From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Myers, Reg (London)
	Sent: 24 August 2006 13:53
	To: Oren Miller
	Cc: qui...@li...
	Subject: Re: [Quickfix-developers] Logon after several attempts
=09
=09
	Hi Oren,
	=20
	 unfortunately our own FixEngine only logs FIX messages that are
successfully accepted through the port / socket.
	It confuses me why QuickFix does eventually logon after a few
attempts.
	=20
	rgds
	=20
	Reg
	=20

		-----Original Message-----
		From: Oren Miller [mailto:or...@qu...]=20
		Sent: 24 August 2006 13:30
		To: Myers, Reg (London)
		Cc: qui...@li...
		Subject: Re: [Quickfix-developers] Logon after several
attempts
	=09
	=09
		Do you have any log files?=20

		--oren

		On Aug 24, 2006, at 6:46 AM, Myers, Reg (London) wrote:


			QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
			QuickFIX Support:
http://www.quickfixengine.org/services.html


			Hi,=20

			I'm trying to connect QuickFix to an externally
written Fix Engine.=20
			QuickFix only seems to be able to logon after
about 7 or 8 attempts.=20
			The number of attempts changes and is not
related to seqNum.=20
			I've taken failed attempt messages...used my own
socket to send them=20
			to my Fix Engine and they'vs logged on first
time. I'm beginning to think there=20
			may something funny in the way QuickFix handles
messages over sockets.=20

			Has this happened to anyone before??=20
			Can anyone help?=20

			NB QuickFix ver 1.12.2 on linux=20
			FIX.4.2=20
			In house Fix-engine can only see the successful
logon messages and seems to ignore failed attempts.=20

  _____ =20

			If you are not an intended recipient of this
e-mail, please notify the sender, delete it and do not read, act upon,
print, disclose, copy, retain or redistribute it. Click here
<http://www.ml.com/email_terms/> for important additional terms relating
to this e-mail.     http://www.ml.com/email_terms/
  _____ =20

=09
------------------------------------------------------------------------
-
			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
=09
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
121642
_______________________________________________
			Quickfix-developers mailing list
			Qui...@li...
=09
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [Quickfix-developers] Logon after several attempts

[Myers, R. \(London\) <Reg...@ml...>]

Hi Oren,
=20
 unfortunately our own FixEngine only logs FIX messages that are
successfully accepted through the port / socket.
It confuses me why QuickFix does eventually logon after a few attempts.
=20
rgds
=20
Reg
=20

	-----Original Message-----
	From: Oren Miller [mailto:or...@qu...]=20
	Sent: 24 August 2006 13:30
	To: Myers, Reg (London)
	Cc: qui...@li...
	Subject: Re: [Quickfix-developers] Logon after several attempts
=09
=09
	Do you have any log files?=20

	--oren

	On Aug 24, 2006, at 6:46 AM, Myers, Reg (London) wrote:


		QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
		QuickFIX Support:
http://www.quickfixengine.org/services.html


		Hi,=20

		I'm trying to connect QuickFix to an externally written
Fix Engine.=20
		QuickFix only seems to be able to logon after about 7 or
8 attempts.=20
		The number of attempts changes and is not related to
seqNum.=20
		I've taken failed attempt messages...used my own socket
to send them=20
		to my Fix Engine and they'vs logged on first time. I'm
beginning to think there=20
		may something funny in the way QuickFix handles messages
over sockets.=20

		Has this happened to anyone before??=20
		Can anyone help?=20

		NB QuickFix ver 1.12.2 on linux=20
		FIX.4.2=20
		In house Fix-engine can only see the successful logon
messages and seems to ignore failed attempts.=20

  _____ =20

		If you are not an intended recipient of this e-mail,
please notify the sender, delete it and do not read, act upon, print,
disclose, copy, retain or redistribute it. Click here
<http://www.ml.com/email_terms/> for important additional terms relating
to this e-mail.     http://www.ml.com/email_terms/
  _____ =20

=09
------------------------------------------------------------------------
-
		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
=09
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
121642
_______________________________________________
		Quickfix-developers mailing list
		Qui...@li...
=09
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [Quickfix-developers] Logon after several attempts

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

Do you have any log files?

--oren

On Aug 24, 2006, at 6:46 AM, Myers, Reg (London) wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/=20
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi,
>
> I'm trying to connect QuickFix to an externally written Fix Engine.
> QuickFix only seems to be able to logon after about 7 or 8 attempts.
> The number of attempts changes and is not related to seqNum.
> I've taken failed attempt messages=85used my own socket to send them
> to my Fix Engine and they'vs logged on first time. I'm beginning to =20=

> think there
> may something funny in the way QuickFix handles messages over sockets.
>
> Has this happened to anyone before??
> Can anyone help?
>
> NB QuickFix ver 1.12.2 on linux
> FIX.4.2
> In house Fix-engine can only see the successful logon messages and =20
> seems to ignore failed attempts.
>
> If you are not an intended recipient of this e-mail, please notify =20
> the sender, delete it and do not read, act upon, print, disclose, =20
> copy, retain or redistribute it. Click here for important =20
> additional terms relating to this e-mail.     http://www.ml.com/=20
> email_terms/
> ----------------------------------------------------------------------=20=

> ---
> Using Tomcat but need to do more? Need to support web services, =20
> security?
> Get stuff done quickly with pre-integrated technology to make your =20
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache =20
> Geronimo
> http://sel.as-us.falkag.net/sel?=20
> cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D121642________________________=
______=20
> _________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] Logon after several attempts

[Myers, R. \(London\) <Reg...@ml...>]

Hi,

I'm trying to connect QuickFix to an externally written Fix Engine.
QuickFix only seems to be able to logon after about 7 or 8 attempts.
The number of attempts changes and is not related to seqNum.
I've taken failed attempt messages...used my own socket to send them=20
to my Fix Engine and they'vs logged on first time. I'm beginning to
think there=20
may something funny in the way QuickFix handles messages over sockets.

Has this happened to anyone before??
Can anyone help?

NB QuickFix ver 1.12.2 on linux
FIX.4.2
In house Fix-engine can only see the successful logon messages and seems
to ignore failed attempts.
--------------------------------------------------------

If you are not an intended recipient of this e-mail, please notify the =
sender, delete it and do not read, act upon, print, disclose, copy, =
retain or redistribute it. Click here for important additional terms =
relating to this e-mail.     http://www.ml.com/email_terms/
--------------------------------------------------------

Re: [Quickfix-developers] SocketInitiator Constructor Weirdness..

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

On 8/23/06, Mark Raynes <mr...@pr...> wrote:
> The only way I can see to get this to work is to define FileLogPath in th=
e
> default session settings=85 obviously though, this isn't ideal if you wan=
t a
> different log file for each session=85 which I do!

You will have a different log for each session.  FileLogPath should
point to a directory, and the FileLog will create files in there named
for each session (e.g. FIX.4.2-SENDER-TARGET.log).

--=20
Caleb Epstein

[Quickfix-developers] SocketInitiator Constructor Weirdness..

[Mark R. <mr...@pr...>]

Hi all,

=20

I'm rather new to QuickFix so please excuse me if I have overlooked
something...

=20

Version - 1.12.1

Language - C++

Platform - Windows XP

Compiler MS Visual Studio 7

=20

If I change the tradeclient example to use a FileLog rather than a
ScreenLog, it throws an exception saying that the FileLogPath is not
defined...

...

Application application;

FIX::FileStoreFactory storeFactory( settings );

FIX::FileLogFactory logFactory( settings );

FIX::SocketInitiator initiator( application, storeFactory, settings,
logFactory );

...

=20

The problem is that the Initiator constructor calls
"logFactory.create()" (Initiator.cpp, line 57)...  this version of
create() looks for the FILE_LOG_PATH setting in the default settings,
not any particular session and if it isn't defined it throws an
exception.

=20

The only way I can see to get this to work is to define FileLogPath in
the default session settings... obviously though, this isn't ideal if
you want a different log file for each session... which I do!

=20

Any ideas?

=20

Regards,

Mark

=20

Re: [Quickfix-developers] What should be done if ResendRequest generated by doTargetTooHigh have never been received or acted upon

[len <le...@fa...>]

Caleb,

Thanks for insightful reply. My response is below

On 8/21/06, Caleb Epstein wrote:

>> The effect I have described occurs in version 1.11.x. I have already
>> downloaded latest source 1.12.2 and very quick check reveal addition of
>> Session level "m_sendRedundantResendRequests" variable which can be set
by
>> Application level code which control reissue of already sent
ResendRequest,
>> which is probably enough for my objectives - what can I say, stupid me, I
>> have to do it first before arrogantly asking the question.

>It doesn't seem like issuing more ResendRequests would help with this
>counterparty.

I believe that ResentRequest message was just simply swallowed somewhere
after network glitch and accordingly second re-send would make the
difference in our particular situation. Generally speaking when you
explicitly elaborated on timeouts when no messages in the PROPER sequence
are arriving - I like it a lot and I am going to test it really soon.

>Perhaps you could expoound on what changes you've made to the QuickFIX
>sources.  If they are beneficial to others, maybe you can have them
>incorporated into the upstream codebase to reduce the need for this
>sort of integration.

>QuickFIX already builds as a DLL doesn't it?
No, QuickFIX is not a DLL in the Windows project. It is a statically linked
library and there nothing wrong with it except that you will have a memory
overhead when you run more than one executable linked to it. It was not in
version 1.11 and I have checked 1.12.2 it is still not the case.

Besides some trivial configuration changes (debug symbols, locations) and
converting it to DLL (small config changes and I had to add MACRO expanding
to __declspec(dllexport) in few key classes to make them exportable) I have
made following changes to the project:

1. Add resource file (xxxx.RC) which includes QuickFIX version - that
allowed under Windows right-click on the quicfix.dll and see its version via
standard property dialog
2. Made bunch of changes which allowed me dynamically config
session/sessions. May be because of my in-expirience with QuickFIX engine
but I've got impression that its life-cycle is too straight-forward for our
needs: Global Application (and its infrastructure such as log, message
store, ThreadedConnection) is loaded and configured only once during
executable host startup. My modification allowed me to do it at any time
dynamically. In addition all our configuration details are stored in DB and
not init file - client code reads config from DB and (re)configure QuickFIX
application. But again there may be a way to achieve it in other way - I
just was not able to find it.
3. Moved Message's validate() method from private to public section -
because it was a beneficial to validate message prior to posting it.
4. Added two more types of logon. One just to check remote sequence number
and disconnect and second to realign local sequence number and continue
connection - this for pure testing purposes.
5. Added a client control methods to simulate loss of incoming or/and
outgoing messages - as well for testing only.

If you want me a share code I also can do it very easily.

Thanks.

Len.

-----Original Message-----
From: Caleb Epstein [mailto:cal...@gm...] 
Sent: Monday, August 21, 2006 4:45 PM
To: len
Cc: Joerg Thoennes; qui...@li...
Subject: Re: [Quickfix-developers] What should be done if ResendRequest
generated by doTargetTooHigh have never been received or acted upon

On 8/21/06, len <le...@fa...> wrote:

> The effect I have described occurs in version 1.11.x. I have already
> downloaded latest source 1.12.2 and very quick check reveal addition of
> Session level "m_sendRedundantResendRequests" variable which can be set by
> Application level code which control reissue of already sent
ResendRequest,
> which is probably enough for my objectives - what can I say, stupid me, I
> have to do it first before arrogantly asking the question.

It doesn't seem like issuing more ResendRequests would help with this
counterparty.

> Interestingly enough Caleb refers for time-out behavior which I did not
> discover yet by surfing through the code. I am planning to test it though

This is the standard FIX heartbeating mechanism.  If no messages are
received (in proper sequence) in <HeartbeatInterval> seconds, a
heartbeat message will be sent.  If still no messages (in proper
sequence) are received after 1.2 * <HeartbeatInterval>, a Test request
is sent, and the connection will eventually timeout if no messages are
received for 2.4 * HeartbeatInterval.  Look at the code in
SessionState.h and Session::next()

> but it will take me a week or two because I am on the other project and I
> will need to back-port our QuickFix sources changes (compiling it into DLL
> and dozen of other little things)

Perhaps you could expoound on what changes you've made to the QuickFIX
sources.  If they are beneficial to others, maybe you can have them
incorporated into the upstream codebase to reduce the need for this
sort of integration.

QuickFIX already builds as a DLL doesn't it?

-- 
Caleb Epstein

Re: [Quickfix-developers] What should be done if ResendRequest generated by doTargetTooHigh have never been received or acted upon

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

On 8/21/06, len <le...@fa...> wrote:

> The effect I have described occurs in version 1.11.x. I have already
> downloaded latest source 1.12.2 and very quick check reveal addition of
> Session level "m_sendRedundantResendRequests" variable which can be set by
> Application level code which control reissue of already sent ResendRequest,
> which is probably enough for my objectives - what can I say, stupid me, I
> have to do it first before arrogantly asking the question.

It doesn't seem like issuing more ResendRequests would help with this
counterparty.

> Interestingly enough Caleb refers for time-out behavior which I did not
> discover yet by surfing through the code. I am planning to test it though

This is the standard FIX heartbeating mechanism.  If no messages are
received (in proper sequence) in <HeartbeatInterval> seconds, a
heartbeat message will be sent.  If still no messages (in proper
sequence) are received after 1.2 * <HeartbeatInterval>, a Test request
is sent, and the connection will eventually timeout if no messages are
received for 2.4 * HeartbeatInterval.  Look at the code in
SessionState.h and Session::next()

> but it will take me a week or two because I am on the other project and I
> will need to back-port our QuickFix sources changes (compiling it into DLL
> and dozen of other little things)

Perhaps you could expoound on what changes you've made to the QuickFIX
sources.  If they are beneficial to others, maybe you can have them
incorporated into the upstream codebase to reduce the need for this
sort of integration.

QuickFIX already builds as a DLL doesn't it?

-- 
Caleb Epstein

Re: [Quickfix-developers] What should be done if ResendRequest generated by doTargetTooHigh have never been received or acted upon

[len <le...@fa...>]

Thanks everybody for the very quick response. 

The effect I have described occurs in version 1.11.x. I have already
downloaded latest source 1.12.2 and very quick check reveal addition of
Session level "m_sendRedundantResendRequests" variable which can be set by
Application level code which control reissue of already sent ResendRequest,
which is probably enough for my objectives - what can I say, stupid me, I
have to do it first before arrogantly asking the question.

Interestingly enough Caleb refers for time-out behavior which I did not
discover yet by surfing through the code. I am planning to test it though
but it will take me a week or two because I am on the other project and I
will need to back-port our QuickFix sources changes (compiling it into DLL
and dozen of other little things)

I will post my findings as soon as I can.

Thank you guys.

Len.

-----Original Message-----
From: Caleb Epstein [mailto:cal...@gm...] 
Sent: Monday, August 21, 2006 4:26 PM
To: Joerg Thoennes
Cc: len; qui...@li...
Subject: Re: [Quickfix-developers] What should be done if ResendRequest
generated by doTargetTooHigh have never been received or acted upon

On 8/21/06, Joerg Thoennes <Joe...@ma...> wrote:
> > We recently encounter the situation when remote FIX engine seems to
ignore
> > ResendRequest message generated by our QuickFix engine. Unfortunately
that
> > ultimately blocked our running QuickFix engine because remote party was
keep
> > sending messages with higher and higher sequence numbers and QuickFix
simply
> > queue the message and just log ""Already sent ResendRequest FROM:.".
> > Therefore Application code was not aware about problem and QuickFix did
not
> > try to resolve it.
> >
> > Did anyone have experience with it? What solution should be? I am
inclining
> > to add some time-out check (basically add time when resendRequest was
sent
> > into m_state and resend the message after certain period of time). May
be
> > upcoming QuickFix releases address this problem?
>
> reading the discussion in the FIX Protocol forums, I would like to support
John Prewetts suggestion
> to force a logout (or disconnect) after a time-out. Oren, do you think it
is worth to add
> configuration option as "ResendTimeout" to support this?

What version of QF are people testing this behavior with?  I think the
very latest release 1.12.2 (and anything built from the SVN sources
after 4/29/06 (r1437)) will timeout the connection when this happens
and no new code or configuration should be necessary to support it.
It would be great if someone could test this.

There *was* a bug where the Session's lastReceived timestamp was being
updated before the sequence number checking was done, which caused
test requests never to go out and the connection to stay alive in this
scenario.  this bug was fixed in April, but there haven't been any
QuickFIX releases since then ((until last week).

See my email about this from July 20.

http://sourceforge.net/mailarchive/message.php?msg_id=32260466

-- 
Caleb Epstein

Re: [Quickfix-developers] What should be done if ResendRequest generated by doTargetTooHigh have never been received or acted upon

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

On 8/21/06, Joerg Thoennes <Joe...@ma...> wrote:
> > We recently encounter the situation when remote FIX engine seems to ignore
> > ResendRequest message generated by our QuickFix engine. Unfortunately that
> > ultimately blocked our running QuickFix engine because remote party was keep
> > sending messages with higher and higher sequence numbers and QuickFix simply
> > queue the message and just log ""Already sent ResendRequest FROM:.".
> > Therefore Application code was not aware about problem and QuickFix did not
> > try to resolve it.
> >
> > Did anyone have experience with it? What solution should be? I am inclining
> > to add some time-out check (basically add time when resendRequest was sent
> > into m_state and resend the message after certain period of time). May be
> > upcoming QuickFix releases address this problem?
>
> reading the discussion in the FIX Protocol forums, I would like to support John Prewetts suggestion
> to force a logout (or disconnect) after a time-out. Oren, do you think it is worth to add
> configuration option as "ResendTimeout" to support this?

What version of QF are people testing this behavior with?  I think the
very latest release 1.12.2 (and anything built from the SVN sources
after 4/29/06 (r1437)) will timeout the connection when this happens
and no new code or configuration should be necessary to support it.
It would be great if someone could test this.

There *was* a bug where the Session's lastReceived timestamp was being
updated before the sequence number checking was done, which caused
test requests never to go out and the connection to stay alive in this
scenario.  this bug was fixed in April, but there haven't been any
QuickFIX releases since then ((until last week).

See my email about this from July 20.

http://sourceforge.net/mailarchive/message.php?msg_id=32260466

-- 
Caleb Epstein

Re: [Quickfix-developers] What should be done if ResendRequestgenerated by doTargetTooHigh have never been received or acted upon

[Sean K. <sea...@pi...>]

Len,

We have experienced the same issue with 1.11.x versions of the code.  I =
believe there is a change in logic to not update the "last time =
received" if this error condition is encountered in 1.12.x which should =
cause the test request logic to kick in.  I haven't been able to test it =
yet.

--Sean

> -----Original Message-----
> From: qui...@li...
> [mailto:qui...@li...]On Behalf Of
> len
> Sent: Monday, August 21, 2006 1:36 PM
> To: qui...@li...
> Subject: [Quickfix-developers] What should be done if
> ResendRequestgenerated by doTargetTooHigh have never been received or
> acted upon
>=20
>=20
> QuickFIX Documentation:=20
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>=20
>=20


Disclaimer: Any references to Pipeline performance contained herein are =
based on historic performance levels which Pipeline expects to maintain =
or exceed but nevertheless does not guarantee. Congested networks, price =
volatility, or other extraordinary events may impede future trading =
activities and degrade performance statistics.

Re: [Quickfix-developers] What should be done if ResendRequest generated by doTargetTooHigh have never been received or acted upon

[len <le...@fa...>]

Hi J=F6rg,

Because Oren was not on the Cc list, can you please keep me in the loop
about my question future discussion?=20

Thanks again.

Len.

-----Original Message-----
From: Joerg Thoennes [mailto:Joe...@ma...]=20
Sent: Monday, August 21, 2006 3:42 PM
To: len
Cc: qui...@li...
Subject: Re: [Quickfix-developers] What should be done if ResendRequest
generated by doTargetTooHigh have never been received or acted upon

> We recently encounter the situation when remote FIX engine seems to =
ignore
> ResendRequest message generated by our QuickFix engine. Unfortunately =
that
> ultimately blocked our running QuickFix engine because remote party =
was
keep
> sending messages with higher and higher sequence numbers and QuickFix
simply
> queue the message and just log ""Already sent ResendRequest FROM:.".
> Therefore Application code was not aware about problem and QuickFix =
did
not
> try to resolve it.
> =20
> Did anyone have experience with it? What solution should be? I am
inclining
> to add some time-out check (basically add time when resendRequest was =
sent
> into m_state and resend the message after certain period of time). May =
be
> upcoming QuickFix releases address this problem?

Hi Len,

reading the discussion in the FIX Protocol forums, I would like to =
support
John Prewetts suggestion
to force a logout (or disconnect) after a time-out. Oren, do you think =
it is
worth to add
configuration option as "ResendTimeout" to support this?

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

Re: [Quickfix-developers] What should be done if ResendRequest generated by doTargetTooHigh have never been received or acted upon

[Joerg T. <Joe...@ma...>]

> We recently encounter the situation when remote FIX engine seems to ign=
ore
> ResendRequest message generated by our QuickFix engine. Unfortunately t=
hat
> ultimately blocked our running QuickFix engine because remote party was=
 keep
> sending messages with higher and higher sequence numbers and QuickFix s=
imply
> queue the message and just log ""Already sent ResendRequest FROM:.".
> Therefore Application code was not aware about problem and QuickFix did=
 not
> try to resolve it.
> =20
> Did anyone have experience with it? What solution should be? I am incli=
ning
> to add some time-out check (basically add time when resendRequest was s=
ent
> into m_state and resend the message after certain period of time). May =
be
> upcoming QuickFix releases address this problem?

Hi Len,

reading the discussion in the FIX Protocol forums, I would like to suppor=
t John Prewetts suggestion
to force a logout (or disconnect) after a time-out. Oren, do you think it=
 is worth to add
configuration option as "ResendTimeout" to support this?

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

[Quickfix-developers] What should be done if ResendRequest generated by doTargetTooHigh have never been received or acted upon

[len <le...@fa...>]

Hi,
 
We recently encounter the situation when remote FIX engine seems to ignore
ResendRequest message generated by our QuickFix engine. Unfortunately that
ultimately blocked our running QuickFix engine because remote party was keep
sending messages with higher and higher sequence numbers and QuickFix simply
queue the message and just log ""Already sent ResendRequest FROM:.".
Therefore Application code was not aware about problem and QuickFix did not
try to resolve it.
 
Did anyone have experience with it? What solution should be? I am inclining
to add some time-out check (basically add time when resendRequest was sent
into m_state and resend the message after certain period of time). May be
upcoming QuickFix releases address this problem?
 
Thank you.

[Quickfix-developers] QuickFixJ bug?

[Stefano R. <ste...@ko...>]

Hi all,

 

I might found a problem with the engine but I'm not sure if it's a bug or
not.

According to the datadictionary (FIX44), the component block
(UnderlyingInstrument) has another

component block inside it (UnderlyingStipulations).

According to the implementation class MessageComponent.java a component
block can't have other

Component blocks but only fields and groups.

It seems to be a mismatch between what the dictionary says and how the
actual class is implemented.

May be I'm wrong and I'm missing something. Just want to be sure.

 

Sorry for my English.

 

Regards,

Stefano Rocco

 

Re: [Quickfix-developers] Datestamp in Log File names

[David S. <Dav...@ig...>]

Oren, I have tested the changes you made and they work fine. Thank you
very much for such a speedy response.=20

Just for your information, I was testing our price feed today and after
2 hours it had generated a 1GB .body file and a 68MB .header file. That
was subscribing to about 3600 instruments. Other feeds subscribe to over
10 thousand!

I think this change could be a real life saver for anyone using QuickFIX
for pricing ;-)

Thanks for the great work. Have a good weekend.

Cheers
Dave

-----Original Message-----
From: Oren Miller [mailto:or...@qu...]=20
Sent: 17 August 2006 22:02
To: David Stewart
Cc: Qui...@li...
Subject: Re: [Quickfix-developers] Datestamp in Log File names

David,

I checked into source control support for the PersistMessages
configuration setting.  If this is set to 'N', the session will not
store or retrieve messages from the message store.  Instead it will
respond to all ResendRequests with a single gap fill message.  Try this
out and see if it works for you.

--oren



The information contained in this email is strictly confidential and for =
the use of the addressee only, unless otherwise indicated. If you are not=
 the intended recipient, please do not read, copy, use or disclose to oth=
ers this message or any attachment. Please also notify the sender by repl=
ying to this email or by telephone +44 (0)20 7896 0011 and then delete th=
e email and any copies of it. Opinions, conclusions (etc.) that do not re=
late to the official business of this company shall be understood as neit=
her given nor endorsed by it. IG Markets Limited and IG Index Plc are aut=
horised and regulated by the Financial Services Authority and, in Austral=
ia, by the Australian Securities and Investments Commission.

Re: [Quickfix-developers] QuickFIX Python binding and repeating groups

[Reggie D. <re...@me...>]

Oren,

I've attached a short Python script (basically examples from the docs)
that fails for me.  If I change the call to the start method to a call
to the block method, it runs fine and the session is successfully logged
on.  Here's the output I get when I run it:

$ python qftest.py
FIX.4.4:MERFINMD->JPSIMMD created
<20060817-21:39:27, FIX.4.4:MERFINMD->JPSIMMD, event>
  (Created session)
<20060817-21:39:27, FIX.4.4:MERFINMD->JPSIMMD, event>
  (Connecting to 198.75.230.13 on port 4059)
Segmentation fault

Thanks for helping with this.

-Reggie

On Wed, 2006-08-16 at 01:23 -0500, Oren Miller wrote:
> Reggie,
> 
> I'm unable to duplicate this unfortunately.  Would it be possible for  
> you to send me your script?
> 
> --oren
> 
> On Aug 11, 2006, at 6:06 PM, Reggie Dugard wrote:
> 
> > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
> > html/index.html
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> >
> > On Fri, 2006-08-11 at 10:42 -0700, or...@qu... wrote:
> >>> The quickfix44.py that is generated starts with a class NoHops  
> >>> which is
> >>> derived from fix.Group.  This class is indented, presumably because
> >>> groups are usually a part of a containing Message (which does not  
> >>> seem
> >>> to be the case here).  This is a syntax error in Python and for  
> >>> now I've
> >>> manually dedented that class definition to be able to import the  
> >>> file.
> >>> What would be the correct fix for this?
> >>
> >> This was apparently the repeating group from the header that  
> >> didn't have
> >> a home. I've updated the generator so it is not placed in this file
> >> anymore.  I have checked the fix into the svn repository.
> >>
> > quickfix44.py imports fine now, thanks
> >
> >>> I'm trying to create a MarketDataRequest message which contains
> >>> repeating groups.  I've attempted to follow the repeating group  
> >>> example
> >>> in the documentation, but I get the following traceback:
> >> [snip]
> >>> I've tried looking around in the source code, but I can't find any
> >>> definition of intArray.  Is this the correct way to set up a  
> >>> repeating
> >>> group?  Where is intArray defined?
> >>
> >> This should be referencing IntArray instead of intArray.  This fix  
> >> has
> >> also been checked into svn.
> >>
> > Thanks, I can successfully make MarketDataRequests now.
> >
> >>> I'm currently doing everything within the callbacks of a class  
> >>> derived
> >>> from fix.Application, and using the block method of  
> >>> SocketInitiator, but
> >>> when I've tried to use separate threads, I've gotten "Segmentation
> >>> Fault" both when using the start method or when trying to create the
> >>> threads myself using Python's threading module.  What is the  
> >>> correct way
> >>> to do this?
> >>
> >> Can you provide more details?  Are you segfaulting immediately?   
> >> Does it
> >> happen over time?
> >>
> > It segfaults almost immediately; seems to be just after the session is
> > created.  It seems to be trying to send the logon message according to
> > this gdb output:
> >
> > GNU gdb Red Hat Linux (6.3.0.0-1.84rh)
> > Copyright 2004 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License,  
> > and you are
> > welcome to change it and/or distribute copies of it under certain  
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for  
> > details.
> > This GDB was configured as "i386-redhat-linux-gnu"...(no debugging  
> > symbols found)
> > Using host libthread_db library "/lib/libthread_db.so.1".
> >
> > Reading symbols from shared object read from target memory...(no  
> > debugging symbols found)...done.
> > Loaded system supplied DSO at 0x664000
> > Core was generated by `python fixplay.py'.
> > Program terminated with signal 11, Segmentation fault.
> >
> > warning: svr4_current_sos: Can't read pathname for load map: Input/ 
> > output error
> >
> > Reading symbols from /usr/lib/libpython2.4.so.1.0...(no debugging  
> > symbols found)...done.
> >
> > ...
> >
> > Reading symbols from /usr/lib/python2.4/lib-dynload/ 
> > _weakref.so...done.
> > Loaded symbols for /usr/lib/python2.4/lib-dynload/_weakref.so
> > #0  0x00000269 in ?? ()
> > (gdb) where
> > #0  0x00000269 in ?? ()
> > #1  0x00139f9f in FIX::Session::sendRaw (this=0x97dae80,  
> > message=@0xb786d940, num=0) at Session.cpp:457
> > #2  0x0014481d in FIX::Session::generateLogon (this=0x97dae80) at  
> > Session.cpp:602
> > #3  0x00144fce in FIX::Session::next (this=0x97dae80) at  
> > Session.cpp:147
> > #4  0x0017bd8f in FIX::SocketConnection::onTimeout (this=0x96d72d0)  
> > at SocketConnection.cpp:239
> > #5  0x001738af in FIX::SocketInitiator::onTimeout (this=0x93bb888)  
> > at SocketInitiator.cpp:244
> > #6  0x00166b03 in FIX::ConnectorWrapper::onTimeout  
> > (this=0xb786dd3c) at SocketConnector.cpp:89
> > #7  0x0017a8f3 in FIX::SocketMonitor::block (this=0x93bb96c,  
> > strategy=@0x6cd44a, poll=false) at SocketMonitor.cpp:228
> > Previous frame inner to this frame (corrupt stack?)
> > (gdb)
> >
> > Hopefully this will help, let me know if I can provide you with any  
> > other info.
> >
> >> --oren
> >>
> > -- 
> > -Reggie
> >
> >
> >
> >
> > ---------------------------------------------------------------------- 
> > ---
> > 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
> >

Re: [Quickfix-developers] Datestamp in Log File names

[David S. <Dav...@ig...>]

Awesome! Thank you mate. I will try it out next week.

Thanks
Dave

-----Original Message-----
From: Oren Miller [mailto:or...@qu...]=20
Sent: 17 August 2006 22:02
To: David Stewart
Cc: Qui...@li...
Subject: Re: [Quickfix-developers] Datestamp in Log File names

David,

I checked into source control support for the PersistMessages
configuration setting.  If this is set to 'N', the session will not
store or retrieve messages from the message store.  Instead it will
respond to all ResendRequests with a single gap fill message.  Try this
out and see if it works for you.

--oren

On Aug 17, 2006, at 3:41 AM, David Stewart wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Thanks Oren. I have also noticed that our resend file (.body) is=20
> getting very large also.
> Is there a way I can tell quickfix to just gap-fill any resend=20
> requests and thereby avoid the overhead of cacheing all the messages?
> As the fix engine is used for a price feed we don't particularly want=20=

> to resend stale prices anyway.
>
> Thanks
> Dave
>
>
> -----Original Message-----
> From: Oren Miller [mailto:or...@qu...]
> Sent: 17 August 2006 06:05
> To: David Stewart
> Cc: qui...@li...
> Subject: Re: [Quickfix-developers] Datestamp in Log File names
>
> Passing a LogStoreFactory is optional.  If you do not pass one in, no
> log files will be created.
>
> --oren
>
> On Aug 16, 2006, at 2:18 AM, David Stewart wrote:
>
>> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/
>> html/index.html
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>> Unfortunately our processes don't restart daily. Is there a quick and
>> easy way to configure quickfix to not log at all? By means of a =20
>> config
>
>> flag or something?
>>
>> Thanks
>> Dave
>>
>>
>>
>> The information contained in this email is strictly confidential and
>> for the use of the addressee only, unless otherwise indicated.
>> If you are not the intended recipient, please do not read, copy, use
>> or disclose to others this message or any attachment. Please also
>> notify the sender by replying to this email or by telephone
>> +44 (0)20 7896 0011 and then delete the email and any copies of it.
>> Opinions, conclusions (etc.) that do not relate to the official
>> business of this company shall be understood as neither given nor
>> endorsed by it. IG Markets Limited and IG Index Plc are authorised =20=

>> and
>
>> regulated by the Financial Services Authority and, in Australia, by
>> the Australian Securities and Investments Commission.
>>
>>
>> ---------------------------------------------------------------------

>> -
>> ---
>> Using Tomcat but need to do more? Need to support web services,
>> security?
>> Get stuff done quickly with pre-integrated technology to make your =20=

>> job
>
>> easier Download IBM WebSphere Application Server v.1.0.1 based on
>> Apache Geronimo http://sel.as-us.falkag.net/sel?
>> cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D121642
>> _______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>
>
>
>
> The information contained in this email is strictly confidential =20
> and for the use of the addressee only, unless otherwise indicated. =20
> If you are not the intended recipient, please do not read, copy, =20
> use or disclose to others this message or any attachment. Please =20
> also notify the sender by replying to this email or by telephone =20
> +44 (0)20 7896 0011 and then delete the email and any copies of it. =20=

> Opinions, conclusions (etc.) that do not relate to the official =20
> business of this company shall be understood as neither given nor =20
> endorsed by it. IG Markets Limited and IG Index Plc are authorised =20
> and regulated by the Financial Services Authority and, in =20
> Australia, by the Australian Securities and Investments Commission.
>
>
> ----------------------------------------------------------------------

> ---
> Using Tomcat but need to do more? Need to support web services, =20
> security?
> Get stuff done quickly with pre-integrated technology to make your =20
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache =20
> Geronimo
> http://sel.as-us.falkag.net/sel?=20
> cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D121642
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>




The information contained in this email is strictly confidential and for =
the use of the addressee only, unless otherwise indicated. If you are not=
 the intended recipient, please do not read, copy, use or disclose to oth=
ers this message or any attachment. Please also notify the sender by repl=
ying to this email or by telephone +44 (0)20 7896 0011 and then delete th=
e email and any copies of it. Opinions, conclusions (etc.) that do not re=
late to the official business of this company shall be understood as neit=
her given nor endorsed by it. IG Markets Limited and IG Index Plc are aut=
horised and regulated by the Financial Services Authority and, in Austral=
ia, by the Australian Securities and Investments Commission.