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

[Caleb E. <cal...@gm...>]

On 1/3/06, Oren Miller <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=3D7090286&forum_id=
=3D103
), and I'm wondering if it might not make sense to remove the queueing logi=
c
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