No way to know about disconnects and other network events

[roji]

It seems that currently QuickFix doesn't provide any way of knowing what's going on with actual connections. For example, I have an application where a human trader clicks on "Connect", and when I start the SocketInitiator I would like to know about any connection failure and display a popup. Aside from a logging event there doesn't seem to be any (event-like) way to know this (aside from maybe polling the session/initiator).

I understand the concept that the actual connection management is an internal thing in QuickFix, that it goes down and up based on sessions etc., but it seems like there should be some way to at least be notified of exception situations.

If this is a good idea, I'd be glad to work on it and submit a pull request.

[gbirchmeier]

How do you think you'd go about implementing it? Callbacks in IApplication?

[roji]

After forgetting about this for a while, I encountered another issue that brought this up. A server had a time accuracy on my side. This made QuickFix refuse to connect, proper messages were logged, but there was no way for the application to know that login is failing for permanent reasons, and for what reasons. This intuitively seems like a scenario where I would expect to receive a "login failed permanently" of some sort.

This is not quite the same issue as the title here. On the one hand we have spontaneous events happening while already connected, and on the other we have a permanent login failure; but we have no visibility into either.

Is this something that's bothering other people? Is it worth thinking about this?

[perrich]

Hi, A method like onConnectionLost (when socket is closed, an error occurs or heartbeat does not have response) could definitively be a good way to implement a lot of behavior based on that.

In my case I need something like that to send an email to the sysadmin. I will try to provide an implementation if you are agree with that.

[gbirchmeier]

@roji, Please open another issue to discuss that idea. It's an idea worth discussing, but a little different from this one. (Also, I think it'd require a little bit of design thought, as right now I think QF/n doesn't distinguish between types of disconnects in a way that would enable such an idea to be readily implemented.)

[gbirchmeier]

@perrich, I think that would probably be a nice feature. Might I suggest calling it OnDisconnect()?

[perrich]

You've right OnDisconnect() is better.

[perrich]

It seems that the IApplication.OnLogout() is called when a connection issue appears if and only if the user is logged and has received a logon response. It does not manage all other cases but OnDisconnect() can.
Maybe, if session.Disconnect() is called with a reason and the responder is not null, we can call IApplication.OnDisconnect(reason, session);

I think we also need to catch exception in SocketInitiatorThread.Send() and call session.Disconnect().
I've not found any catch in call hierarchy when a message is sent.

[knocte]

I encountered another issue that brought this up. A server had a time accuracy on my side. This made QuickFix refuse to connect, proper messages were logged, but there was no way for the application to know that login is failing for permanent reasons, and for what reasons. This intuitively seems like a scenario where I would expect to receive a "login failed permanently" of some sort.

Exactly the issue I had for the past 3 days. There was no trace of the problem but a simple string "Sending time accuracy problem" in the log. No "ERROR" word or "Rejection" or "Failure". This has led me to read about all proposals to integrate QuickFixN with Logging frameworks, and given that it was not well received, I would at least propose a new overload for IApplication::OnLogout(Session), which receives more information about the problem. Maybe IApplication::OnLogout(Session,Nullable<SessionRejectReason>)?

[lobster2012-user]

If a break occurs after the Logon event, the Logout method will not be called. This behavior is not suitable for a productive environment . It is enough to add a call to a couple of lines of code in the RemoveThread(Sessionid) method.

[ericvergnaud]

At the point where RemoveThread is called, the underlying cause is no longer accessible.
So I suggest we capture the exception from SocketInitiatorThread.Read (line 103, in order to let developers properly manage the situation (based for example on the Exception type).
We could then call IApplication.OnDisconnect, passing it the captured exception ?
Happy to submit a PR if the idea makes sense.

[gbirchmeier]

I would love to see a PR about this.

(Lots of feature-request PRs are good ideas, but unless I'm personally fired up about it, I can't do the work for free!)