Re: [Quickfix-developers] Already sent ResendRequest ... Not sending another.

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

Yeah, I'm not sure about removing the queue completely.  It comes off of 
this recommendation from the FIX protocol.

· It is also recommended that an engine should store out of sequence 
messages in a temporary queue and process them in order when the gap is 
closed. This prevents generating resend requests for n->m, n->m+1, 
n->m+2, ... which can result in many resent PossDupFlag=Y messages.

I *think* it might be ok for us to do away with the queue, because I 
believe we are blocking any sends while a resend request was being 
processed (making it impossible to create the above scenario).  
Otherwise removing the queue would cause some serious thrashing on a 
high frequency system that would be unrecoverable.  If it can be 
demonstrated that a high frequency system can gracefully handle resend 
request scenarios, I would be ok removing the queue.

--oren

Caleb Epstein wrote:

> On 1/3/06, *Oren Miller* <or...@qu... 
> <mailto:or...@qu...>> wrote:
>
>     Well, the initiator sent a resend request from 197648 to 0 after
>     logging
>     in, and the acceptor responded with a sequence reset from 197648 to
>     197651.  No messages would have been queued, so no queued messages
>     would
>     have been processed.  So yeah, I would think that it is not being
>     reset
>     in the correct place.
>
>
> Ah that explains it.  I didn't read the log closely enough and missed 
> this reset.
>
> It looks like the right place for the "have we satisfied an 
> outstanding resend request" logic is in Session::verify.  I've just 
> committed a change that moves this logic from Session::nextQueued to 
> here and it passes all user and acceptance tests.  There will be a new 
> event logged when this happens:  "ResendRequest for messages FROM: # 
> TO: # has been satisfied.".
>
> Shifting gears slightly, this raises (again) the queueing of messages 
> from the counterparty.  In Scott's case I'm pretty sure there was at 
> least one message sitting in the SessionState's m_queue that would 
> never be emptied out (#197650) until the session disconnected.
>
> I've posted before about the potential problems associated with 
> queueing messages, specifically Admin-type messages (see 
> http://sourceforge.net/mailarchive/forum.php?thread_id=7090286&forum_id=103 
> <http://sourceforge.net/mailarchive/forum.php?thread_id=7090286&forum_id=103>), 
> and I'm wondering if it might not make sense to remove the queueing 
> logic from the Session entirely.  Its a potential performance 
> optimization that has the potential to cause a memory leak (e.g. 
> queued messages that are skipped by a SequenceReset) and worse, 
> incorrect behavior (see email thread linked previously).
>
> Removing the queue would also simplify the code in the Session class, 
> which is always a good thing IMHO.  Failing that, Admin-type messages 
> should probably not be enqueued, based on the reasons I outlined in 
> the email thread from April.  Oren, what do you think of this?
>
> -- 
> Caleb Epstein
> caleb dot epstein at gmail dot com