Hi,

is the pasted stack trace complete? I can not gather much from it. There should also be log entries from QFJ along with the IOException. Can you post them?

I have never seen this behaviour before. Is it reproducible? Did it stop at some time or did it keep running like that?
When an exception occurs, the exceptionCaught() callback from the AbstractIoHandler should get notified and close the session.
Where are you running the QFJ session? Is it a plain Java process or are you running it inside an application server or Spring application?

Thanks,
Chris.

And of course as always: would be better to first ask on the mailing list. We can clarify there if it really is a bug.

Hi,

is the pasted stack trace complete? I can not gather much from it. There should also be log entries from QFJ along with the IOException. Can you post them?

We do not see another exceptions in log.

I have never seen this behaviour before. Is it reproducible? Did it stop at some time or did it keep running like that?

When an exception occurs, the exceptionCaught() callback from the AbstractIoHandler should get notified and close the session.

Where are you running the QFJ session? Is it a plain Java process or are you running it inside an application server or Spring application?

• Reproducible from time to time.
• This is Java plain application which use Spring Core inside.

I believe we found the way how to achieve this behavior. It is definitely not an expected working behavior, but as a result, quickfix could be stuck in some wrong state forever.

From time to time we have an issue with our HyperV cloud. Virtual machine is frozen for ~30-40 seconds. (it is testing environment)
During this time quickfix client tries to reconnect and send logon message.
When VM becomes alive, application throws an exception for TCP session and then try to handle new connection from client and process several logon messages for the same quickfix session.

Probably qfSession.hasResponder() keeps wrong state forever due to exception in Session.disconnect

  public void disconnect(String reason, boolean logError) throws IOException {
        try {
            final boolean logonReceived = state.isLogonReceived();
            final boolean logonSent = state.isLogonSent();

            synchronized (responderLock) {
                if (!hasResponder()) {
                    if (!ENCOUNTERED_END_OF_STREAM.equals(reason)) {
                        getLog().onEvent("Already disconnected: " + reason);
                    }
                    return;
                }
                final String msg = "Disconnecting: " + reason;
                if (logError) {
                    getLog().onErrorEvent(msg);
                } else {
                    getLog().onEvent(msg);
                }
                responder.disconnect();   // Maybe exception is here 
                setResponder(null);
            }

Hi,

OK, if the whole VM froze for 30 seconds all sort of things can happen.

You are right: given the log message "Multiple logons/connections for this session are not allowed" it looks like the responder was not set to null.
But good that you can reproduce it. So you could checkout the code from github, tentatively wrap parts of the disconnect() method in a try block with cleanup of the responder in a finally-block and try to reproduce again.
But I would actually expect to see QFJ classes appear in the exception stack trace if something in that method failed. That is also why I was asking if this is a plain Java process. I don't know much about Spring but assume that some parts might run differently than in a "normal" Java process. E.g. sometimes Exceptions are swallowed if thrown in threads that are running as part of a thread pool.

When you say that the Exception might occur in or after responder.disconnect() is called then you should have something in your log file like "Disconnecting: " because that happens some lines above. Do you see something like that in your log file?
Could you maybe post the contents of your event log (including exceptions) around the freeze?

Thanks,
Chris.

Hi,

I am sorry for late response.
We transferred our test environment from VM to hardware server.
So, logs were lost and currently we do not have similar issues.

Dmitry.

OK, feel free to update the issue when you encounter problems again.