quickfix-developers — QuickFIX developers forum

[Quickfix-developers] tag 11 format restrictions and new clordid in cxl and repl msg

[Asim <asi...@ya...>]

Hi all - my first post here, Just started looking into q.fix.
 
While using quickfix API, all the orderids set has to be maintained by
the application? Or the api can do that as well ? ya know..clorder,
orderid, origclorderid.in cxls and cxl replace messages,
Also some firms have diff requirement in cxl messages..like they never
want a new clorderid in cxl message and no new clorderid in cxl/replace
msg allowed while reducing quantity, Looks like violating fix rules?
Another prob is some firms restrict the client sides to format their
clorder like yyyymmdd-999, whereas others leave it on order sending
firm's discretion.
So I was wondering if quickfix has the capability to cope with these
variant requirements?
 
Please help!
 
Thanks,
Asim
 

RE: [Quickfix-developers] Reject Message

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

Patrick,

Yes.  Reject messages should not interrupt the flow of valid message
traffic.

--oren

> -------- Original Message --------
> Subject: [Quickfix-developers] Reject Message
> From: "Patrick Flannery" <pat...@ch...>
> Date: Mon, February 07, 2005 5:36 pm
> To: Qui...@li...
> 
> Quickfix Developers,
>             Should a Quickfix acceptor be able to send a FIX44::Reject
> message to an initiator and have message passing continue without
> interruption?  Thanks in advance. 
> Patrick Flannery

[Quickfix-developers] Reject Message

[Patrick F. <pat...@ch...>]

Quickfix Developers,
            Should a Quickfix acceptor be able to send a FIX44::Reject
message to an initiator and have message passing continue without
interruption?  Thanks in advance. 
Patrick Flannery
 

RE: [Quickfix-developers] State of the Engine Address

[Michael R. <mr...@li...>]

Do you maintain a list of companies currently using/testing quickFix?
You mention a few in your address...

M.

-----Original Message-----
From: or...@qu... [mailto:or...@qu...]
Sent: Friday, February 04, 2005 12:44 PM
To: 
Subject: [Quickfix-developers] State of the Engine Address


QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html

Well, I thought it was about time we had a State of the Engine Address,
and no, I'm not referring to sequence numbers or IP addresses (well,
maybe a little).

So QuickFIX is well in it's 3rd year now.  QuickFIX first went live into
several production environments two months after it's initial 1.0
release.  Since several of these systems are still active, this means
are longest running full time production deployments have been going
strong for 3 years. (One of these is now a major online brokerage).

Last year I had mentioned the major shift in attitude towards open
source software in corporate settings.  We saw a huge burst in
downloads and usage of QuickFIX.  I'm happy to say that the trend has
continued.  We do very little traditional promotion of QuickFIX, so it
can only be attributed to word of mouth.  Quite incredible how often
you guys talk to each other, but then that is what FIX is supposed to
accomplish.

I can't even begin to cover all of the new deployments.  Some notable
ones include the CME's very successful rollout, and Deutche Boerse's
Xentric FIX Gateway.  As many of you may know, my position concerning
QuickFIX is that it complements as often as it competes with commercial
offerings.  The Xetra/Eurex solution is a perfect example of a product
rolled out with a combination of both CameronFIX and QuickFIX offerings
to provide a complete FIX solution.

* FUTURE RELEASES *

Much work has been done in preparation for the next release.  1.9.4 has
been quite successful.  At this point, we have enough stuff to
constitute a major release.  Some of these are bug fixes, new features,
better error reporting and such.  Not everything on our plate right now
is going to make the cut for this release.  We are currently targeting
a release date some time this month.  After that, we will probably
follow up with a another release in a relatively short period of time
that has everything we want.

We are also working on adding support for more databases.  Caleb Epstein
has contributed support for Sleepycat Berkely DB, and we are also
looking at Postgres and MSSQL.  These will probably show up a couple
releases down the road.

* ADOPTION *

Our goal for the next year will be to make it easier for people to adopt
QuickFIX.  Early on, we focused our efforts on getting software
developers and technologist familiar with QuickFIX.  All along I have
credited software developers with being the driving force for
introducing new technology into company infrastructures.  Well the
executives have noticed, and they have a lot of good questions of their
own.  Why?  They generally have a board of directors to report to, and
QuickFIX is becoming a topic in a lot of board rooms.

There are three fronts in which I'd like to address this issue:
Technology, Information, and Responsibility.  

Through technology, we need to make QuickFIX as easy to evaluate as
possible.  Last year we introduced pre-built windows binary
distributions that have proven very popular and lowered one barrier to
entry ( Visual Studio license ).  We must continue to focus on making
the technology even easer to get started with.  Not only that, we must
provide tools in which companies can easily perform benchmarks on their
own hardware.  Anything that will make it possible for a company to
easily evaluate if QuickFIX meets their needs.

Information covers many things. It covers the documentation of the
product itself, which should see improvements in organization and
content.  But it means so much more than that.  So many people look at
QuickFIX and they just don't know what exactly is going on.  Often
there is the impression that QuickFIX is a fringe player that is used
by only small firms.  They don't know that it is in heavy use by many
of the largest financial institutions in the world.  That makes a big
difference to the board of directors.  It is important for us to gather
the information executives need so we are ready to answer the questions
that come up over and over again.  I've talked to many of them, believe
me, they are always the same questions. (That just means they all have a
common problem that needs a solution).

Responsibility has always been the albatross of open source.  Last year
Connamara Systems and Macdonald Associates began offering QuickFIX
support contracts.  They essentially said that they will take the
responsibility for support that is comparable to those offered by
commercial software providers.  Just the fact that these support
contracts exist has made a big difference in adoption.  I hope that
this experiment proves successful for them as it will be a great
benefit to the project.  We must continue to find other ways to
demonstrate the commitment to the future of QuickFIX.  I'll be
discussing more on this at a future date.

* FPL *

We plan on applying for FPL membership in the near future (they have
expressed interest in our joining).  This will give us greater
influence on the future direction of the protocol.  With
quickfixengine.org as an FPL member, we will be able to represent the
interests of QuickFIX users.  There are some interesting things going
on with the FPL, and I feel it is important that we voice our desire
for the protocol to remain open and free.  As influential as we have
been in promoting FIX, within the FPL it is members that have the
strongest voices.

* PURE JAVA PORT *

Some of you may have seen postings from Steve Bate about a pure Java
port of QuickFIX he started.  Steve sent us the work he has done so
far, and it looks very promising.  Steve and I talked a few days ago
and we decided that we would put his work into our CVS repository. 
Yes, it's real, and this will possibly become an official java version
of the QuickFIX engine.  Steve's current design goal is to emulate the
current engine as closely as possible.  This means remaining compatible
with the configuration files, data dictionaries, message stores, and
current java API.  Basically, you should be able to swap out the JNI
version of QuickFIX with this port.  After this design goal is reached,
we may look into how we can take fuller advantage of the Java platform
once the library is no longer being held back by its C++ core.

* SIMC CONFERENCE *

Are you a major firm with an interesting story regarding the adoption of
QuickFIX?  If so, please get in touch with us.  Last year the SIMC held
a conference on open source software in the securities industry.  At
that conference, Reuters shared their experience in adopting QuickFIX. 
They have invited us back to get an update on our current status and
want to hear other adoption stories.  This is a well attended event
that primarily consists of executive level IT professionals.  You could
participate either in person at the New York location, or you can attend
remotely via telephone.  Please email us at as...@qu... if
you are interested.

* SOUTH AMERICA *

What is this about?  Well, that's where I'm going to be for the next 10
days.  I'll largely be unreachable, so instead of sending me emails
directly, send them to as...@qu..., and someone will get
back to you.

* FIN *

Thanks for the enormous contributions we have received from so many
people.  We will continue to explore ways in which the community can
stay informed, and contribute to our progress.



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

[Quickfix-developers] State of the Engine Address

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

Well, I thought it was about time we had a State of the Engine Address,
and no, I'm not referring to sequence numbers or IP addresses (well,
maybe a little).

So QuickFIX is well in it's 3rd year now.  QuickFIX first went live into
several production environments two months after it's initial 1.0
release.  Since several of these systems are still active, this means
are longest running full time production deployments have been going
strong for 3 years. (One of these is now a major online brokerage).

Last year I had mentioned the major shift in attitude towards open
source software in corporate settings.  We saw a huge burst in
downloads and usage of QuickFIX.  I'm happy to say that the trend has
continued.  We do very little traditional promotion of QuickFIX, so it
can only be attributed to word of mouth.  Quite incredible how often
you guys talk to each other, but then that is what FIX is supposed to
accomplish.

I can't even begin to cover all of the new deployments.  Some notable
ones include the CME's very successful rollout, and Deutche Boerse's
Xentric FIX Gateway.  As many of you may know, my position concerning
QuickFIX is that it complements as often as it competes with commercial
offerings.  The Xetra/Eurex solution is a perfect example of a product
rolled out with a combination of both CameronFIX and QuickFIX offerings
to provide a complete FIX solution.

* FUTURE RELEASES *

Much work has been done in preparation for the next release.  1.9.4 has
been quite successful.  At this point, we have enough stuff to
constitute a major release.  Some of these are bug fixes, new features,
better error reporting and such.  Not everything on our plate right now
is going to make the cut for this release.  We are currently targeting
a release date some time this month.  After that, we will probably
follow up with a another release in a relatively short period of time
that has everything we want.

We are also working on adding support for more databases.  Caleb Epstein
has contributed support for Sleepycat Berkely DB, and we are also
looking at Postgres and MSSQL.  These will probably show up a couple
releases down the road.

* ADOPTION *

Our goal for the next year will be to make it easier for people to adopt
QuickFIX.  Early on, we focused our efforts on getting software
developers and technologist familiar with QuickFIX.  All along I have
credited software developers with being the driving force for
introducing new technology into company infrastructures.  Well the
executives have noticed, and they have a lot of good questions of their
own.  Why?  They generally have a board of directors to report to, and
QuickFIX is becoming a topic in a lot of board rooms.

There are three fronts in which I'd like to address this issue:
Technology, Information, and Responsibility.  

Through technology, we need to make QuickFIX as easy to evaluate as
possible.  Last year we introduced pre-built windows binary
distributions that have proven very popular and lowered one barrier to
entry ( Visual Studio license ).  We must continue to focus on making
the technology even easer to get started with.  Not only that, we must
provide tools in which companies can easily perform benchmarks on their
own hardware.  Anything that will make it possible for a company to
easily evaluate if QuickFIX meets their needs.

Information covers many things. It covers the documentation of the
product itself, which should see improvements in organization and
content.  But it means so much more than that.  So many people look at
QuickFIX and they just don't know what exactly is going on.  Often
there is the impression that QuickFIX is a fringe player that is used
by only small firms.  They don't know that it is in heavy use by many
of the largest financial institutions in the world.  That makes a big
difference to the board of directors.  It is important for us to gather
the information executives need so we are ready to answer the questions
that come up over and over again.  I've talked to many of them, believe
me, they are always the same questions. (That just means they all have a
common problem that needs a solution).

Responsibility has always been the albatross of open source.  Last year
Connamara Systems and Macdonald Associates began offering QuickFIX
support contracts.  They essentially said that they will take the
responsibility for support that is comparable to those offered by
commercial software providers.  Just the fact that these support
contracts exist has made a big difference in adoption.  I hope that
this experiment proves successful for them as it will be a great
benefit to the project.  We must continue to find other ways to
demonstrate the commitment to the future of QuickFIX.  I'll be
discussing more on this at a future date.

* FPL *

We plan on applying for FPL membership in the near future (they have
expressed interest in our joining).  This will give us greater
influence on the future direction of the protocol.  With
quickfixengine.org as an FPL member, we will be able to represent the
interests of QuickFIX users.  There are some interesting things going
on with the FPL, and I feel it is important that we voice our desire
for the protocol to remain open and free.  As influential as we have
been in promoting FIX, within the FPL it is members that have the
strongest voices.

* PURE JAVA PORT *

Some of you may have seen postings from Steve Bate about a pure Java
port of QuickFIX he started.  Steve sent us the work he has done so
far, and it looks very promising.  Steve and I talked a few days ago
and we decided that we would put his work into our CVS repository. 
Yes, it's real, and this will possibly become an official java version
of the QuickFIX engine.  Steve's current design goal is to emulate the
current engine as closely as possible.  This means remaining compatible
with the configuration files, data dictionaries, message stores, and
current java API.  Basically, you should be able to swap out the JNI
version of QuickFIX with this port.  After this design goal is reached,
we may look into how we can take fuller advantage of the Java platform
once the library is no longer being held back by its C++ core.

* SIMC CONFERENCE *

