RE: [Quickfix-developers] Bug in Session::sendRaw.

[Miller, O. <OM...@ri...>]

Looks like pretty much this exact question was just addressed in the =
forum =
(http://www.fixprotocol.org/cgi-bin/BBS.cgi?menu=3D710&board=3D1&message=3D=
3110&thread=3D3109).

Essentially either disconnecting or sending a logout is valid, however =
disconnecting is considered more stable, while logging out is clearly =
more informative.  It seems to me that the configuration file should =
give a session the choice how it wants to handle these situations.

Currently disconnects are handled when an std::exception is thrown in =
the Session, which results in a call to disconnect.  If we start putting =
text into these exceptions, we can have the session use it to label the =
logout reason and send it if the session is setup for this behavior.

-----Original Message-----
From:	Timothy Yates [mailto:ty...@pa...]
Sent:	Thu 2/26/2004 10:53 AM
To:	'qui...@li...'
Cc:	William Todd; Lenny Shleymovich
Subject:	[Quickfix-developers] Bug in Session::sendRaw.

There is an bug in Session::sendRaw, which may cause a sequence number =
to be
consumed without any message actually being sent.

For example, session-level reject messages are not sent if the session =
is
not logged in.  In such cases, an empty message (empty string) is =
committed
to the message store and the outbound sequence number is incremented.  =
This
causes the session to be irretrievably broken.  If the client asks for =
the
missing message, an exception is thrown on attempting to parse the empty
message from the message store.  In the current quickfix release, this =
will
cause the client's resend request to be ignored.

The attached acceptance test definition illustrates this problem by =
sending
a logon message with a bad sending time.  This seems like a slightly
artificial test case.  However, we have seen a large number of instances =
of
this problem which were caused by something other than bad sending time. =
 We
are still trying to ascertain exactly which outbound messages were being
suppressed.

I am not certain what the correct behaviour should be for this test =
case.
Should the reject still be sent, or should it be suppressed?  I think it
should be suppressed because the normal way to reject a logon is either =
with
a logout or a disconnect.   Ideally, the logout text should include the
reason for the problem (i.e. sending time inaccuracy), otherwise it =
could be
very difficult for the client to ascertain.

 <<5000_STA.def>>=20
Tim Yates
Lead Developer=20
Patsystems (US) LLC=20
141 West Jackson Boulevard
Chicago 60604, USA=20
Tel +1 (312) 542-1336=20
www.patsystems.com=20


DISCLAIMER: This e-mail is confidential and may also be legally =
privileged.
If you are not the intended recipient, use of the information contained =
in
this e-mail (including disclosure, copying or distribution) is =
prohibited
and may be unlawful.  Please inform the sender and delete the message
immediately from your system.  This e-mail is attributed to the sender =
and
may not necessarily reflect the views of the Patsystems Group and no =
member
of the Patsystems Group accepts any liability for any action taken in
reliance on the contents of this e-mail (other than where it has a legal =
or
regulatory obligation to do so) or for the consequences of any computer
viruses which may have been transmitted by this e-mail. The Patsystems =
Group
comprises Patsystems plc and its subsidiary group of companies.