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

[Scott H. <sco...@fo...>]

Dear Caleb:

Thanks for patching the Session.cpp code to fix my problem.  I just today 
caught up to things and have ported your fix to my local copy of 
quickfixj/src/quickfix/Session.java.  The patch is attached; could we ask 
Steve to review it and check it in to quickfixj?

My underlying message length error (in netty2?) that caused my 
ResendRequest in the first place was intermittent and I haven't rigged a 
testbed to force it to happen on command.  But once it does happen (I saw 
it every other day or so before, and once several times in one day), I 
will know that the new code is working when I see the new "ResendRequest 
has been satisfied" message.  I guess then I will have to tackle the 
underlying problem before I can switch to QuickFIX/J in production....

Scott


On Tue, 3 Jan 2006, Caleb Epstein wrote:

> 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=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