Are you a major firm with an interesting story regarding the adoption of
QuickFIX?  If so, please get in touch with us.  Last year the SIMC held
a conference on open source software in the securities industry.  At
that conference, Reuters shared their experience in adopting QuickFIX. 
They have invited us back to get an update on our current status and
want to hear other adoption stories.  This is a well attended event
that primarily consists of executive level IT professionals.  You could
participate either in person at the New York location, or you can attend
remotely via telephone.  Please email us at as...@qu... if
you are interested.

* SOUTH AMERICA *

What is this about?  Well, that's where I'm going to be for the next 10
days.  I'll largely be unreachable, so instead of sending me emails
directly, send them to as...@qu..., and someone will get
back to you.

* FIN *

Thanks for the enormous contributions we have received from so many
people.  We will continue to explore ways in which the community can
stay informed, and contribute to our progress.

RE: [Quickfix-developers] Week Long Session Bug

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

It would be helpful if you could send us exactly what your time/day
settings are in your configuration file and what time zone you are in. 
That way we can design a test for this situation.

BTW looks like this answers my last question, you are using 1.6, so yeah
the other bug you encountered is a known bug in that version.

--oren

> -------- Original Message --------
> Subject: [Quickfix-developers] Week Long Session Bug
> From: "Michael Holm" <mh...@li...>
> Date: Fri, February 04, 2005 4:48 am
> To: qui...@li...
> 
> This was re-posted because the last email I sent was garbled for some
> reason.
>  
> I am using QuickFix 1.6 to connect to SFE. I am planning on using the
> newest version 1.94 and have found a weird bug with week long sessions.
> I set the session to run from Monday - Friday. This works fine for the
> first week but when it should start on the following Monday the only
> thing that happens is that it creates a session and then hangs. Has
> anyone seen this before? If I get rid of week long sessions everything
> runs fine. I think the problem might have something to do with GMT
> because their Monday is still Sunday to us. But I have tested this and
> it still seems to be buggy. What is an example that you guys use for
> CME, mo - fr etc..? 
> 
>  
> 
> Thanks
> 
> Michael Holm
> 
> Liquid Capital Markets Ltd
> 11 Old Jewry
> London EC2R 8DU
> Tel:020 7726 3028

RE: [Quickfix-developers] Re: Intermittent disconnect problem

[Bishop, B. <Bar...@gs...>]

Hi Michael,
 
Thanks for your suggestions, although I think you have a different problem
to me. We never have sudden bursts of traffic (inbound or outbound) and
sometimes we disconnect after 10 seconds of complete inactivity.
 
In your case though, wouldn't it be better pass the inbound messages on to a
separate thread. This would unload the FIX thread to carry doing what it
does best, leaving you as much time as you need to process all the messages.
It would also save patching the quickfix code for this specal case.
 
Best of luck,
barry

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Michael Holm
Sent: Friday, February 04, 2005 10:43 AM
To: qui...@li...
Subject: [Quickfix-developers] Re: Intermittent disconnect problem



I have seen a similar problem when connecting to SFE. They require that I
follow the heartbeat procedure defined in the Fix spec. with one exception.
At initial start-up time or at certain times throughout the day they may
blast a huge amount of data to me which needs to be processed. The QuickFix
engine gives priority to these messages and starves the heartbeat time
slice. So if I am processing these messages for more then the agreed upon
heartbeat period SFE will disconnect the session on their side and then
QuickFix re-establishes the session and resyncs. And then they have to
retransmit messages and as you can see I will encounter a never ending loop
of shit. So I modified the following to code to stop QuickFix from starving
the heartbeats.

 

In the following method - void SocketInitiator::onData( SocketConnector&
connector, int s )

 

The current code:

while( pSocketConnection->read( connector ) )

{}

 

My modified version:

while( pSocketConnection->read( connector ) ) 

{

  // Modified 11-26-03 by M. Holm. Because heartbeats are being starved!

  i->second->onTimeout();

}

 

This will ensure that heartbeats will be sent when necessary according to
the SFE spec.

 

You might be having a similar problem to the one I encountered.

 

Hope this helps.

 

Michael Holm

Liquid Capital Markets Ltd
11 Old Jewry
London EC2R 8DU
Tel:020 7726 3028

 

RE: [Quickfix-developers] Re: Intermittent disconnect problem

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

Hi Michael,

Thanks.  What version of QuickFIX are you using?  I ask because in 1.9.0
we introduced a similar fix for this.  Instead of calling onTimeout
after the read call, the session is calling next() after it processes
each message, which should have a similar effect.  Was your fix applied
to a 1.9.x version or an earlier one?

--oren

> -------- Original Message --------
> Subject: [Quickfix-developers] Re: Intermittent disconnect problem
> From: "Michael Holm" <mh...@li...>
> Date: Fri, February 04, 2005 4:42 am
> To: qui...@li...
> 
> I have seen a similar problem when connecting to SFE. They require that
> I follow the heartbeat procedure defined in the Fix spec. with one
> exception. At initial start-up time or at certain times throughout the
> day they may blast a huge amount of data to me which needs to be
> processed. The QuickFix engine gives priority to these messages and
> starves the heartbeat time slice. So if I am processing these messages
> for more then the agreed upon heartbeat period SFE will disconnect the
> session on their side and then QuickFix re-establishes the session and
> resyncs. And then they have to retransmit messages and as you can see I
> will encounter a never ending loop of shit. So I modified the following
> to code to stop QuickFix from starving the heartbeats.
> 
>  
> 
> In the following method - void SocketInitiator::onData( SocketConnector&
> connector, int s )
> 
>  
> 
> The current code:
> 
> while( pSocketConnection->read( connector ) )
> 
> {}
> 
>  
> 
> My modified version:
> 
> while( pSocketConnection->read( connector ) ) 
> 
> {
> 
>   // Modified 11-26-03 by M. Holm. Because heartbeats are being starved!
> 
>   i->second->onTimeout();
> 
> }
> 
>  
> 
> This will ensure that heartbeats will be sent when necessary according
> to the SFE spec.
> 
>  
> 
> You might be having a similar problem to the one I encountered.
> 
>  
> 
> Hope this helps.
> 
>  
> 
> Michael Holm
> 
> Liquid Capital Markets Ltd
> 11 Old Jewry
> London EC2R 8DU
> Tel:020 7726 3028

[Quickfix-developers] "Invalid tag number" error for proprietary feild

[Xizhen W. <wan...@ya...>]

Hi All,

A incoming FIX msg from counterparty contains their
proprietary tag (6602). QF rejected the message as
below:
(Message 107 Rejected: Invalid tag number:6602)

I use dictionary for repeating group. I wonder if this
is related to the rejection? How to fix the problem?

Thanks a lot!
Alvin

=====
/)_/)
( ._.)
c(")(")


		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 

[Quickfix-developers] toString Method

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

This was re-posted because the last email I sent was garbled for some
reason.

=20

When you call the toString method in the message class the string
returned is not guaranteed to be of the same exact format of the
original message. Since I need to be able to retrieve the original
message in the original format I added another member variable and
method to return this information. I have seen other posts commenting
about this. I need this when receiving user defined messages so I can
process them correctly. This probably should be added permanently. I can
post the code if you want to add this to the library.

=20

Thanks

Michael Holm

Liquid Capital Markets Ltd
11 Old Jewry
London EC2R 8DU
Tel:020 7726 3028

=20

[Quickfix-developers] Week Long Session Bug

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

This was re-posted because the last email I sent was garbled for some
reason.
=20
I am using QuickFix 1.6 to connect to SFE. I am planning on using the
newest version 1.94 and have found a weird bug with week long sessions.
I set the session to run from Monday - Friday. This works fine for the
first week but when it should start on the following Monday the only
thing that happens is that it creates a session and then hangs. Has
anyone seen this before? If I get rid of week long sessions everything
runs fine. I think the problem might have something to do with GMT
because their Monday is still Sunday to us. But I have tested this and
it still seems to be buggy. What is an example that you guys use for
CME, mo - fr etc..?=20

=20

Thanks

Michael Holm

Liquid Capital Markets Ltd
11 Old Jewry
London EC2R 8DU
Tel:020 7726 3028

=20

[Quickfix-developers] Re: Intermittent disconnect problem

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

I have seen a similar problem when connecting to SFE. They require that
I follow the heartbeat procedure defined in the Fix spec. with one
exception. At initial start-up time or at certain times throughout the
day they may blast a huge amount of data to me which needs to be
processed. The QuickFix engine gives priority to these messages and
starves the heartbeat time slice. So if I am processing these messages
for more then the agreed upon heartbeat period SFE will disconnect the
session on their side and then QuickFix re-establishes the session and
resyncs. And then they have to retransmit messages and as you can see I
will encounter a never ending loop of shit. So I modified the following
to code to stop QuickFix from starving the heartbeats.

=20

In the following method - void SocketInitiator::onData( SocketConnector&
connector, int s )

=20

The current code:

while( pSocketConnection->read( connector ) )

{}

=20

My modified version:

while( pSocketConnection->read( connector ) )=20

{

  // Modified 11-26-03 by M. Holm. Because heartbeats are being starved!

  i->second->onTimeout();

}

=20

This will ensure that heartbeats will be sent when necessary according
to the SFE spec.

=20

You might be having a similar problem to the one I encountered.

=20

Hope this helps.

=20

Michael Holm

Liquid Capital Markets Ltd
11 Old Jewry
London EC2R 8DU
Tel:020 7726 3028

=20

Re: [Quickfix-developers] What is the right way to override FIX types in QF

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

You can create a user defined field with the same field number, but a  
different type. Like this.

namespace FIX
{
	USER_DEFINE_INT( IntOrderQty, FIELD::OrderQty );
}

Then you can use setField and getField with this field.  Although as  
long as you cast your values to an int,  you should be able to use the  
OrderQty value if you like.

--oren

On Feb 1, 2005, at 4:41 PM, Narayan, Arvind wrote:

> QuickFIX Documentation:  
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ:  
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Cme uses an int field to represent OrderQty.
>
> What is the right way to create this field in userland so QF will
> actually publish an int field instead of a double?
>
> ----------------------------------------------------------------------- 
> -------
> This message is intended only for the personal and confidential use of  
> the designated recipient(s) named above.  If you are not the intended  
> recipient of this message you are hereby notified that any review,  
> dissemination, distribution or copying of this message is strictly  
> prohibited.  This communication is for information purposes only and  
> should not be regarded as an offer to sell or as a solicitation of an  
> offer to buy any financial product, an official confirmation of any  
> transaction, or as an official statement of Lehman Brothers.  Email  
> transmission cannot be guaranteed to be secure or error-free.   
> Therefore, we do not represent that this information is complete or  
> accurate and it should not be relied upon as such.  All information is  
> subject to change without notice.
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] RE: Intermittent disconnect problem

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

Yeah, that's not a problem.  The Parser throws a RecvFailed exception, 
so we would just need to return the error number in there.  We can 
create a base SocketException which has a default constructor which 
will get the error name and number as well as the human readable text.  
Then RecvFailed can inherit from it and it the base object will 
automatically get populated with this information if available.

--oren

On Feb 2, 2005, at 4:03 AM, Bishop, Barry wrote:

> So yes, it's a great idea to trap ERRNO around every socket call. To
> propogate this up to the session would mean starting at a low level. I 
> was
> surprised to find the call to recv() (and also socket_fionread) in 
> Parser,
> but that's where it would have to start.

RE: [Quickfix-developers] RE: Intermittent disconnect problem

[Bishop, B. <Bar...@gs...>]

Hi Oren,

Thanks again for your response.

I am definitely of the opinion that nothing should be thrown away,
especially regarding useful information about a runtime event/error.

So yes, it's a great idea to trap ERRNO around every socket call. To
propogate this up to the session would mean starting at a low level. I was
surprised to find the call to recv() (and also socket_fionread) in Parser,
but that's where it would have to start.

Regards,
barry


-----Original Message-----
From: Oren Miller [mailto:or...@qu...] 
Sent: Tuesday, February 01, 2005 5:25 PM
To: Bishop, Barry; qui...@li...
Cc: 'Caleb Epstein'; 'Perez, John'
Subject: Re: [Quickfix-developers] RE: Intermittent disconnect problem


Well, not necessarilly.  "Dropped Connection" right now just means that the 
connection was droppen outside of a logout sequence.  If QuickFIX knows the 
reason for this, it will be preceeded in the log for the reason, such as 
"Timed out waiting for heartbeat."

The only time I can think of where QF would not know the exact reason for a 
disconnect is if the socket is either broken somehow, or closed by the 
counterparty.  You can see in the SocketInitiator and SocketAcceptor 
onDisconnect methods, that Session::disconnect is being called.  This is the

only place where there is not an additional message that provides a 
disconnect reason.

What we can do is start logging the error codes of the socket calls to get a

