quickfix-developers

[Quickfix-developers] Infinite resend loop

[Kovalenko, M. <mic...@cs...>]

Hi Oren,

You wrote:

>...
> Date: Fri, 16 Apr 2004 09:38:37 -0500
> To: "Angela Metallo" <A.M...@it...>
> ...
> Yeah, if a message fails basic validation, you will get infinite resend =20=
> requests.  There isn't much that you can do about this. If a message =20
> fails validation, the protocol says that the message must be ignored.  =20=
> Meaning to treat it like it never happened.  So of course sequence =20
> numbers do not get incremented.  FIX is designed to process all =20
> messages in the correct order.  Passing over a message and going to the =20=
> next one would violate this.
> Rejects really should only occur during testing.  If you ever see a =20
> session level reject during production, you should re-certify with your =20=
> counter-party.  It basically means your connection is broken and needs =20=
> to be addressed.
> ...

Here's what the standard says:
http://www.fixprotocol.org/specification/fix40.doc
page 15:
	Reject -
	The reject message should be issued when a message is received which cannot
be passed 	through to the application level.  
	...
	Rejected messages should be logged and the incoming sequence number
incremented.
	...

I've seen this scenario in certified system: the client Order Entry GUI may
allow limits in excess of those configured in the session layer. Should that
happen, QuickFix would go in the reject/resend-request loop and will never
recover automatically.

Bumping up the sequence number after a session level reject would make
QuickFix a lot more user-friendly.

Sincerely,

Michael Kovalenko

==============================================================================
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==============================================================================

Re: [SPAM] [Quickfix-developers] Infinite resend loop

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

Ok.  This answers my question.  Looks like it's pretty clear what has  
to be done.  Thanks.

--oren

On Apr 19, 2004, at 10:18 AM, Kovalenko, Michael wrote:

> Hi Oren,
>
> You wrote:
>
>> ...
>> Date: Fri, 16 Apr 2004 09:38:37 -0500
>> To: "Angela Metallo" <A.M...@it...>
>> ...
>> Yeah, if a message fails basic validation, you will get infinite  
>> resend =20=
>> requests.  There isn't much that you can do about this. If a message  
>> =20
>> fails validation, the protocol says that the message must be ignored.  
>>  =20=
>> Meaning to treat it like it never happened.  So of course sequence =20
>> numbers do not get incremented.  FIX is designed to process all =20
>> messages in the correct order.  Passing over a message and going to  
>> the =20=
>> next one would violate this.
>> Rejects really should only occur during testing.  If you ever see a  
>> =20
>> session level reject during production, you should re-certify with  
>> your =20=
>> counter-party.  It basically means your connection is broken and  
>> needs =20=
>> to be addressed.
>> ...
>
> Here's what the standard says:
> http://www.fixprotocol.org/specification/fix40.doc
> page 15:
> 	Reject -
> 	The reject message should be issued when a message is received which  
> cannot
> be passed 	through to the application level.
> 	...
> 	Rejected messages should be logged and the incoming sequence number
> incremented.
> 	...
>
> I've seen this scenario in certified system: the client Order Entry  
> GUI may
> allow limits in excess of those configured in the session layer.  
> Should that
> happen, QuickFix would go in the reject/resend-request loop and will  
> never
> recover automatically.
>
> Bumping up the sequence number after a session level reject would make
> QuickFix a lot more user-friendly.
>
> Sincerely,
>
> Michael Kovalenko
>
> ======================================================================= 
> =======
> This message is for the sole use of the intended recipient. If you  
> received
> this message in error please delete it and notify us. If this message  
> was
> misdirected, CSFB does not waive any confidentiality or privilege. CSFB
> retains and monitors electronic communications sent through its  
> network.
> Instructions transmitted over this system are not binding on CSFB  
> until they
> are confirmed by us. Message transmission is not guaranteed to be  
> secure.
> ======================================================================= 
> =======
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [SPAM] [Quickfix-developers] Infinite resend loop

[Joerg T. <Joe...@ma...>]

Oren Miller wrote:
> Ok.  This answers my question.  Looks like it's pretty clear what has  
> to be done.  Thanks.

Oren,

does this mean your are planning to add session level rejects for all 
case except body length or checksum errors? That would resolve some of 
our customers complaints.

Thanks, Jörg

-- 
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

RE: [SPAM] [Quickfix-developers] Infinite resend loop

[James C. D. <jc...@co...>]

Joerg,
I think the test case we need to create is as follows:

Message has CORRECT body length, check sum, and sequence number; but =
FAILS
message validation, e.g. MSgType=3D&.

Quick fix should send session level reject with clear reason, and =
increment
the incoming sequence number to expect on the next message.

Does this look correct? If so we should create a test for this test =
case. We
should also review the existing test cases to ensure that we have proper
coverage for message rejection.

Also are we considering all FIX versions or just 4.2 forward?


Jim
=20
James C. Downs
Connamara Systems, LLC
53 W. Jackson Blvd
Suite 1627
Chicago, IL 60604
312 - 282 - 7746
www.connamara.com

-----Original Message-----
From: qui...@li...
[mailto:qui...@li...] On Behalf Of =
Joerg
Thoennes
Sent: Wednesday, April 21, 2004 4:52 AM
To: Oren Miller
Cc: Kovalenko, Michael; 'qui...@li...'
Subject: Re: [SPAM] [Quickfix-developers] Infinite resend loop

Oren Miller wrote:
> Ok.  This answers my question.  Looks like it's pretty clear what has=20
> to be done.  Thanks.

Oren,

does this mean your are planning to add session level rejects for all =
case
except body length or checksum errors? That would resolve some of our
customers complaints.

Thanks, J=F6rg

--
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [SPAM] [Quickfix-developers] Infinite resend loop

[Joerg T. <Joe...@ma...>]

Hi James,

> Message has CORRECT body length, check sum, and sequence number; but FAILS
> message validation, e.g. MSgType=&.

Yes. We should add test cases for different variants, too. E.g. 
duplicate message tags, etc. There are some tests in the "future" 
sections which probably could used.

> Quick fix should send session level reject with clear reason, and increment
> the incoming sequence number to expect on the next message.

And log to the event log. This is important, too.

> Does this look correct? If so we should create a test for this test case. We
> should also review the existing test cases to ensure that we have proper
> coverage for message rejection.

Yes.

> Also are we considering all FIX versions or just 4.2 forward?

If the spec not explicitely prohibits this, we should add it. It 
improves useability in error situations dramatically (avoiding loops).

James, you are the guy which always says "I am adding an acceptance test 
for it..." :-) This is a Good Thing - thank you very much! Do you add 
these cases directly to the CVS repository? I haven't checked it lately, 
though.

Cheers, Jörg

-- 
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen