quickfix-developers

RE: [Quickfix-developers] PossDup flag on logon

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

Ok well I looked at it and this code doesn't seem to have changed=0D=0Abetw=
een these versions versions=2E  =0D=0A =0D=0AThe behavior is correct=2E  If=
 a sequence number is too low and PossDup is=0D=0Anot Y, the counterparty s=
hould be disconnected, no matter the message=2E=0D=0AIf this is common then=
 we can add a configuration setting that ignores=0D=0Athis for logons=2E  A=
re you sure you didn't patch 1=2E6=2E0 and forgot?  In=0D=0Aany case I agre=
e that better logging should be enabled for these=0D=0Asituations, we'll wo=
rk on improving that=2E  I'm sure that previous=0D=0Aversions weren't helpf=
ul with checkLatency because we have had a lot of=0D=0Acomplaints about it =
:-), it's event mentioned in the FAQ=2E  =0D=0A =0D=0AAny idea why the brok=
ers are logging in with sequence numbers that are=0D=0Atoo low?  Do the fol=
lowing messages have correct sequence numbers?  It=0D=0Asounds like very st=
range behavior to me=2E  Are you able to identify who=0D=0Athey are so othe=
rs may be aware of it?  Thanks=2E=0D=0A =0D=0A--oren=0D=0A =0D=0A-----Origi=
nal Message-----=0D=0AFrom: Jo Janssens [mailto:jo@tridecap=2Ecom] =0D=0ASe=
nt: Thursday, April 01, 2004 10:26 AM=0D=0ATo: quickfix-developers@lists=2E=
sourceforge=2Enet=0D=0ASubject: RE: [Quickfix-developers] PossDup flag on l=
ogon=0D=0A =0D=0AI should mention: this only happens when the logon respons=
e I receive=0D=0Ahas a low sequence number=2E If this happens, the doTarget=
TooLow()=0D=0Afunction tries to get the PossDup flag and throws an exceptio=
n, causing=0D=0Aa disconnect w/o and informative messages in the log=2E Thi=
s was quite=0D=0Afrustrating initially, I had to modify the quickfix code t=
o figure it=0D=0Aout=2E=0D=0A =0D=0AI also noticed that a bad time causes a=
 disconnect if checkLatency is=0D=0Aon, and no message is printed to the lo=
g in that case either=2E=0D=0A =0D=0AIt seems that the previous version sen=
t rejects to indicate what went=0D=0Awrong, but now it simply disconnects a=
nd that makes it tough to figure=0D=0Aout what went wrong=2E=0D=0A =0D=0A =
=0D=0A-----Original Message-----=0D=0AFrom: quickfix-developers-admin@lists=
=2Esourceforge=2Enet=0D=0A[mailto:quickfix-developers-admin@lists=2Esourcef=
orge=2Enet] On Behalf Of Jo=0D=0AJanssens=0D=0ASent: Thursday, April 01, 20=
04 10:12=0D=0ATo: quickfix-developers@lists=2Esourceforge=2Enet=0D=0ASubjec=
t: [Quickfix-developers] PossDup flag on logon=0D=0A =0D=0AI just rebuilt m=
y stuff with quickfix 1=2E7=2E0 (C++)=2E=0D=0A =0D=0AA couple of my brokers=
 do not send the PossDup field (43) on logon, and=0D=0Athis causes quickfix=
 to disconnect them=2E=0D=0A =0D=0AI am using FIX 4=2E2 and I do not believ=
e it requires tag 43 on a logon,=0D=0Aso is this a new bug?=0D=0A =0D=0ATha=
nks,=0D=0AJo Janssens=0D=0A =0D=0A =0D=0A=0D=0A=0D=0A=0D=0A----------------=
-------------------------=0D=0AThis email and any attachments are confident=
ial and may be legally privileged=2E  No confidentiality or privilege is wa=
ived or lost by any transmission in error=2E  If you are not the intended r=
ecipient you are hereby notified that any use, printing, copying or disclos=
ure is strictly prohibited=2E  Please delete this email and any attachments=
, without printing, copying, forwarding or saving them and notify the sende=
r immediately by reply e-mail=2E  The company reserves the right to monitor=
 all e-mail communications through its networks=2E  Unless otherwise stated=
, any financial results or price data contained in this email are indicativ=
e only and are subject to change without notice=2E=0D=0A

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.