more detailed analysis on what is hapenning with the socket.  For instance, 
calling close can set the global error code to one of the following.

      EBADF  The s argument is not an active descriptor.
      ECONNABORTED  The connection was aborted by the remote endpoint.
      ECONNREFUSED  The remote endpoint refused to continue the connection.
      ECONNRESET  The remote endpoint reset the connection request.
      EDESTUNREACH  Remote destination is now unreachable.
      EHOSTUNREACH  Remote host is now unreachable.
      ENETDOWN  Local network interface is down.
      ETIMEDOUT  The connection timed out.


I think that would get you the information you need to figure out the source

of the disconnect.

--oren

----- Original Message ----- 
From: "Bishop, Barry" <Bar...@gs...>
To: "'Oren Miller'" <or...@qu...>; 
<qui...@li...>
Cc: "'Caleb Epstein'" <cal...@gm...>; "'Perez, John'" 
<jp...@Cr...>
Sent: Tuesday, February 01, 2005 10:30 AM
Subject: RE: [Quickfix-developers] RE: Intermittent disconnect problem


> Hello Oren,
>
> I'm afraid there is no consistency as to when this happens. Sometimes 
> it doesn't happen for a week, whereas it could be 8 times a week 
> anywhere from 7:00AM to 9:00 PM.
>
> The amount of traffic is very low, maybe 1 or 2 messages per second at
> most.
>
> The outage doesn't last long and it's not a very big deal, but it 
> would be nice to get it fixed.
>
> Can you confirm that if quickfix logs the message 'Dropped Connection'
> then
> it was quickfix that disconnected? I believe this to be the case, but it
> seems that the code only tests to see if a logout has been sent.
>
> Should quickfix have logged another message if the above is true?
>
> In the meantime, I will take John Perez's advice and have a good look 
> through the last received message just in case this is related. 
> However, the disconnect often occurs many seconds after the last 
> message is sent or received.
>
> Thanks again,
> barry
>
>
>
> -----Original Message-----
> From: Oren Miller [mailto:or...@qu...]
> Sent: Tuesday, February 01, 2005 4:12 PM
> To: Bishop, Barry; qui...@li...
> Cc: 'Caleb Epstein'
> Subject: Re: [Quickfix-developers] RE: Intermittent disconnect problem
>
>
> Barry,
>
> Is there anything common about the times in which these disconnects 
> occur? Is this a high frequency line?  Is it possible you are 
> overloading the socket buffer?
>
> --oren
>
> ----- Original Message -----
> From: "Bishop, Barry" <Bar...@gs...>
> To: <qui...@li...>
> Cc: "Oren Miller" <or...@qu...>; "'Caleb Epstein'"
> <cal...@gm...>
> Sent: Tuesday, February 01, 2005 9:37 AM
> Subject: RE: [Quickfix-developers] RE: Intermittent disconnect problem
>
>
>> QuickFIX Documentation: 
>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>> QuickFIX FAQ: 
>> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>> Hello all,
>>
>> This is a follow up on a problem that I was having last year:
>>
>> quickfix seemingly disconnects from its peer without indicating why.
>>
>> We've upgraded our system to quickfix 1.9.4 in the hope of getting 
>> more useful messages, but we don't appear to. I've had a look through 
>> the code and I can't see quite how this could happen. However it 
>> does.
>>
>> To reiterate, at some random time quickfix disconnects the TCP 
>> seesion from its peer and logs this message in the event log:
>>
>> 20050201-13:33:27 : Dropped Connection
>>
>> This message indicates that quickfix initiated the disconnect, but it 
>> does not say why. The inbound and outbound messages all look fine and 
>> usually there has been a few seconds since the last message was sent 
>> anyway.
>>
>> What happens next is the usual reconnect, logon and resend request. 
>> Everything continues after this. Incidentally, since upgrading from 
>> quickfix 1.4.0 to 1.9.4 this reconnect/resync is a whole order of 
>> magnitude better behaved.
>>
>> However, the mysterious disconnect still occurs.
>>
>> Has anyone else seen anything like this?
>> Can anyone give me any suggestions as to how to track down the 
>> problem?
>>
>> We are running quickfix 1.9.4 on solaris 5.8
>> quickfix was built with GCC 3.2.2
>> We connect using SocketInitiator
>>
>> Thanks in advance,
>> barry
>>
>>
>>
>> Here are some excerpts from our logs:
>>
>> EVENT LOG
>> =========
>> 20050201-13:33:27 : Dropped Connection
>> 20050201-13:33:29 : Connecting to XXX.XXX.XXX.XXX on port YYYY 
>> 20050201-13:33:29 : Connection succeeded 20050201-13:33:29 : 
>> Initiated logon request 20050201-13:33:31 : Received logon response
>>
>>
>> INCOMING
>> ========
>> The last message before disconnecting 
>> 8=FIX.4.2|9=0183|35=R|115=2126|34=8349|49=CCCCCC|56=BBBBBB|52=2005020
>> 1
>> -13:32
>>
> :49|122=20050201-13:33:23|116=10101010101010101|144=ZZZZZZZ|131=200502
> 017287
>> |146=1|55=BBBBBB|48=773670|22=108|38=100|10=146|
>>
>> The logon response 
>> 8=FIX.4.2|9=0067|35=A|34=8351|49=CCCCCC|56=BBBBBB|52=20050201-13:32:5
>> 4
>> |98=0|
>> 108=30|10=004|
>>
>>
>> OUTGOING
>> ========
>> The last message before disconnecting 
>> 8=FIX.4.2|9=290|35=S|34=8232|49=BBBBBB|52=20050201-13:33:23.582|56=CC
>> C
>> CCC|12
>>
> 8=2126|129=10101010101010101|145=ZZZZZZZ|22=108|48=773670|55=GSAMFFT|1
> 07=des
>> cription|117=id|131=txn|132=1|133=2|134=50000|
>>
>> The logon after the disconnect 
>> 135=50000|167=OPT|200=200101|201=1|202=1.1|205=20|206=L|231=0.01|10=1
>> 8
>> 1|
>>
> 8=FIX.4.2|9=71|35=A|34=8233|49=GSAMFFT|52=20050201-13:33:29.210|56=CAT
> SOS|98
>> =0|108=30|10=098|
>>
>>
>> APPLICATION LOG
>> ===============
>> Tue Feb 1 13:33:23:528 GMT+00:00 2005|Received: 
>> quickfix.fix42.QuoteRequest Tue Feb 1 13:33:23:528 GMT+00:00 
>> 2005|toApp, SessionID=FIX.4.2:BBBBBB->CCCCCC, 
>> Message=quickfix.fix42.Quote Tue Feb 1 13:33:27:117 GMT+00:00 
>> 2005|onLogout, SessionID=FIX.4.2:BBBBBB->CCCCCC
>>
>>
>>
>> -----Original Message-----
>> From: Bishop, Barry
>> Sent: Tuesday, November 30, 2004 08:11 AM
>> To: or...@qu... [mailto:or...@qu...]
>> Cc: 'qui...@li...'
>> Subject: RE: [Quickfix-developers] Intermittent disconnect problem
>>
>> Hello Oren,
>>
>> Thanks for the reply.
>>
>> Sounds to me like I should try version 1.9.2 or later in  our 
>> production environment. I have been unable to reproduce the 
>> mysterious disconnect in our QA system to the same client, but this 
>> is not surprising as it is so infrequent. I have been simulating it 
>> by breaking something else in the chain (which would appear as a 
>> client
>> disconnect) so this would explain the lack of an explanation from
>> qdhÔuickfix.
>>
>> I will try this over the next few days and report back.
>>
>> Thanks again,
>> barry
>>
>>
>> -----Original Message-----
>> From: or...@qu... [mailto:or...@qu...]
>> Sent: Monday, November 29, 2004 7:56 PM
>> To: Bishop, Barry
>> Cc: 'qui...@li...'
>> Subject: RE: [Quickfix-developers] Intermittent disconnect problem
>>
>>
>> Barry,
>>
>> For every disconnect that QuickFIX initiates, there should be a 
>> reason provided (not with 1.4.0, but with the new releases).  With 
>> 1.9.4 (available now), QuickFIX also displays a "Dropped Connection" 
>> message if the disconnect is initiated by the peer (1.9.2, does not 
>> differentiate).  That should help you to verify if it is QuickFIX 
>> that is initiating the disconnect.  I don't think there are any more 
>> cases where QuickFIX initiates a disconnect without providing a 
>> reason.  If the couterparty drops the connection, then unless they 
>> provide information in the form of a reject or
>> logoff text, there is little QuickFIX can do to determine the cause.  The
>> best that we can probably do is report whether the socket was dropped
>> gracefully, and therefore intentionally, or if it was an abnormal
>> disconnect
>> of some sort.
>>
>> Is there anything significantly different about this new client?  
>> Does their logs reveal anything about the nature of the disconnect?
>>
>> --oren
>>
>>> 1) Anyone have any idea what's going on?
>>> 2) Is there a way to increase the amount of detail in log messages, 
>>> especially those to do with disconnection events?
>>> 3) What sort of thing would cause quickfix to disconnect without 
>>> saying why?
>>>
>>> Thanks in advance,
>>> barry
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real 
>> users. Discover which products truly live up to the hype. Start 
>> reading now. http://productguide.itmanagersjournal.com/
>> _______________________________________________
>> Quickfix-developers mailing list 
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive 
>> Reporting Tool for open source databases. Create drag-&-drop reports. 
>> Save time by over 75%! Publish reports on the web. Export to DOC, 
>> XLS, RTF, etc. Download a FREE copy at 
>> http://www.intelliview.com/go/osdn_nl
>> _______________________________________________
>> Quickfix-developers mailing list 
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
> 

[Quickfix-developers] ignore

[Narayan, A. <Arv...@le...>]

test


---------------------------------------------------------------------------=
---
This message is intended only for the personal and confidential use of the =
designated recipient(s) named above.  If you are not the intended recipient=
 =
of this message you are hereby notified that any review, dissemination, =
distribution or copying of this message is strictly prohibited.  This =
communication is for information purposes only and should not be regarded a=
s=
 an offer to sell or as a solicitation of an offer to buy any financial =
product, an official confirmation of any transaction, or as an official =
statement of Lehman Brothers.  Email transmission cannot be guaranteed to b=
e=
 secure or error-free.  Therefore, we do not represent that this informatio=
n=
 is complete or accurate and it should not be relied upon as such.  All =
information is subject to change without notice.

[Quickfix-developers] What is the right way to override FIX types in QF

[Narayan, A. <Arv...@le...>]

Cme uses an int field to represent OrderQty.

What is the right way to create this field in userland so QF will
actually publish an int field instead of a double=3F

---------------------------------------------------------------------------=
---
This message is intended only for the personal and confidential use of the =
designated recipient(s) named above.  If you are not the intended recipient=
 =
of this message you are hereby notified that any review, dissemination, =
distribution or copying of this message is strictly prohibited.  This =
communication is for information purposes only and should not be regarded a=
s=
 an offer to sell or as a solicitation of an offer to buy any financial =
product, an official confirmation of any transaction, or as an official =
statement of Lehman Brothers.  Email transmission cannot be guaranteed to b=
e=
 secure or error-free.  Therefore, we do not represent that this informatio=
n=
 is complete or accurate and it should not be relied upon as such.  All =
information is subject to change without notice.

RE: [Quickfix-developers] RE: Intermittent disconnect problem

[Yihu F. <Yih...@re...>]

Sounds good.

Another alternative is to provide a callback (e.g. onError()) in the Applic=
ation interface so that the application has better control or view of what =
is really going on in the FIX engine.

-Yihu

-----Original Message-----
From: Oren Miller [mailto:or...@qu...]=20
Sent: Tuesday, February 01, 2005 1:31 PM
To: Yihu Fang; Bishop, Barry; qui...@li...
Cc: Caleb Epstein; Perez, John
Subject: Re: [Quickfix-developers] RE: Intermittent disconnect problem

Yeah, for the first scenario we will be implementing a global logger.  Righ=
t=20
now as you know all loggers are associated with a specific session, so if=
 there is something of interest that cannot be associated with a session, i=
t=20
doesn't have a place to report it.

The second scenario will be easy to implement since we can place the=20
duplicate logon attempt into the original sessions log.  start/end time=20
logging will also be easy to implement.

--oren

----- Original Message -----=20
From: "Yihu Fang" <Yih...@re...>
To: "Oren Miller" <or...@qu...>; "Bishop, Barry"=20
<Bar...@gs...>; <qui...@li...>
Cc: "Caleb Epstein" <cal...@gm...>; "Perez, John"=20
<jp...@Cr...>
Sent: Tuesday, February 01, 2005 11:50 AM
Subject: RE: [Quickfix-developers] RE: Intermittent disconnect problem


Hi,

I understand that this discussion is about initiator gets disconnected.

However, for a separate issue regarding QuickFIX acceptor, the acceptor=20
silently drops the connection without any error message at least in the=20
following scenario. (see ThreadedSocketConnection.cpp::setSession())

(1) If the incoming message does not have correct session header.
(2) If the acceptor already establishes a session, a second connection from=
 the same client tries to connect to the same port.

It also silently drops connection if the incoming connection is out of=20
session window (startTime/endTime etc).

It will be very help that QuickFIX can provide appropriate error messages=
 for these cases too.

Thanks.

-Yihu


-----Original Message-----
From: qui...@li...=20
[mailto:qui...@li...] On Behalf Of Oren=
 Miller
Sent: Tuesday, February 01, 2005 12:25 PM
To: Bishop, Barry; qui...@li...
Cc: 'Caleb Epstein'; 'Perez, John'
Subject: Re: [Quickfix-developers] RE: Intermittent disconnect problem

QuickFIX Documentation:=20
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html

Well, not necessarilly.  "Dropped Connection" right now just means that the=
 connection was droppen outside of a logout sequence.  If QuickFIX knows the
reason for this, it will be preceeded in the log for the reason, such as
"Timed out waiting for heartbeat."

The only time I can think of where QF would not know the exact reason for a=
 disconnect is if the socket is either broken somehow, or closed by the
counterparty.  You can see in the SocketInitiator and SocketAcceptor
onDisconnect methods, that Session::disconnect is being called.  This is the
only place where there is not an additional message that provides a
disconnect reason.

What we can do is start logging the error codes of the socket calls to get a
more detailed analysis on what is hapenning with the socket.  For instance,=
 calling close can set the global error code to one of the following.

      EBADF  The s argument is not an active descriptor.
      ECONNABORTED  The connection was aborted by the remote endpoint.
      ECONNREFUSED  The remote endpoint refused to continue the connection.
      ECONNRESET  The remote endpoint reset the connection request.
      EDESTUNREACH  Remote destination is now unreachable.
      EHOSTUNREACH  Remote host is now unreachable.
      ENETDOWN  Local network interface is down.
      ETIMEDOUT  The connection timed out.


I think that would get you the information you need to figure out the source
of the disconnect.

--oren

----- Original Message -----=20
From: "Bishop, Barry" <Bar...@gs...>
To: "'Oren Miller'" <or...@qu...>;
<qui...@li...>
Cc: "'Caleb Epstein'" <cal...@gm...>; "'Perez, John'"
<jp...@Cr...>
Sent: Tuesday, February 01, 2005 10:30 AM
Subject: RE: [Quickfix-developers] RE: Intermittent disconnect problem


> Hello Oren,
>
> I'm afraid there is no consistency as to when this happens. Sometimes it
> doesn't happen for a week, whereas it could be 8 times a week anywhere
> from
> 7:00AM to 9:00 PM.
>
> The amount of traffic is very low, maybe 1 or 2 messages per second at
> most.
>
> The outage doesn't last long and it's not a very big deal, but it would be
> nice to get it fixed.
>
> Can you confirm that if quickfix logs the message 'Dropped Connection'
> then
> it was quickfix that disconnected? I believe this to be the case, but it
> seems that the code only tests to see if a logout has been sent.
>
> Should quickfix have logged another message if the above is true?
>
> In the meantime, I will take John Perez's advice and have a good look
> through the last received message just in case this is related. However, =
>=20
> the
> disconnect often occurs many seconds after the last message is sent or
> received.
>
> Thanks again,
> barry
>
>
>
> -----Original Message-----
> From: Oren Miller [mailto:or...@qu...]
> Sent: Tuesday, February 01, 2005 4:12 PM
> To: Bishop, Barry; qui...@li...
> Cc: 'Caleb Epstein'
> Subject: Re: [Quickfix-developers] RE: Intermittent disconnect problem
>
>
> Barry,
>
> Is there anything common about the times in which these disconnects occur?
> Is this a high frequency line?  Is it possible you are overloading the
> socket buffer?
>
> --oren
>
> ----- Original Message -----=20
> From: "Bishop, Barry" <Bar...@gs...>
> To: <qui...@li...>
> Cc: "Oren Miller" <or...@qu...>; "'Caleb Epstein'"
> <cal...@gm...>
> Sent: Tuesday, February 01, 2005 9:37 AM
> Subject: RE: [Quickfix-developers] RE: Intermittent disconnect problem
>
>
>> QuickFIX Documentation:
>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>> Hello all,
>>
>> This is a follow up on a problem that I was having last year:
>>
>> quickfix seemingly disconnects from its peer without indicating why.
>>
>> We've upgraded our system to quickfix 1.9.4 in the hope of getting
>> more useful messages, but we don't appear to. I've had a look through
>> the code and I can't see quite how this could happen. However it does.
>>
>> To reiterate, at some random time quickfix disconnects the TCP seesion
>> from
>> its peer and logs this message in the event log:
>>
>> 20050201-13:33:27 : Dropped Connection
>>
>> This message indicates that quickfix initiated the disconnect, but it
>> does not say why. The inbound and outbound messages all look fine and
>> usually there has been a few seconds since the last message was sent
>> anyway.
>>
>> What happens next is the usual reconnect, logon and resend request.
>> Everything continues after this. Incidentally, since upgrading from
>> quickfix 1.4.0 to 1.9.4 this reconnect/resync is a whole order of
>> magnitude better behaved.
>>
>> However, the mysterious disconnect still occurs.
>>
>> Has anyone else seen anything like this?
>> Can anyone give me any suggestions as to how to track down the
>> problem?
>>
>> We are running quickfix 1.9.4 on solaris 5.8
>> quickfix was built with GCC 3.2.2
>> We connect using SocketInitiator
>>
>> Thanks in advance,
>> barry
>>
>>
>>
>> Here are some excerpts from our logs:
>>
>> EVENT LOG
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>> 20050201-13:33:27 : Dropped Connection
>> 20050201-13:33:29 : Connecting to XXX.XXX.XXX.XXX on port YYYY
>> 20050201-13:33:29 : Connection succeeded 20050201-13:33:29 : Initiated
>> logon request 20050201-13:33:31 : Received logon response
>>
>>
>> INCOMING
>> =3D=3D=3D=3D=3D=3D=3D=3D
>> The last message before disconnecting
>> 8=3DFIX.4.2|9=3D0183|35=3DR|115=3D2126|34=3D8349|49=3DCCCCCC|56=3DBBBBBB=
|52=3D20050201
>> -13:32
>>
> :49|122=3D20050201-13:33:23|116=3D10101010101010101|144=3DZZZZZZZ|131=3D2=
00502017287
>> |146=3D1|55=3DBBBBBB|48=3D773670|22=3D108|38=3D100|10=3D146|
>>
>> The logon response
>> 8=3DFIX.4.2|9=3D0067|35=3DA|34=3D8351|49=3DCCCCCC|56=3DBBBBBB|52=3D20050=
201-13:32:54
>> |98=3D0|
>> 108=3D30|10=3D004|
>>
>>
>> OUTGOING
>> =3D=3D=3D=3D=3D=3D=3D=3D
>> The last message before disconnecting
>> 8=3DFIX.4.2|9=3D290|35=3DS|34=3D8232|49=3DBBBBBB|52=3D20050201-13:33:23.=
582|56=3DCCC
>> CCC|12
>>
> 8=3D2126|129=3D10101010101010101|145=3DZZZZZZZ|22=3D108|48=3D773670|55=3D=
GSAMFFT|107=3Ddes
>> cription|117=3Did|131=3Dtxn|132=3D1|133=3D2|134=3D50000|
>>
>> The logon after the disconnect
>> 135=3D50000|167=3DOPT|200=3D200101|201=3D1|202=3D1.1|205=3D20|206=3DL|23=
1=3D0.01|10=3D18
>> 1|
>>
> 8=3DFIX.4.2|9=3D71|35=3DA|34=3D8233|49=3DGSAMFFT|52=3D20050201-13:33:29.2=
10|56=3DCATSOS|98
>> =3D0|108=3D30|10=3D098|
>>
>>
>> APPLICATION LOG
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> Tue Feb 1 13:33:23:528 GMT+00:00 2005|Received:
>> quickfix.fix42.QuoteRequest
>> Tue Feb 1 13:33:23:528 GMT+00:00 2005|toApp,
>> SessionID=3DFIX.4.2:BBBBBB->CCCCCC, Message=3Dquickfix.fix42.Quote
>> Tue Feb 1 13:33:27:117 GMT+00:00 2005|onLogout,
>> SessionID=3DFIX.4.2:BBBBBB->CCCCCC
>>
>>
>>
>> -----Original Message-----
>> From: Bishop, Barry
>> Sent: Tuesday, November 30, 2004 08:11 AM
>> To: or...@qu... [mailto:or...@qu...]
>> Cc: 'qui...@li...'
>> Subject: RE: [Quickfix-developers] Intermittent disconnect problem
>>
>> Hello Oren,
>>
>> Thanks for the reply.
>>
>> Sounds to me like I should try version 1.9.2 or later in  our
>> production environment. I have been unable to reproduce the mysterious
>> disconnect in our QA system to the same client, but this is not
>> surprising as it is so infrequent. I have been simulating it by
>> breaking something else in the chain (which would appear as a client
>> disconnect) so this would explain the lack of an explanation from
>> qdh=D4uickfix.
>>
>> I will try this over the next few days and report back.
>>
>> Thanks again,
>> barry
>>
>>
>> -----Original Message-----
>> From: or...@qu... [mailto:or...@qu...]
>> Sent: Monday, November 29, 2004 7:56 PM
>> To: Bishop, Barry
>> Cc: 'qui...@li...'
>> Subject: RE: [Quickfix-developers] Intermittent disconnect problem
>>
>>
>> Barry,
>>
>> For every disconnect that QuickFIX initiates, there should be a reason
>> provided (not with 1.4.0, but with the new releases).  With 1.9.4
>> (available now), QuickFIX also displays a "Dropped Connection" message
>> if the disconnect is initiated by the peer (1.9.2, does not
>> differentiate).  That should help you to verify if it is QuickFIX that
>> is initiating the disconnect.  I don't think there are any more cases
>> where QuickFIX initiates
>> a disconnect without providing a reason.  If the couterparty drops the
>> connection, then unless they provide information in the form of a reject
>> or
>> logoff text, there is little QuickFIX can do to determine the cause.  The
>> best that we can probably do is report whether the socket was dropped
>> gracefully, and therefore intentionally, or if it was an abnormal
>> disconnect
>> of some sort.
>>
>> Is there anything significantly different about this new client?  Does
>> their
>> logs reveal anything about the nature of the disconnect?
>>
>> --oren
>>
>>> 1) Anyone have any idea what's going on?
>>> 2) Is there a way to increase the amount of detail in log messages,
>>> especially those to do with disconnection events?
>>> 3) What sort of thing would cause quickfix to disconnect without
>>> saying why?
>>>
>>> Thanks in advance,
>>> barry
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real
>> users. Discover which products truly live up to the hype. Start
>> reading now. http://productguide.itmanagersjournal.com/
>> _______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive
>> Reporting Tool for open source databases. Create drag-&-drop reports.
>> Save time by over 75%! Publish reports on the web. Export to DOC, XLS,
>> RTF, etc. Download a FREE copy at
>> http://www.intelliview.com/go/osdn_nl
>> _______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers



-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.





-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.

Re: [Quickfix-developers] RE: Intermittent disconnect problem

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

Yeah, for the first scenario we will be implementing a global logger.  Right 
now as you know all loggers are associated with a specific session, so if 
there is something of interest that cannot be associated with a session, it 
doesn't have a place to report it.

The second scenario will be easy to implement since we can place the 
duplicate logon attempt into the original sessions log.  start/end time 
logging will also be easy to implement.

--oren

----- Original Message ----- 
From: "Yihu Fang" <Yih...@re...>
To: "Oren Miller" <or...@qu...>; "Bishop, Barry" 
<Bar...@gs...>; <qui...@li...>
Cc: "Caleb Epstein" <cal...@gm...>; "Perez, John" 
<jp...@Cr...>
Sent: Tuesday, February 01, 2005 11:50 AM
Subject: RE: [Quickfix-developers] RE: Intermittent disconnect problem


Hi,

I understand that this discussion is about initiator gets disconnected.

However, for a separate issue regarding QuickFIX acceptor, the acceptor 
silently drops the connection without any error message at least in the 
following scenario. (see ThreadedSocketConnection.cpp::setSession())

(1) If the incoming message does not have correct session header.
(2) If the acceptor already establishes a session, a second connection from 
the same client tries to connect to the same port.

It also silently drops connection if the incoming connection is out of 
session window (startTime/endTime etc).

It will be very help that QuickFIX can provide appropriate error messages 
for these cases too.

Thanks.

-Yihu


-----Original Message-----
From: qui...@li... 
[mailto:qui...@li...] On Behalf Of Oren 
Miller
Sent: Tuesday, February 01, 2005 12:25 PM
To: Bishop, Barry; qui...@li...
Cc: 'Caleb Epstein'; 'Perez, John'
Subject: Re: [Quickfix-developers] RE: Intermittent disconnect problem

