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

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

On 8/21/06, len <le...@fa...> wrote:

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

It doesn't seem like issuing more ResendRequests would help with this
counterparty.

> 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

This is the standard FIX heartbeating mechanism.  If no messages are
received (in proper sequence) in <HeartbeatInterval> seconds, a
heartbeat message will be sent.  If still no messages (in proper
sequence) are received after 1.2 * <HeartbeatInterval>, a Test request
is sent, and the connection will eventually timeout if no messages are
received for 2.4 * HeartbeatInterval.  Look at the code in
SessionState.h and Session::next()

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

Perhaps you could expoound on what changes you've made to the QuickFIX
sources.  If they are beneficial to others, maybe you can have them
incorporated into the upstream codebase to reduce the need for this
sort of integration.

QuickFIX already builds as a DLL doesn't it?

-- 
Caleb Epstein