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
>