QuickFIX Documentation: 
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html

Well, not necessarilly.  "Dropped Connection" right now just means that the 
connection was droppen outside of a logout sequence.  If QuickFIX knows the
reason for this, it will be preceeded in the log for the reason, such as
"Timed out waiting for heartbeat."

The only time I can think of where QF would not know the exact reason for a 
disconnect is if the socket is either broken somehow, or closed by the
counterparty.  You can see in the SocketInitiator and SocketAcceptor
onDisconnect methods, that Session::disconnect is being called.  This is the
only place where there is not an additional message that provides a
disconnect reason.

What we can do is start logging the error codes of the socket calls to get a
more detailed analysis on what is hapenning with the socket.  For instance, 
calling close can set the global error code to one of the following.

      EBADF  The s argument is not an active descriptor.
      ECONNABORTED  The connection was aborted by the remote endpoint.
      ECONNREFUSED  The remote endpoint refused to continue the connection.
      ECONNRESET  The remote endpoint reset the connection request.
      EDESTUNREACH  Remote destination is now unreachable.
      EHOSTUNREACH  Remote host is now unreachable.
      ENETDOWN  Local network interface is down.
      ETIMEDOUT  The connection timed out.


I think that would get you the information you need to figure out the source
of the disconnect.

--oren

----- Original Message ----- 
From: "Bishop, Barry" <Bar...@gs...>
To: "'Oren Miller'" <or...@qu...>;
<qui...@li...>
Cc: "'Caleb Epstein'" <cal...@gm...>; "'Perez, John'"
<jp...@Cr...>
Sent: Tuesday, February 01, 2005 10:30 AM
Subject: RE: [Quickfix-developers] RE: Intermittent disconnect problem


> Hello Oren,
>
> I'm afraid there is no consistency as to when this happens. Sometimes it
> doesn't happen for a week, whereas it could be 8 times a week anywhere
> from
> 7:00AM to 9:00 PM.
>
> The amount of traffic is very low, maybe 1 or 2 messages per second at
> most.
>
> The outage doesn't last long and it's not a very big deal, but it would be
> nice to get it fixed.
>
> Can you confirm that if quickfix logs the message 'Dropped Connection'
> then
> it was quickfix that disconnected? I believe this to be the case, but it
> seems that the code only tests to see if a logout has been sent.
>
> Should quickfix have logged another message if the above is true?
>
> In the meantime, I will take John Perez's advice and have a good look
> through the last received message just in case this is related. However, > 
> the
> disconnect often occurs many seconds after the last message is sent or
> received.
>
> Thanks again,
> barry
>
>
>
> -----Original Message-----
> From: Oren Miller [mailto:or...@qu...]
> Sent: Tuesday, February 01, 2005 4:12 PM
> To: Bishop, Barry; qui...@li...
> Cc: 'Caleb Epstein'
> Subject: Re: [Quickfix-developers] RE: Intermittent disconnect problem
>
>
> Barry,
>
> Is there anything common about the times in which these disconnects occur?
> Is this a high frequency line?  Is it possible you are overloading the
> socket buffer?
>
> --oren
>
> ----- Original Message ----- 
> From: "Bishop, Barry" <Bar...@gs...>
> To: <qui...@li...>
> Cc: "Oren Miller" <or...@qu...>; "'Caleb Epstein'"
> <cal...@gm...>
> Sent: Tuesday, February 01, 2005 9:37 AM
> Subject: RE: [Quickfix-developers] RE: Intermittent disconnect problem
>
>
>> QuickFIX Documentation:
>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>> Hello all,
>>
>> This is a follow up on a problem that I was having last year:
>>
>> quickfix seemingly disconnects from its peer without indicating why.
>>
>> We've upgraded our system to quickfix 1.9.4 in the hope of getting
>> more useful messages, but we don't appear to. I've had a look through
>> the code and I can't see quite how this could happen. However it does.
>>
>> To reiterate, at some random time quickfix disconnects the TCP seesion
>> from
>> its peer and logs this message in the event log:
>>
>> 20050201-13:33:27 : Dropped Connection
>>
>> This message indicates that quickfix initiated the disconnect, but it
>> does not say why. The inbound and outbound messages all look fine and
>> usually there has been a few seconds since the last message was sent
>> anyway.
>>
>> What happens next is the usual reconnect, logon and resend request.
>> Everything continues after this. Incidentally, since upgrading from
>> quickfix 1.4.0 to 1.9.4 this reconnect/resync is a whole order of
>> magnitude better behaved.
>>
>> However, the mysterious disconnect still occurs.
>>
>> Has anyone else seen anything like this?
>> Can anyone give me any suggestions as to how to track down the
>> problem?
>>
>> We are running quickfix 1.9.4 on solaris 5.8
>> quickfix was built with GCC 3.2.2
>> We connect using SocketInitiator
>>
>> Thanks in advance,
>> barry
>>
>>
>>
>> Here are some excerpts from our logs:
>>
>> EVENT LOG
>> =========
>> 20050201-13:33:27 : Dropped Connection
>> 20050201-13:33:29 : Connecting to XXX.XXX.XXX.XXX on port YYYY
>> 20050201-13:33:29 : Connection succeeded 20050201-13:33:29 : Initiated
>> logon request 20050201-13:33:31 : Received logon response
>>
>>
>> INCOMING
>> ========
>> The last message before disconnecting
>> 8=FIX.4.2|9=0183|35=R|115=2126|34=8349|49=CCCCCC|56=BBBBBB|52=20050201
>> -13:32
>>
> :49|122=20050201-13:33:23|116=10101010101010101|144=ZZZZZZZ|131=200502017287
>> |146=1|55=BBBBBB|48=773670|22=108|38=100|10=146|
>>
>> The logon response
>> 8=FIX.4.2|9=0067|35=A|34=8351|49=CCCCCC|56=BBBBBB|52=20050201-13:32:54
>> |98=0|
>> 108=30|10=004|
>>
>>
>> OUTGOING
>> ========
>> The last message before disconnecting
>> 8=FIX.4.2|9=290|35=S|34=8232|49=BBBBBB|52=20050201-13:33:23.582|56=CCC
>> CCC|12
>>
> 8=2126|129=10101010101010101|145=ZZZZZZZ|22=108|48=773670|55=GSAMFFT|107=des
>> cription|117=id|131=txn|132=1|133=2|134=50000|
>>
>> The logon after the disconnect
>> 135=50000|167=OPT|200=200101|201=1|202=1.1|205=20|206=L|231=0.01|10=18
>> 1|
>>
> 8=FIX.4.2|9=71|35=A|34=8233|49=GSAMFFT|52=20050201-13:33:29.210|56=CATSOS|98
>> =0|108=30|10=098|
>>
>>
>> APPLICATION LOG
>> ===============
>> Tue Feb 1 13:33:23:528 GMT+00:00 2005|Received:
>> quickfix.fix42.QuoteRequest
>> Tue Feb 1 13:33:23:528 GMT+00:00 2005|toApp,
>> SessionID=FIX.4.2:BBBBBB->CCCCCC, Message=quickfix.fix42.Quote
>> Tue Feb 1 13:33:27:117 GMT+00:00 2005|onLogout,
>> SessionID=FIX.4.2:BBBBBB->CCCCCC
>>
>>
>>
>> -----Original Message-----
>> From: Bishop, Barry
>> Sent: Tuesday, November 30, 2004 08:11 AM
>> To: or...@qu... [mailto:or...@qu...]
>> Cc: 'qui...@li...'
>> Subject: RE: [Quickfix-developers] Intermittent disconnect problem
>>
>> Hello Oren,
>>
>> Thanks for the reply.
>>
>> Sounds to me like I should try version 1.9.2 or later in  our
>> production environment. I have been unable to reproduce the mysterious
>> disconnect in our QA system to the same client, but this is not
>> surprising as it is so infrequent. I have been simulating it by
>> breaking something else in the chain (which would appear as a client
>> disconnect) so this would explain the lack of an explanation from
>> qdhÔuickfix.
>>
>> I will try this over the next few days and report back.
>>
>> Thanks again,
>> barry
>>
>>
>> -----Original Message-----
>> From: or...@qu... [mailto:or...@qu...]
>> Sent: Monday, November 29, 2004 7:56 PM
>> To: Bishop, Barry
>> Cc: 'qui...@li...'
>> Subject: RE: [Quickfix-developers] Intermittent disconnect problem
>>
>>
>> Barry,
>>
>> For every disconnect that QuickFIX initiates, there should be a reason
>> provided (not with 1.4.0, but with the new releases).  With 1.9.4
>> (available now), QuickFIX also displays a "Dropped Connection" message
>> if the disconnect is initiated by the peer (1.9.2, does not
>> differentiate).  That should help you to verify if it is QuickFIX that
>> is initiating the disconnect.  I don't think there are any more cases
>> where QuickFIX initiates
>> a disconnect without providing a reason.  If the couterparty drops the
>> connection, then unless they provide information in the form of a reject
>> or
>> logoff text, there is little QuickFIX can do to determine the cause.  The
>> best that we can probably do is report whether the socket was dropped
>> gracefully, and therefore intentionally, or if it was an abnormal
>> disconnect
>> of some sort.
>>
>> Is there anything significantly different about this new client?  Does
>> their
>> logs reveal anything about the nature of the disconnect?
>>
>> --oren
>>
>>> 1) Anyone have any idea what's going on?
>>> 2) Is there a way to increase the amount of detail in log messages,
>>> especially those to do with disconnection events?
>>> 3) What sort of thing would cause quickfix to disconnect without
>>> saying why?
>>>
>>> Thanks in advance,
>>> barry
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real
>> users. Discover which products truly live up to the hype. Start
>> reading now. http://productguide.itmanagersjournal.com/
>> _______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive
>> Reporting Tool for open source databases. Create drag-&-drop reports.
>> Save time by over 75%! Publish reports on the web. Export to DOC, XLS,
>> RTF, etc. Download a FREE copy at
>> http://www.intelliview.com/go/osdn_nl
>> _______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers



-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.

RE: [Quickfix-developers] RE: Intermittent disconnect problem

[Yihu F. <Yih...@re...>]

Hi,

I understand that this discussion is about initiator gets disconnected.=20

However, for a separate issue regarding QuickFIX acceptor, the acceptor sil=
ently drops the connection without any error message at least in the follow=
ing scenario. (see ThreadedSocketConnection.cpp::setSession())

(1) If the incoming message does not have correct session header.
(2) If the acceptor already establishes a session, a second connection from=
 the same client tries to connect to the same port.

It also silently drops connection if the incoming connection is out of sess=
ion window (startTime/endTime etc).

It will be very help that QuickFIX can provide appropriate error messages f=
or these cases too.

Thanks.

-Yihu


-----Original Message-----
From: qui...@li... [mailto:quickfix-deve=
lop...@li...] On Behalf Of Oren Miller
Sent: Tuesday, February 01, 2005 12:25 PM
To: Bishop, Barry; qui...@li...
Cc: 'Caleb Epstein'; 'Perez, John'
Subject: Re: [Quickfix-developers] RE: Intermittent disconnect problem

QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/ind=
ex.html
QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html

Well, not necessarilly.  "Dropped Connection" right now just means that the=
 connection was droppen outside of a logout sequence.  If QuickFIX knows th=
e=20
reason for this, it will be preceeded in the log for the reason, such as=20
"Timed out waiting for heartbeat."

The only time I can think of where QF would not know the exact reason for a=
 disconnect is if the socket is either broken somehow, or closed by the=20
counterparty.  You can see in the SocketInitiator and SocketAcceptor=20
onDisconnect methods, that Session::disconnect is being called.  This is th=
e=20
only place where there is not an additional message that provides a=20
disconnect reason.

What we can do is start logging the error codes of the socket calls to get =
a=20
more detailed analysis on what is hapenning with the socket.  For instance,=
 calling close can set the global error code to one of the following.

      EBADF  The s argument is not an active descriptor.
      ECONNABORTED  The connection was aborted by the remote endpoint.
      ECONNREFUSED  The remote endpoint refused to continue the connection.
      ECONNRESET  The remote endpoint reset the connection request.
      EDESTUNREACH  Remote destination is now unreachable.
      EHOSTUNREACH  Remote host is now unreachable.
      ENETDOWN  Local network interface is down.
      ETIMEDOUT  The connection timed out.


I think that would get you the information you need to figure out the sourc=
e=20
of the disconnect.

--oren

----- Original Message -----=20
From: "Bishop, Barry" <Bar...@gs...>
To: "'Oren Miller'" <or...@qu...>;=20
<qui...@li...>
Cc: "'Caleb Epstein'" <cal...@gm...>; "'Perez, John'"=20
<jp...@Cr...>
Sent: Tuesday, February 01, 2005 10:30 AM
Subject: RE: [Quickfix-developers] RE: Intermittent disconnect problem


