Session state is set incorrectly when MessageStore cannot persist Logon message

[gokayhuz]

Describe the bug
When QFJ receives a Logon message for an incoming session, it:

1. callsgenerateLogon(),
2. (which) generates a Logon message,
3. calls sendRaw()
4. (finally) calls state.setLogonSent(true) on the Session object.

Here the return value of sendRaw() is not checked. and QFJ assumes a Logon message has been sent to the counterparty (even in cases where it has not). From this point on, the Application will be able to send messages to the counterparty.

if however, the call to MessageStore.persist() fails and the outgoing message cannot be persisted (due to an IOException for example), Session.send() is never invoked and message is not sent to the counterparty. But still QFJ calls state.setLogonSent(true). Any further outgoing messages to the counterparty will be rejected as they will be waiting for a Logon message

Expected behavior
in Session.generateLogon(), the return value of sendRaw() call should be checked, and state.setLogonSent(true) should be called only if sendRaw() has returned true

system information:
environment/version independent. But is still present as of the latest commit on 18.5.2026 and 3.0.2

[chrjohn]

@gokayhuz thanks for the report. Sounds sensible. Although even if sendRaw returned true it is not guaranteed that the message was sent, only queued for transmission by MINA.

[gokayhuz]

@chrjohn : that is definitely true, but currently there is a MessageStore (most probably an IO-bound one) layer between QFJ and MINA for outgoing messages. If this layer fails for one message, message never gets to MINA, but QFJ still acts as if it had been sent out.

If there were a check for the return value, and QFJ knew MessageStore failed and message was never sent to the counterparty, it would not have updated session state to LogonSet = true and subsequent sendRaw() calls would also fail. This would eliminate one certain point-of-failure

Without the return value check, QFJ has an incorrect state where it thinks logon has been sent, and subsequennt application messages are also sent out (which are rejected by the CP, and trigger disconnect). And on next successful logon, these previously rejected application-level messages are not resent automatically as they have already been sent out and sequence numbers have been incremented for these on both parties.

I think it is a safer assumption that once message has been handed down to MINA layer, it is on equal level with any subsequent message, and they are more likely to either all succeed or fail together. And even in the total or failure failure case, session would recover automatically on next logon with the messages in MessageStore on the sending side, and sequence numbers not incremented on the remote side

[chrjohn]

I'll have a closer look in a few weeks, currently OOO.