Tim.
Currently the logging is generally the only thing that gives a reason
why something like this happens. You can, if you like, implement
your own logger to receive these messages through callbacks if you
like. There isn't any sort of enumeration that is really understood
by an application all that well since it is just text. For instance,
the logger will record "Timed out waiting for logon response" in this
scenario.
At this point, just about any reason QF has for disconnecting that it
knows about, there will be some message in the log indicating the
reason. You may not be so lucky in knowing why the other side
disconnected. Their maching may have shut down, they may have forced
the socket closed, taken the machine down, received a sequence number
that is too low or you sent the wrong comp id (at which point they
are permitted by the spec to just disconnect you). In some scenarios
they may send you a logout message with a reason in the text field,
but again it is not really reliably parsable by a machine.
I'm not sure what you mean by knowing that "QuickFIX has stopped
trying". Do you just mean for that particular connection attempt?
Unless you tell it otherwise, QuickFIX will continue trying
indefinitely as long as it is within the defined session time. The
configuration has settings for changing the reconnect interval, as
well as the logon timeout. This timeout refers to the time it sends
a Logon to the time it expects the response. If it fails to receive
the logon response in this time frame, it will close the connection
and retry at the next reconnect interval.
--oren
On Oct 25, 2006, at 5:01 PM, EclipseCap wrote:
> I am trying to capture logonTimedOut function. I am not having
> trouble
> connecting, but when I do I want my application to know that
> QuickFix has
> stopped trying.
>
> I also want to grab the reason why the session was disconnected.
> Either
> initiated by the client or server.
>
> I am sure it is right in front of me and I am just missing it.
>
> Thanks,
>
> Tim
|
