RE: [Quickfix-developers] PossDup flag on logon

[Jo J. <jo...@tr...>]

It seems this problem only occurred because in my testing today, my
sequence numbers got messed up.
So, it probably is not new to version 1.7.
 
The only real changes I made to the code are:
1)       Put a try-catch block around the header.getField( possDupFlag
); line in session.cpp in the doTargetTooLow() function. This way the
getField() call will not prevent the appropriate message to be logged.
2)       Log messages for the reason for disconnection in various
places.
 
Now, if the same problem occurs again, the log file will indicate what
happened. Here is my altered doTargetTooLow(), let me know if this is
incorrect somehow:
 
bool Session::doTargetTooLow( const Message& msg )
{ QF_STACK_PUSH(Session::doTargetTooLow)
 
  const Header & header = msg.getHeader();
  MsgType msgType;
  PossDupFlag possDupFlag;
  MsgSeqNum msgSeqNum;
  header.getField( msgType );
  try {
      header.getField( possDupFlag );
  } catch(FieldNotFound&) {
        possDupFlag.setValue(false);
  }
  header.getField( msgSeqNum );
 
  m_state.onEvent( "MsgSeqNum too low RECEIVED: "
                   + IntConvertor::convert( msgSeqNum )
                   +" EXPECTED: "
                   + IntConvertor::convert( getExpectedTargetNum() )
                   + " PosDup: " + BoolConvertor::convert( possDupFlag )
);
 
  if ( !possDupFlag )
    throw std::exception();
  return doPossDup( msg );
 
  QF_STACK_POP
}
 
-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of
Miller, Oren
Sent: Thursday, April 01, 2004 11:10
To: Jo Janssens; qui...@li...
Subject: RE: [Quickfix-developers] PossDup flag on logon
 
Ok well I looked at it and this code doesn't seem to have changed
between these versions versions.  
 
The behavior is correct.  If a sequence number is too low and PossDup is
not Y, the counterparty should be disconnected, no matter the message.
If this is common then we can add a configuration setting that ignores
this for logons.  Are you sure you didn't patch 1.6.0 and forgot?  In
any case I agree that better logging should be enabled for these
situations, we'll work on improving that.  I'm sure that previous
versions weren't helpful with checkLatency because we have had a lot of
complaints about it :-), it's event mentioned in the FAQ.  
 
Any idea why the brokers are logging in with sequence numbers that are
too low?  Do the following messages have correct sequence numbers?  It
sounds like very strange behavior to me.  Are you able to identify who
they are so others may be aware of it?  Thanks.
 
--oren
 
-----Original Message-----
From: Jo Janssens [mailto:jo...@tr...] 
Sent: Thursday, April 01, 2004 10:26 AM
To: qui...@li...
Subject: RE: [Quickfix-developers] PossDup flag on logon
 
I should mention: this only happens when the logon response I receive
has a low sequence number. If this happens, the doTargetTooLow()
function tries to get the PossDup flag and throws an exception, causing
a disconnect w/o and informative messages in the log. This was quite
frustrating initially, I had to modify the quickfix code to figure it
out.
 
I also noticed that a bad time causes a disconnect if checkLatency is
on, and no message is printed to the log in that case either.
 
It seems that the previous version sent rejects to indicate what went
wrong, but now it simply disconnects and that makes it tough to figure
out what went wrong.
 
 
-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of Jo
Janssens
Sent: Thursday, April 01, 2004 10:12
To: qui...@li...
Subject: [Quickfix-developers] PossDup flag on logon
 
I just rebuilt my stuff with quickfix 1.7.0 (C++).
 
A couple of my brokers do not send the PossDup field (43) on logon, and
this causes quickfix to disconnect them.
 
I am using FIX 4.2 and I do not believe it requires tag 43 on a logon,
so is this a new bug?
 
Thanks,
Jo Janssens
 
 
  _____  

This email and any attachments are confidential and may be legally
privileged. No confidentiality or privilege is waived or lost by any
transmission in error. If you are not the intended recipient you are
hereby notified that any use, printing, copying or disclosure is
strictly prohibited. Please delete this email and any attachments,
without printing, copying, forwarding or saving them and notify the
sender immediately by reply e-mail. The company reserves the right to
monitor all e-mail communications through its networks. Unless otherwise
stated, any financial results or price data contained in this email are
indicative only and are subject to change without notice.