> Hello Oren,
>
> I'm afraid there is no consistency as to when this happens. Sometimes it
> doesn't happen for a week, whereas it could be 8 times a week anywhere=20
> from
> 7:00AM to 9:00 PM.
>
> The amount of traffic is very low, maybe 1 or 2 messages per second at=20
> most.
>
> The outage doesn't last long and it's not a very big deal, but it would be
> nice to get it fixed.
>
> Can you confirm that if quickfix logs the message 'Dropped Connection'=20
> then
> it was quickfix that disconnected? I believe this to be the case, but it
> seems that the code only tests to see if a logout has been sent.
>
> Should quickfix have logged another message if the above is true?
>
> In the meantime, I will take John Perez's advice and have a good look
> through the last received message just in case this is related. However,=
 > the
> disconnect often occurs many seconds after the last message is sent or
> received.
>
> Thanks again,
> barry
>
>
>
> -----Original Message-----
> From: Oren Miller [mailto:or...@qu...]
> Sent: Tuesday, February 01, 2005 4:12 PM
> To: Bishop, Barry; qui...@li...
> Cc: 'Caleb Epstein'
> Subject: Re: [Quickfix-developers] RE: Intermittent disconnect problem
>
>
> Barry,
>
> Is there anything common about the times in which these disconnects occur?
> Is this a high frequency line?  Is it possible you are overloading the
> socket buffer?
>
> --oren
>
> ----- Original Message -----=20
> From: "Bishop, Barry" <Bar...@gs...>
> To: <qui...@li...>
> Cc: "Oren Miller" <or...@qu...>; "'Caleb Epstein'"
> <cal...@gm...>
> Sent: Tuesday, February 01, 2005 9:37 AM
> Subject: RE: [Quickfix-developers] RE: Intermittent disconnect problem
>
>
>> QuickFIX Documentation:
>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>> Hello all,
>>
>> This is a follow up on a problem that I was having last year:
>>
>> quickfix seemingly disconnects from its peer without indicating why.
>>
>> We've upgraded our system to quickfix 1.9.4 in the hope of getting
>> more useful messages, but we don't appear to. I've had a look through
>> the code and I can't see quite how this could happen. However it does.
>>
>> To reiterate, at some random time quickfix disconnects the TCP seesion
>> from
>> its peer and logs this message in the event log:
>>
>> 20050201-13:33:27 : Dropped Connection
>>
>> This message indicates that quickfix initiated the disconnect, but it
>> does not say why. The inbound and outbound messages all look fine and
>> usually there has been a few seconds since the last message was sent
>> anyway.
>>
>> What happens next is the usual reconnect, logon and resend request.
>> Everything continues after this. Incidentally, since upgrading from
>> quickfix 1.4.0 to 1.9.4 this reconnect/resync is a whole order of
>> magnitude better behaved.
>>
>> However, the mysterious disconnect still occurs.
>>
>> Has anyone else seen anything like this?
>> Can anyone give me any suggestions as to how to track down the
>> problem?
>>
>> We are running quickfix 1.9.4 on solaris 5.8
>> quickfix was built with GCC 3.2.2
>> We connect using SocketInitiator
>>
>> Thanks in advance,
>> barry
>>
>>
>>
>> Here are some excerpts from our logs:
>>
>> EVENT LOG
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>> 20050201-13:33:27 : Dropped Connection
>> 20050201-13:33:29 : Connecting to XXX.XXX.XXX.XXX on port YYYY
>> 20050201-13:33:29 : Connection succeeded 20050201-13:33:29 : Initiated
>> logon request 20050201-13:33:31 : Received logon response
>>
>>
>> INCOMING
>> =3D=3D=3D=3D=3D=3D=3D=3D
>> The last message before disconnecting
>> 8=3DFIX.4.2|9=3D0183|35=3DR|115=3D2126|34=3D8349|49=3DCCCCCC|56=3DBBBBBB=
|52=3D20050201
>> -13:32
>>
> :49|122=3D20050201-13:33:23|116=3D10101010101010101|144=3DZZZZZZZ|131=3D2=
00502017287
>> |146=3D1|55=3DBBBBBB|48=3D773670|22=3D108|38=3D100|10=3D146|
>>
>> The logon response
>> 8=3DFIX.4.2|9=3D0067|35=3DA|34=3D8351|49=3DCCCCCC|56=3DBBBBBB|52=3D20050=
201-13:32:54
>> |98=3D0|
>> 108=3D30|10=3D004|
>>
>>
>> OUTGOING
>> =3D=3D=3D=3D=3D=3D=3D=3D
>> The last message before disconnecting
>> 8=3DFIX.4.2|9=3D290|35=3DS|34=3D8232|49=3DBBBBBB|52=3D20050201-13:33:23.=
582|56=3DCCC
>> CCC|12
>>
> 8=3D2126|129=3D10101010101010101|145=3DZZZZZZZ|22=3D108|48=3D773670|55=3D=
GSAMFFT|107=3Ddes
>> cription|117=3Did|131=3Dtxn|132=3D1|133=3D2|134=3D50000|
>>
>> The logon after the disconnect
>> 135=3D50000|167=3DOPT|200=3D200101|201=3D1|202=3D1.1|205=3D20|206=3DL|23=
1=3D0.01|10=3D18
>> 1|
>>
> 8=3DFIX.4.2|9=3D71|35=3DA|34=3D8233|49=3DGSAMFFT|52=3D20050201-13:33:29.2=
10|56=3DCATSOS|98
>> =3D0|108=3D30|10=3D098|
>>
>>
>> APPLICATION LOG
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> Tue Feb 1 13:33:23:528 GMT+00:00 2005|Received:
>> quickfix.fix42.QuoteRequest
>> Tue Feb 1 13:33:23:528 GMT+00:00 2005|toApp,
>> SessionID=3DFIX.4.2:BBBBBB->CCCCCC, Message=3Dquickfix.fix42.Quote
>> Tue Feb 1 13:33:27:117 GMT+00:00 2005|onLogout,
>> SessionID=3DFIX.4.2:BBBBBB->CCCCCC
>>
>>
>>
>> -----Original Message-----
>> From: Bishop, Barry
>> Sent: Tuesday, November 30, 2004 08:11 AM
>> To: or...@qu... [mailto:or...@qu...]
>> Cc: 'qui...@li...'
>> Subject: RE: [Quickfix-developers] Intermittent disconnect problem
>>
>> Hello Oren,
>>
>> Thanks for the reply.
>>
>> Sounds to me like I should try version 1.9.2 or later in  our
>> production environment. I have been unable to reproduce the mysterious
>> disconnect in our QA system to the same client, but this is not
>> surprising as it is so infrequent. I have been simulating it by
>> breaking something else in the chain (which would appear as a client
>> disconnect) so this would explain the lack of an explanation from
>> qdh=D4uickfix.
>>
>> I will try this over the next few days and report back.
>>
>> Thanks again,
>> barry
>>
>>
>> -----Original Message-----
>> From: or...@qu... [mailto:or...@qu...]
>> Sent: Monday, November 29, 2004 7:56 PM
>> To: Bishop, Barry
>> Cc: 'qui...@li...'
>> Subject: RE: [Quickfix-developers] Intermittent disconnect problem
>>
>>
>> Barry,
>>
>> For every disconnect that QuickFIX initiates, there should be a reason
>> provided (not with 1.4.0, but with the new releases).  With 1.9.4
>> (available now), QuickFIX also displays a "Dropped Connection" message
>> if the disconnect is initiated by the peer (1.9.2, does not
>> differentiate).  That should help you to verify if it is QuickFIX that
>> is initiating the disconnect.  I don't think there are any more cases
>> where QuickFIX initiates
>> a disconnect without providing a reason.  If the couterparty drops the
>> connection, then unless they provide information in the form of a reject
>> or
>> logoff text, there is little QuickFIX can do to determine the cause.  The
>> best that we can probably do is report whether the socket was dropped
>> gracefully, and therefore intentionally, or if it was an abnormal
>> disconnect
>> of some sort.
>>
>> Is there anything significantly different about this new client?  Does
>> their
>> logs reveal anything about the nature of the disconnect?
>>
>> --oren
>>
>>> 1) Anyone have any idea what's going on?
>>> 2) Is there a way to increase the amount of detail in log messages,
>>> especially those to do with disconnection events?
>>> 3) What sort of thing would cause quickfix to disconnect without
>>> saying why?
>>>
>>> Thanks in advance,
>>> barry
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real
>> users. Discover which products truly live up to the hype. Start
>> reading now. http://productguide.itmanagersjournal.com/
>> _______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive
>> Reporting Tool for open source databases. Create drag-&-drop reports.
>> Save time by over 75%! Publish reports on the web. Export to DOC, XLS,
>> RTF, etc. Download a FREE copy at
>> http://www.intelliview.com/go/osdn_nl
>> _______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>=20



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers



-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.

Re: [Quickfix-developers] RE: Intermittent disconnect problem

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

Well, not necessarilly.  "Dropped Connection" right now just means that the 
connection was droppen outside of a logout sequence.  If QuickFIX knows the 
reason for this, it will be preceeded in the log for the reason, such as 
"Timed out waiting for heartbeat."

The only time I can think of where QF would not know the exact reason for a 
disconnect is if the socket is either broken somehow, or closed by the 
counterparty.  You can see in the SocketInitiator and SocketAcceptor 
onDisconnect methods, that Session::disconnect is being called.  This is the 
only place where there is not an additional message that provides a 
disconnect reason.

What we can do is start logging the error codes of the socket calls to get a 
more detailed analysis on what is hapenning with the socket.  For instance, 
calling close can set the global error code to one of the following.

      EBADF  The s argument is not an active descriptor.
      ECONNABORTED  The connection was aborted by the remote endpoint.
      ECONNREFUSED  The remote endpoint refused to continue the connection.
      ECONNRESET  The remote endpoint reset the connection request.
      EDESTUNREACH  Remote destination is now unreachable.
      EHOSTUNREACH  Remote host is now unreachable.
      ENETDOWN  Local network interface is down.
      ETIMEDOUT  The connection timed out.


I think that would get you the information you need to figure out the source 
of the disconnect.

--oren

----- Original Message ----- 
From: "Bishop, Barry" <Bar...@gs...>
To: "'Oren Miller'" <or...@qu...>; 
<qui...@li...>
Cc: "'Caleb Epstein'" <cal...@gm...>; "'Perez, John'" 
<jp...@Cr...>
Sent: Tuesday, February 01, 2005 10:30 AM
Subject: RE: [Quickfix-developers] RE: Intermittent disconnect problem


