Re: [Quickfix-developers] What should be done if ResendRequest generated by doTargetTooHigh have never been received or acted upon

[len <le...@fa...>]

Thanks everybody for the very quick response. 

The effect I have described occurs in version 1.11.x. I have already
downloaded latest source 1.12.2 and very quick check reveal addition of
Session level "m_sendRedundantResendRequests" variable which can be set by
Application level code which control reissue of already sent ResendRequest,
which is probably enough for my objectives - what can I say, stupid me, I
have to do it first before arrogantly asking the question.

Interestingly enough Caleb refers for time-out behavior which I did not
discover yet by surfing through the code. I am planning to test it though
but it will take me a week or two because I am on the other project and I
will need to back-port our QuickFix sources changes (compiling it into DLL
and dozen of other little things)

I will post my findings as soon as I can.

Thank you guys.

Len.

-----Original Message-----
From: Caleb Epstein [mailto:cal...@gm...] 
Sent: Monday, August 21, 2006 4:26 PM
To: Joerg Thoennes
Cc: len; qui...@li...
Subject: Re: [Quickfix-developers] What should be done if ResendRequest
generated by doTargetTooHigh have never been received or acted upon

On 8/21/06, Joerg Thoennes <Joe...@ma...> wrote:
> > We recently encounter the situation when remote FIX engine seems to
ignore
> > ResendRequest message generated by our QuickFix engine. Unfortunately
that
> > ultimately blocked our running QuickFix engine because remote party was
keep
> > sending messages with higher and higher sequence numbers and QuickFix
simply
> > queue the message and just log ""Already sent ResendRequest FROM:.".
> > Therefore Application code was not aware about problem and QuickFix did
not
> > try to resolve it.
> >
> > Did anyone have experience with it? What solution should be? I am
inclining
> > to add some time-out check (basically add time when resendRequest was
sent
> > into m_state and resend the message after certain period of time). May
be
> > upcoming QuickFix releases address this problem?
>
> reading the discussion in the FIX Protocol forums, I would like to support
John Prewetts suggestion
> to force a logout (or disconnect) after a time-out. Oren, do you think it
is worth to add
> configuration option as "ResendTimeout" to support this?

What version of QF are people testing this behavior with?  I think the
very latest release 1.12.2 (and anything built from the SVN sources
after 4/29/06 (r1437)) will timeout the connection when this happens
and no new code or configuration should be necessary to support it.
It would be great if someone could test this.

There *was* a bug where the Session's lastReceived timestamp was being
updated before the sequence number checking was done, which caused
test requests never to go out and the connection to stay alive in this
scenario.  this bug was fixed in April, but there haven't been any
QuickFIX releases since then ((until last week).

See my email about this from July 20.

http://sourceforge.net/mailarchive/message.php?msg_id=32260466

-- 
Caleb Epstein