[Quickfix-developers] Re: Infinite loop when receiving bad message in threaded acceptor

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

I ended up writing the catch block as follows:

if( length )
    m_buffer.erase( 0, pos + length )
else
  m_buffer.erase();

I added a unit test to verify that passing the example string you =
supplied throws an exception the first time, then returns false on the =
second pass.  The reason I do the check for length is that it could save =
some resend requests in case there are other messages in the buffer that =
might be cleared.  Could be a significant factor in a high frequency =
system if the buffer builds up. Please let me know if your tests =
indicate that this code satisfies the error case you reported.

--oren
  ----- Original Message -----=20
  From: Yihu Fang=20
  To: Oren Miller ; qui...@li...=20
  Sent: Tuesday, February 22, 2005 7:01 PM
  Subject: RE: Infinite loop when receiving bad message in threaded =
acceptor


  Oren,

  =20

  Yes, after the fix to empty m_buffer correctly, QF can continue to =
read the next message without disconnect the session.

  =20

  The only annoying thing is that =
ThreadedSocketConnection::readMessage() gets an empty string so the log =
could not record the garbled incoming message. It would record an event =
error "BodyLength or CheckSum missing" because of the empty string. This =
could be misleading.

  =20

  Thanks,

  =20

  -Yihu

  =20


-------------------------------------------------------------------------=
-----

  From: Oren Miller [mailto:or...@qu...]=20
  Sent: Tuesday, February 22, 2005 5:54 PM
  To: Yihu Fang; qui...@li...
  Subject: Re: Infinite loop when receiving bad message in threaded =
acceptor

  =20

  Garbled messages should be ignored, so it shouldn't cause a =
termination of the session. If it goes on to continue reading the =
buffer, then that is the correct behavior according to the FPL test =
cases.

  =20

  --oren

    ----- Original Message -----=20

    From: Yihu Fang=20

    To: Yihu Fang ; Oren Miller ; =
qui...@li...=20

    Sent: Tuesday, February 22, 2005 2:45 PM

    Subject: RE: Infinite loop when receiving bad message in threaded =
acceptor

    =20

    Hi,

    =20

    To stop the infinite loop, in catch(MessageParseError &e) of =
Parser::readFixMessage(), the m_buffer should be emptied. Because pos =
and length are zero, the bad message in m_buffer is reused which causes =
the infinite loop.

    =20

    QuickFIX 1.9.4

    117,118c117

    <     // m_buffer.erase( 0, pos + length );

    <         m_buffer.erase();

    ---

    >     m_buffer.erase( 0, pos + length );

    =20

    Whether QF is going to decide to terminate the session or not should =
be done in the ThreadedSocketConnection.

    =20

    Thanks,

    =20

    -Yihu

    =20


-------------------------------------------------------------------------=
---

    From: Yihu Fang=20
    Sent: Tuesday, February 22, 2005 2:09 PM
    To: 'Oren Miller'; qui...@li...
    Subject: Infinite loop when receiving bad message in threaded =
acceptor

    =20

    Oren,

    =20

    When a threaded acceptor receives a garbled message, e.g. invalid =
length field, during an established FIX session, the QuickFIX engine =
runs into an infinite loop.

    =20

    An example garbles message is like this, =
8=3DTEST9=3DTEST35=3DTEST49=3DSS156=3DRORE34=3D352=3D20050222-16:45:5310=3D=
TEST

    =20

    Parser::extractLength() throws a MessageParserError exception =
because of field 9=3DTEST.

    =20

    ThreadSocketConnection::readMessage() catches the exception but it =
does nothing and returns true.

    =20

    This causes an infinite loop in the =
ThreadedSocketConnection::readQueue(). An empty string is passed to =
Session::next(), an InvalidMessage exception is thrown. However, because =
the session is in a logon on state, the session is not disconnected, but =
keeps going.

    =20

    The session should be disconnected in the exception catch of either =
MessageParserError or InvalidMessage.

    =20

    Thank you,

    =20

    -Yihu



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