> Hello Oren,
>
> I'm afraid there is no consistency as to when this happens. Sometimes it
> doesn't happen for a week, whereas it could be 8 times a week anywhere 
> from
> 7:00AM to 9:00 PM.
>
> The amount of traffic is very low, maybe 1 or 2 messages per second at 
> most.
>
> The outage doesn't last long and it's not a very big deal, but it would be
> nice to get it fixed.
>
> Can you confirm that if quickfix logs the message 'Dropped Connection' 
> then
> it was quickfix that disconnected? I believe this to be the case, but it
> seems that the code only tests to see if a logout has been sent.
>
> Should quickfix have logged another message if the above is true?
>
> In the meantime, I will take John Perez's advice and have a good look
> through the last received message just in case this is related. However, 
> the
> disconnect often occurs many seconds after the last message is sent or
> received.
>
> Thanks again,
> barry
>
>
>
> -----Original Message-----
> From: Oren Miller [mailto:or...@qu...]
> Sent: Tuesday, February 01, 2005 4:12 PM
> To: Bishop, Barry; qui...@li...
> Cc: 'Caleb Epstein'
> Subject: Re: [Quickfix-developers] RE: Intermittent disconnect problem
>
>
> Barry,
>
> Is there anything common about the times in which these disconnects occur?
> Is this a high frequency line?  Is it possible you are overloading the
> socket buffer?
>
> --oren
>
> ----- Original Message ----- 
> From: "Bishop, Barry" <Bar...@gs...>
> To: <qui...@li...>
> Cc: "Oren Miller" <or...@qu...>; "'Caleb Epstein'"
> <cal...@gm...>
> Sent: Tuesday, February 01, 2005 9:37 AM
> Subject: RE: [Quickfix-developers] RE: Intermittent disconnect problem
>
>
>> QuickFIX Documentation:
>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>> Hello all,
>>
>> This is a follow up on a problem that I was having last year:
>>
>> quickfix seemingly disconnects from its peer without indicating why.
>>
>> We've upgraded our system to quickfix 1.9.4 in the hope of getting
>> more useful messages, but we don't appear to. I've had a look through
>> the code and I can't see quite how this could happen. However it does.
>>
>> To reiterate, at some random time quickfix disconnects the TCP seesion
>> from
>> its peer and logs this message in the event log:
>>
>> 20050201-13:33:27 : Dropped Connection
>>
>> This message indicates that quickfix initiated the disconnect, but it
>> does not say why. The inbound and outbound messages all look fine and
>> usually there has been a few seconds since the last message was sent
>> anyway.
>>
>> What happens next is the usual reconnect, logon and resend request.
>> Everything continues after this. Incidentally, since upgrading from
>> quickfix 1.4.0 to 1.9.4 this reconnect/resync is a whole order of
>> magnitude better behaved.
>>
>> However, the mysterious disconnect still occurs.
>>
>> Has anyone else seen anything like this?
>> Can anyone give me any suggestions as to how to track down the
>> problem?
>>
>> We are running quickfix 1.9.4 on solaris 5.8
>> quickfix was built with GCC 3.2.2
>> We connect using SocketInitiator
>>
>> Thanks in advance,
>> barry
>>
>>
>>
>> Here are some excerpts from our logs:
>>
>> EVENT LOG
>> =========
>> 20050201-13:33:27 : Dropped Connection
>> 20050201-13:33:29 : Connecting to XXX.XXX.XXX.XXX on port YYYY
>> 20050201-13:33:29 : Connection succeeded 20050201-13:33:29 : Initiated
>> logon request 20050201-13:33:31 : Received logon response
>>
>>
>> INCOMING
>> ========
>> The last message before disconnecting
>> 8=FIX.4.2|9=0183|35=R|115=2126|34=8349|49=CCCCCC|56=BBBBBB|52=20050201
>> -13:32
>>
> :49|122=20050201-13:33:23|116=10101010101010101|144=ZZZZZZZ|131=200502017287
>> |146=1|55=BBBBBB|48=773670|22=108|38=100|10=146|
>>
>> The logon response
>> 8=FIX.4.2|9=0067|35=A|34=8351|49=CCCCCC|56=BBBBBB|52=20050201-13:32:54
>> |98=0|
>> 108=30|10=004|
>>
>>
>> OUTGOING
>> ========
>> The last message before disconnecting
>> 8=FIX.4.2|9=290|35=S|34=8232|49=BBBBBB|52=20050201-13:33:23.582|56=CCC
>> CCC|12
>>
> 8=2126|129=10101010101010101|145=ZZZZZZZ|22=108|48=773670|55=GSAMFFT|107=des
>> cription|117=id|131=txn|132=1|133=2|134=50000|
>>
>> The logon after the disconnect
>> 135=50000|167=OPT|200=200101|201=1|202=1.1|205=20|206=L|231=0.01|10=18
>> 1|
>>
> 8=FIX.4.2|9=71|35=A|34=8233|49=GSAMFFT|52=20050201-13:33:29.210|56=CATSOS|98
>> =0|108=30|10=098|
>>
>>
>> APPLICATION LOG
>> ===============
>> Tue Feb 1 13:33:23:528 GMT+00:00 2005|Received:
>> quickfix.fix42.QuoteRequest
>> Tue Feb 1 13:33:23:528 GMT+00:00 2005|toApp,
>> SessionID=FIX.4.2:BBBBBB->CCCCCC, Message=quickfix.fix42.Quote
>> Tue Feb 1 13:33:27:117 GMT+00:00 2005|onLogout,
>> SessionID=FIX.4.2:BBBBBB->CCCCCC
>>
>>
>>
>> -----Original Message-----
>> From: Bishop, Barry
>> Sent: Tuesday, November 30, 2004 08:11 AM
>> To: or...@qu... [mailto:or...@qu...]
>> Cc: 'qui...@li...'
>> Subject: RE: [Quickfix-developers] Intermittent disconnect problem
>>
>> Hello Oren,
>>
>> Thanks for the reply.
>>
>> Sounds to me like I should try version 1.9.2 or later in  our
>> production environment. I have been unable to reproduce the mysterious
>> disconnect in our QA system to the same client, but this is not
>> surprising as it is so infrequent. I have been simulating it by
>> breaking something else in the chain (which would appear as a client
>> disconnect) so this would explain the lack of an explanation from
>> qdhÔuickfix.
>>
>> I will try this over the next few days and report back.
>>
>> Thanks again,
>> barry
>>
>>
>> -----Original Message-----
>> From: or...@qu... [mailto:or...@qu...]
>> Sent: Monday, November 29, 2004 7:56 PM
>> To: Bishop, Barry
>> Cc: 'qui...@li...'
>> Subject: RE: [Quickfix-developers] Intermittent disconnect problem
>>
>>
>> Barry,
>>
>> For every disconnect that QuickFIX initiates, there should be a reason
>> provided (not with 1.4.0, but with the new releases).  With 1.9.4
>> (available now), QuickFIX also displays a "Dropped Connection" message
>> if the disconnect is initiated by the peer (1.9.2, does not
>> differentiate).  That should help you to verify if it is QuickFIX that
>> is initiating the disconnect.  I don't think there are any more cases
>> where QuickFIX initiates
>> a disconnect without providing a reason.  If the couterparty drops the
>> connection, then unless they provide information in the form of a reject
>> or
>> logoff text, there is little QuickFIX can do to determine the cause.  The
>> best that we can probably do is report whether the socket was dropped
>> gracefully, and therefore intentionally, or if it was an abnormal
>> disconnect
>> of some sort.
>>
>> Is there anything significantly different about this new client?  Does
>> their
>> logs reveal anything about the nature of the disconnect?
>>
>> --oren
>>
>>> 1) Anyone have any idea what's going on?
>>> 2) Is there a way to increase the amount of detail in log messages,
>>> especially those to do with disconnection events?
>>> 3) What sort of thing would cause quickfix to disconnect without
>>> saying why?
>>>
>>> Thanks in advance,
>>> barry
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real
>> users. Discover which products truly live up to the hype. Start
>> reading now. http://productguide.itmanagersjournal.com/
>> _______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive
>> Reporting Tool for open source databases. Create drag-&-drop reports.
>> Save time by over 75%! Publish reports on the web. Export to DOC, XLS,
>> RTF, etc. Download a FREE copy at
>> http://www.intelliview.com/go/osdn_nl
>> _______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
> 

RE: [Quickfix-developers] RE: Intermittent disconnect problem

[Bishop, B. <Bar...@gs...>]

Hello Oren,

I'm afraid there is no consistency as to when this happens. Sometimes it
doesn't happen for a week, whereas it could be 8 times a week anywhere from
7:00AM to 9:00 PM.

The amount of traffic is very low, maybe 1 or 2 messages per second at most.

The outage doesn't last long and it's not a very big deal, but it would be
nice to get it fixed.

Can you confirm that if quickfix logs the message 'Dropped Connection' then
it was quickfix that disconnected? I believe this to be the case, but it
seems that the code only tests to see if a logout has been sent.

Should quickfix have logged another message if the above is true?

In the meantime, I will take John Perez's advice and have a good look
through the last received message just in case this is related. However, the
disconnect often occurs many seconds after the last message is sent or
received.

Thanks again,
barry



-----Original Message-----
From: Oren Miller [mailto:or...@qu...] 
Sent: Tuesday, February 01, 2005 4:12 PM
To: Bishop, Barry; qui...@li...
Cc: 'Caleb Epstein'
Subject: Re: [Quickfix-developers] RE: Intermittent disconnect problem


Barry,

Is there anything common about the times in which these disconnects occur? 
Is this a high frequency line?  Is it possible you are overloading the 
socket buffer?

--oren

----- Original Message ----- 
From: "Bishop, Barry" <Bar...@gs...>
To: <qui...@li...>
Cc: "Oren Miller" <or...@qu...>; "'Caleb Epstein'" 
<cal...@gm...>
Sent: Tuesday, February 01, 2005 9:37 AM
Subject: RE: [Quickfix-developers] RE: Intermittent disconnect problem


> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hello all,
>
> This is a follow up on a problem that I was having last year:
>
> quickfix seemingly disconnects from its peer without indicating why.
>
> We've upgraded our system to quickfix 1.9.4 in the hope of getting 
> more useful messages, but we don't appear to. I've had a look through 
> the code and I can't see quite how this could happen. However it does.
>
> To reiterate, at some random time quickfix disconnects the TCP seesion
> from
> its peer and logs this message in the event log:
>
> 20050201-13:33:27 : Dropped Connection
>
> This message indicates that quickfix initiated the disconnect, but it 
> does not say why. The inbound and outbound messages all look fine and 
> usually there has been a few seconds since the last message was sent 
> anyway.
>
> What happens next is the usual reconnect, logon and resend request. 
> Everything continues after this. Incidentally, since upgrading from 
> quickfix 1.4.0 to 1.9.4 this reconnect/resync is a whole order of 
> magnitude better behaved.
>
> However, the mysterious disconnect still occurs.
>
> Has anyone else seen anything like this?
> Can anyone give me any suggestions as to how to track down the 
> problem?
>
> We are running quickfix 1.9.4 on solaris 5.8
> quickfix was built with GCC 3.2.2
> We connect using SocketInitiator
>
> Thanks in advance,
> barry
>
>
>
> Here are some excerpts from our logs:
>
> EVENT LOG
> =========
> 20050201-13:33:27 : Dropped Connection
> 20050201-13:33:29 : Connecting to XXX.XXX.XXX.XXX on port YYYY 
> 20050201-13:33:29 : Connection succeeded 20050201-13:33:29 : Initiated 
> logon request 20050201-13:33:31 : Received logon response
>
>
> INCOMING
> ========
> The last message before disconnecting 
> 8=FIX.4.2|9=0183|35=R|115=2126|34=8349|49=CCCCCC|56=BBBBBB|52=20050201
> -13:32
>
:49|122=20050201-13:33:23|116=10101010101010101|144=ZZZZZZZ|131=200502017287
> |146=1|55=BBBBBB|48=773670|22=108|38=100|10=146|
>
> The logon response 
> 8=FIX.4.2|9=0067|35=A|34=8351|49=CCCCCC|56=BBBBBB|52=20050201-13:32:54
> |98=0|
> 108=30|10=004|
>
>
> OUTGOING
> ========
> The last message before disconnecting 
> 8=FIX.4.2|9=290|35=S|34=8232|49=BBBBBB|52=20050201-13:33:23.582|56=CCC
> CCC|12
>
8=2126|129=10101010101010101|145=ZZZZZZZ|22=108|48=773670|55=GSAMFFT|107=des
> cription|117=id|131=txn|132=1|133=2|134=50000|
>
> The logon after the disconnect 
> 135=50000|167=OPT|200=200101|201=1|202=1.1|205=20|206=L|231=0.01|10=18
> 1|
>
8=FIX.4.2|9=71|35=A|34=8233|49=GSAMFFT|52=20050201-13:33:29.210|56=CATSOS|98
> =0|108=30|10=098|
>
>
> APPLICATION LOG
> ===============
> Tue Feb 1 13:33:23:528 GMT+00:00 2005|Received:
> quickfix.fix42.QuoteRequest
> Tue Feb 1 13:33:23:528 GMT+00:00 2005|toApp,
> SessionID=FIX.4.2:BBBBBB->CCCCCC, Message=quickfix.fix42.Quote
> Tue Feb 1 13:33:27:117 GMT+00:00 2005|onLogout,
> SessionID=FIX.4.2:BBBBBB->CCCCCC
>
>
>
> -----Original Message-----
> From: Bishop, Barry
> Sent: Tuesday, November 30, 2004 08:11 AM
> To: or...@qu... [mailto:or...@qu...]
> Cc: 'qui...@li...'
> Subject: RE: [Quickfix-developers] Intermittent disconnect problem
>
> Hello Oren,
>
> Thanks for the reply.
>
> Sounds to me like I should try version 1.9.2 or later in  our 
> production environment. I have been unable to reproduce the mysterious 
> disconnect in our QA system to the same client, but this is not 
> surprising as it is so infrequent. I have been simulating it by 
> breaking something else in the chain (which would appear as a client 
> disconnect) so this would explain the lack of an explanation from 
> qdhÔuickfix.
>
> I will try this over the next few days and report back.
>
> Thanks again,
> barry
>
>
> -----Original Message-----
> From: or...@qu... [mailto:or...@qu...]
> Sent: Monday, November 29, 2004 7:56 PM
> To: Bishop, Barry
> Cc: 'qui...@li...'
> Subject: RE: [Quickfix-developers] Intermittent disconnect problem
>
>
> Barry,
>
> For every disconnect that QuickFIX initiates, there should be a reason 
> provided (not with 1.4.0, but with the new releases).  With 1.9.4 
> (available now), QuickFIX also displays a "Dropped Connection" message 
> if the disconnect is initiated by the peer (1.9.2, does not 
> differentiate).  That should help you to verify if it is QuickFIX that 
> is initiating the disconnect.  I don't think there are any more cases 
> where QuickFIX initiates
> a disconnect without providing a reason.  If the couterparty drops the
> connection, then unless they provide information in the form of a reject 
> or
> logoff text, there is little QuickFIX can do to determine the cause.  The
> best that we can probably do is report whether the socket was dropped
> gracefully, and therefore intentionally, or if it was an abnormal 
> disconnect
> of some sort.
>
> Is there anything significantly different about this new client?  Does
> their
> logs reveal anything about the nature of the disconnect?
>
> --oren
>
>> 1) Anyone have any idea what's going on?
>> 2) Is there a way to increase the amount of detail in log messages, 
>> especially those to do with disconnection events?
>> 3) What sort of thing would cause quickfix to disconnect without 
>> saying why?
>>
>> Thanks in advance,
>> barry
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users. Discover which products truly live up to the hype. Start 
> reading now. http://productguide.itmanagersjournal.com/
> _______________________________________________
> Quickfix-developers mailing list 
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive 
> Reporting Tool for open source databases. Create drag-&-drop reports. 
> Save time by over 75%! Publish reports on the web. Export to DOC, XLS, 
> RTF, etc. Download a FREE copy at 
> http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> 

Re: [Quickfix-developers] RE: Intermittent disconnect problem

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

Barry,

Is there anything common about the times in which these disconnects occur? 
Is this a high frequency line?  Is it possible you are overloading the 
socket buffer?

--oren

----- Original Message ----- 
From: "Bishop, Barry" <Bar...@gs...>
To: <qui...@li...>
Cc: "Oren Miller" <or...@qu...>; "'Caleb Epstein'" 
<cal...@gm...>
Sent: Tuesday, February 01, 2005 9:37 AM
Subject: RE: [Quickfix-developers] RE: Intermittent disconnect problem


> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hello all,
>
> This is a follow up on a problem that I was having last year:
>
> quickfix seemingly disconnects from its peer without indicating why.
>
> We've upgraded our system to quickfix 1.9.4 in the hope of getting more
> useful messages, but we don't appear to. I've had a look through the code
> and I can't see quite how this could happen. However it does.
>
> To reiterate, at some random time quickfix disconnects the TCP seesion 
> from
> its peer and logs this message in the event log:
>
> 20050201-13:33:27 : Dropped Connection
>
> This message indicates that quickfix initiated the disconnect, but it does
> not say why. The inbound and outbound messages all look fine and usually
> there has been a few seconds since the last message was sent anyway.
>
> What happens next is the usual reconnect, logon and resend request.
> Everything continues after this. Incidentally, since upgrading from 
> quickfix
> 1.4.0 to 1.9.4 this reconnect/resync is a whole order of magnitude better
> behaved.
>
> However, the mysterious disconnect still occurs.
>
> Has anyone else seen anything like this?
> Can anyone give me any suggestions as to how to track down the problem?
>
> We are running quickfix 1.9.4 on solaris 5.8
> quickfix was built with GCC 3.2.2
> We connect using SocketInitiator
>
> Thanks in advance,
> barry
>
>
>
> Here are some excerpts from our logs:
>
> EVENT LOG
> =========
> 20050201-13:33:27 : Dropped Connection
> 20050201-13:33:29 : Connecting to XXX.XXX.XXX.XXX on port YYYY
> 20050201-13:33:29 : Connection succeeded
> 20050201-13:33:29 : Initiated logon request
> 20050201-13:33:31 : Received logon response
>
>
> INCOMING
> ========
> The last message before disconnecting
> 8=FIX.4.2|9=0183|35=R|115=2126|34=8349|49=CCCCCC|56=BBBBBB|52=20050201-13:32
> :49|122=20050201-13:33:23|116=10101010101010101|144=ZZZZZZZ|131=200502017287
> |146=1|55=BBBBBB|48=773670|22=108|38=100|10=146|
>
> The logon response
> 8=FIX.4.2|9=0067|35=A|34=8351|49=CCCCCC|56=BBBBBB|52=20050201-13:32:54|98=0|
> 108=30|10=004|
>
>
> OUTGOING
> ========
> The last message before disconnecting
> 8=FIX.4.2|9=290|35=S|34=8232|49=BBBBBB|52=20050201-13:33:23.582|56=CCCCCC|12
> 8=2126|129=10101010101010101|145=ZZZZZZZ|22=108|48=773670|55=GSAMFFT|107=des
> cription|117=id|131=txn|132=1|133=2|134=50000|
>
> The logon after the disconnect
> 135=50000|167=OPT|200=200101|201=1|202=1.1|205=20|206=L|231=0.01|10=181|
> 8=FIX.4.2|9=71|35=A|34=8233|49=GSAMFFT|52=20050201-13:33:29.210|56=CATSOS|98
> =0|108=30|10=098|
>
>
> APPLICATION LOG
> ===============
> Tue Feb 1 13:33:23:528 GMT+00:00 2005|Received: 
> quickfix.fix42.QuoteRequest
> Tue Feb 1 13:33:23:528 GMT+00:00 2005|toApp,
> SessionID=FIX.4.2:BBBBBB->CCCCCC, Message=quickfix.fix42.Quote
> Tue Feb 1 13:33:27:117 GMT+00:00 2005|onLogout,
> SessionID=FIX.4.2:BBBBBB->CCCCCC
>
>
>
> -----Original Message-----
> From: Bishop, Barry
> Sent: Tuesday, November 30, 2004 08:11 AM
> To: or...@qu... [mailto:or...@qu...]
> Cc: 'qui...@li...'
> Subject: RE: [Quickfix-developers] Intermittent disconnect problem
>
> Hello Oren,
>
> Thanks for the reply.
>
> Sounds to me like I should try version 1.9.2 or later in  our production
> environment. I have been unable to reproduce the mysterious disconnect in
> our QA system to the same client, but this is not surprising as it is so
> infrequent. I have been simulating it by breaking something else in the
> chain (which would appear as a client disconnect) so this would explain 
> the
> lack of an explanation from qdhÔuickfix.
>
> I will try this over the next few days and report back.
>
> Thanks again,
> barry
>
>
> -----Original Message-----
> From: or...@qu... [mailto:or...@qu...]
> Sent: Monday, November 29, 2004 7:56 PM
> To: Bishop, Barry
> Cc: 'qui...@li...'
> Subject: RE: [Quickfix-developers] Intermittent disconnect problem
>
>
> Barry,
>
> For every disconnect that QuickFIX initiates, there should be a reason
> provided (not with 1.4.0, but with the new releases).  With 1.9.4 
> (available
> now), QuickFIX also displays a "Dropped Connection" message if the
> disconnect is initiated by the peer (1.9.2, does not differentiate).  That
> should help you to verify if it is QuickFIX that is initiating the
> disconnect.  I don't think there are any more cases where QuickFIX 
> initiates
> a disconnect without providing a reason.  If the couterparty drops the
> connection, then unless they provide information in the form of a reject 
> or
> logoff text, there is little QuickFIX can do to determine the cause.  The
> best that we can probably do is report whether the socket was dropped
> gracefully, and therefore intentionally, or if it was an abnormal 
> disconnect
> of some sort.
>
> Is there anything significantly different about this new client?  Does 
> their
> logs reveal anything about the nature of the disconnect?
>
> --oren
>
>> 1) Anyone have any idea what's going on?
>> 2) Is there a way to increase the amount of detail in log messages,
>> especially those to do with disconnection events?
>> 3) What sort of thing would cause quickfix to disconnect without
>> saying why?
>>
>> Thanks in advance,
>> barry
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Quickfix-developers mailing list Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> 

RE: [Quickfix-developers] RE: Intermittent disconnect problem

[Bishop, B. <Bar...@gs...>]

Hello all,

This is a follow up on a problem that I was having last year:

quickfix seemingly disconnects from its peer without indicating why.

We've upgraded our system to quickfix 1.9.4 in the hope of getting more
useful messages, but we don't appear to. I've had a look through the code
and I can't see quite how this could happen. However it does.

To reiterate, at some random time quickfix disconnects the TCP seesion from
its peer and logs this message in the event log:

20050201-13:33:27 : Dropped Connection

This message indicates that quickfix initiated the disconnect, but it does
not say why. The inbound and outbound messages all look fine and usually
there has been a few seconds since the last message was sent anyway.

What happens next is the usual reconnect, logon and resend request.
Everything continues after this. Incidentally, since upgrading from quickfix
1.4.0 to 1.9.4 this reconnect/resync is a whole order of magnitude better
behaved.

However, the mysterious disconnect still occurs.

Has anyone else seen anything like this?
Can anyone give me any suggestions as to how to track down the problem?

We are running quickfix 1.9.4 on solaris 5.8
quickfix was built with GCC 3.2.2
We connect using SocketInitiator

Thanks in advance,
barry



Here are some excerpts from our logs:

EVENT LOG
=========
20050201-13:33:27 : Dropped Connection
20050201-13:33:29 : Connecting to XXX.XXX.XXX.XXX on port YYYY
20050201-13:33:29 : Connection succeeded
20050201-13:33:29 : Initiated logon request
20050201-13:33:31 : Received logon response


INCOMING
========
The last message before disconnecting
8=FIX.4.2|9=0183|35=R|115=2126|34=8349|49=CCCCCC|56=BBBBBB|52=20050201-13:32
:49|122=20050201-13:33:23|116=10101010101010101|144=ZZZZZZZ|131=200502017287
|146=1|55=BBBBBB|48=773670|22=108|38=100|10=146|

The logon response
8=FIX.4.2|9=0067|35=A|34=8351|49=CCCCCC|56=BBBBBB|52=20050201-13:32:54|98=0|
108=30|10=004|


OUTGOING
========
The last message before disconnecting
8=FIX.4.2|9=290|35=S|34=8232|49=BBBBBB|52=20050201-13:33:23.582|56=CCCCCC|12
8=2126|129=10101010101010101|145=ZZZZZZZ|22=108|48=773670|55=GSAMFFT|107=des
cription|117=id|131=txn|132=1|133=2|134=50000|

The logon after the disconnect
135=50000|167=OPT|200=200101|201=1|202=1.1|205=20|206=L|231=0.01|10=181|
8=FIX.4.2|9=71|35=A|34=8233|49=GSAMFFT|52=20050201-13:33:29.210|56=CATSOS|98
=0|108=30|10=098|


APPLICATION LOG
===============
Tue Feb 1 13:33:23:528 GMT+00:00 2005|Received: quickfix.fix42.QuoteRequest
Tue Feb 1 13:33:23:528 GMT+00:00 2005|toApp,
SessionID=FIX.4.2:BBBBBB->CCCCCC, Message=quickfix.fix42.Quote
Tue Feb 1 13:33:27:117 GMT+00:00 2005|onLogout,
SessionID=FIX.4.2:BBBBBB->CCCCCC



-----Original Message-----
From: Bishop, Barry
Sent: Tuesday, November 30, 2004 08:11 AM
To: or...@qu... [mailto:or...@qu...] 
Cc: 'qui...@li...'
Subject: RE: [Quickfix-developers] Intermittent disconnect problem

Hello Oren,

Thanks for the reply.

Sounds to me like I should try version 1.9.2 or later in  our production
environment. I have been unable to reproduce the mysterious disconnect in
our QA system to the same client, but this is not surprising as it is so
infrequent. I have been simulating it by breaking something else in the
chain (which would appear as a client disconnect) so this would explain the
lack of an explanation from quickfix.

I will try this over the next few days and report back.

Thanks again,
barry


-----Original Message-----
From: or...@qu... [mailto:or...@qu...] 
Sent: Monday, November 29, 2004 7:56 PM
To: Bishop, Barry
Cc: 'qui...@li...'
Subject: RE: [Quickfix-developers] Intermittent disconnect problem


Barry,

For every disconnect that QuickFIX initiates, there should be a reason
provided (not with 1.4.0, but with the new releases).  With 1.9.4 (available
now), QuickFIX also displays a "Dropped Connection" message if the
disconnect is initiated by the peer (1.9.2, does not differentiate).  That
should help you to verify if it is QuickFIX that is initiating the
disconnect.  I don't think there are any more cases where QuickFIX initiates
a disconnect without providing a reason.  If the couterparty drops the
connection, then unless they provide information in the form of a reject or
logoff text, there is little QuickFIX can do to determine the cause.  The
best that we can probably do is report whether the socket was dropped
gracefully, and therefore intentionally, or if it was an abnormal disconnect
of some sort.

Is there anything significantly different about this new client?  Does their
logs reveal anything about the nature of the disconnect?

--oren

> 1) Anyone have any idea what's going on?
> 2) Is there a way to increase the amount of detail in log messages, 
> especially those to do with disconnection events?
> 3) What sort of thing would cause quickfix to disconnect without
> saying why?
> 
> Thanks in advance,
> barry



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
_______________________________________________
Quickfix-developers mailing list Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

[Quickfix-developers] CMS / FIX conversions

[Jody H. <jod...@at...>]

Anyone using QF for CMS/FIX conversions?