Quickfixj session reconnect delay

[robotrader]

I have a fix session to external provider established using quickfixj lib as Initiator role.
Provider's session requires only one active connection.

On some connection issues my app tries reconnect immediately.
But provider session needs some timeout, before killing previous connection.

Is that possible to configure "reconnect delay" in quickfixj properties file?

[chrjohn]

There is ReconnectInterval which could be set. Doesn't this work? Default is 30 seconds.

quickfixj/quickfixj-core/src/main/doc/usermanual/usage/configuration.html

Line 472 in 9e843b0

<TD> <I>ReconnectInterval</I> </TD>

So the question is on which issue it immediately reconnects? Do you have an example?

[robotrader]

It seems that we have some another problem...
After reconnet both, acceptor and initiator, start sending ResendRequest's to each other in an endless loop.

Example logs

`//Last messages exchange before disconnect
FIXT.1.1:INITIATOR->ACCEPTOR: 8=FIXT.1.1\u00019=74\u000135=0\u000149=ACCEPTOR\u000156=INITIATOR\u000134=0102\u000152=20240410-07:02:50.507000\u000110=151\u0001
FIXT.1.1:INITIATOR->ACCEPTOR: 8=FIXT.1.1\u00019=63\u000135=0\u000134=100\u000149=INITIATOR\u000152=20240410-07:03:19.467\u000156=ACCEPTOR\u000110=155\u0001

//Disconnect...

FIXT.1.1:INITIATOR->ACCEPTOR: 8=FIXT.1.1\u00019=97\u000135=A\u000134=101\u000149=INITIATOR\u000152=20240410-07:46:26.467\u000156=ACCEPTOR\u000198=0\u0001108=30\u000110=063\u0001
FIXT.1.1:INITIATOR->ACCEPTOR: Initiated logon request
FIXT.1.1:INITIATOR->ACCEPTOR: 8=FIXT.1.1\u00019=100\u000135=A\u000149=ACCEPTOR\u000156=INITIATOR\u000134=0107\u000152=20240410-07:46:26.578000\u000198=0\u0001108=30\u000110=126\u0001
FIXT.1.1:INITIATOR->ACCEPTOR: 8=FIXT.1.1\u00019=87\u000135=2\u000149=ACCEPTOR\u000156=INITIATOR\u000134=0108\u000152=20240410-07:46:26.578000\u00017=100\u000116=101\u000110=243\u0001
FIXT.1.1:INITIATOR->ACCEPTOR: Received logon
FIXT.1.1:INITIATOR->ACCEPTOR: MsgSeqNum too high, expecting 103 but received 107: 8=FIXT.1.1\u00019=100\u000135=A\u000134=0107\u000149=ACCEPTOR\u000152=20240410-07:46:26.578000\u000156=INITIATOR\u0001
FIXT.1.1:INITIATOR->ACCEPTOR: Enqueued at pos 107: 8=FIXT.1.1\u00019=100\u000135=A\u000134=0107\u000149=ACCEPTOR\u000152=20240410-07:46:26.578000\u000156=INITIATOR\u0001
FIXT.1.1:INITIATOR->ACCEPTOR: 8=FIXT.1.1\u00019=76\u000135=2\u000134=102\u000149=INITIATOR\u000152=20240410-07:46:26.690\u000156=ACCEPTOR\u00017=103\u000116=106\u000110=235\u0001
FIXT.1.1:INITIATOR->ACCEPTOR: Sent ResendRequest FROM: 103 TO: 106
FIXT.1.1:INITIATOR->ACCEPTOR: Enqueued at pos 108: 8=FIXT.1.1\u00019=87\u000135=2\u000134=0108\u000149=ACCEPTOR\u000152=20240410-07:46:26.578000\u000156=INITIATOR\u00017=100\u000116=101\u000110=243\u0001
FIXT.1.1:INITIATOR->ACCEPTOR: Received ResendRequest FROM: 100 TO: 101
FIXT.1.1:INITIATOR->ACCEPTOR: 8=FIXT.1.1\u00019=107\u000135=4\u000134=100\u000143=Y\u000149=INITIATOR\u000152=20240410-07:46:26.733\u000156=ACCEPTOR\u0001122=20240410-07:46:26.733\u000136=102\u0001123=Y\u000110=057\u0001
FIXT.1.1:INITIATOR->ACCEPTOR: Sent SequenceReset TO: 102
FIXT.1.1:INITIATOR->ACCEPTOR: 8=FIXT.1.1\u00019=74\u000135=0\u000149=ACCEPTOR\u000156=INITIATOR\u000134=0109\u000152=20240410-07:46:57.366000\u000110=176\u0001
FIXT.1.1:INITIATOR->ACCEPTOR: MsgSeqNum too high, expecting 103 but received 109: 8=FIXT.1.1\u00019=74\u000135=0\u000134=0109\u000149=ACCEPTOR\u000152=20240410-07:46:57.366000\u000156=INITIATOR\u000110=176\u0001
FIXT.1.1:INITIATOR->ACCEPTOR: Enqueued at pos 109: 8=FIXT.1.1\u00019=74\u000135=0\u000134=0109\u000149=ACCEPTOR\u000152=20240410-07:46:57.366000\u000156=INITIATOR\u000110=176\u0001
FIXT.1.1:INITIATOR->ACCEPTOR: Already sent ResendRequest FROM: 103 TO: 106. Not sending another.
FIXT.1.1:INITIATOR->ACCEPTOR: 8=FIXT.1.1\u00019=63\u000135=0\u000134=103\u000149=INITIATOR\u000152=20240410-07:46:57.458\u000156=ACCEPTOR\u000110=167\u0001
FIXT.1.1:INITIATOR->ACCEPTOR: 8=FIXT.1.1\u00019=87\u000135=2\u000149=ACCEPTOR\u000156=INITIATOR\u000134=0110\u000152=20240410-07:46:57.565000\u00017=102\u000116=102\u000110=239\u0001
FIXT.1.1:INITIATOR->ACCEPTOR: Enqueued at pos 110: 8=FIXT.1.1\u00019=87\u000135=2\u000134=0110\u000149=ACCEPTOR\u000152=20240410-07:46:57.565000\u000156=INITIATOR\u00017=102\u000116=102\u000110=239\u0001
FIXT.1.1:INITIATOR->ACCEPTOR: Received ResendRequest FROM: 102 TO: 102
FIXT.1.1:INITIATOR->ACCEPTOR: 8=FIXT.1.1\u00019=107\u000135=4\u000134=102\u000143=Y\u000149=INITIATOR\u000152=20240410-07:46:57.668\u000156=ACCEPTOR\u0001122=20240410-07:46:57.668\u000136=103\u0001123=Y\u000110=082\u0001
FIXT.1.1:INITIATOR->ACCEPTOR: Sent SequenceReset TO: 103
FIXT.1.1:INITIATOR->ACCEPTOR: 8=FIXT.1.1\u00019=74\u000135=0\u000149=ACCEPTOR\u000156=INITIATOR\u000134=0111\u000152=20240410-07:47:28.375000\u000110=168\u0001
FIXT.1.1:INITIATOR->ACCEPTOR: MsgSeqNum too high, expecting 103 but received 111: 8=FIXT.1.1\u00019=74\u000135=0\u000134=0111\u000149=ACCEPTOR\u000152=20240410-07:47:28.375000\u000156=INITIATOR\u000110=168\u0001
FIXT.1.1:INITIATOR->ACCEPTOR: Enqueued at pos 111: 8=FIXT.1.1\u00019=74\u000135=0\u000134=0111\u000149=ACCEPTOR\u000152=20240410-07:47:28.375000\u000156=INITIATOR\u000110=168\u0001
FIXT.1.1:INITIATOR->ACCEPTOR: Already sent ResendRequest FROM: 103 TO: 106. Not sending another.
FIXT.1.1:INITIATOR->ACCEPTOR: 8=FIXT.1.1\u00019=63\u000135=0\u000134=104\u000149=INITIATOR\u000152=20240410-07:47:28.467\u000156=ACCEPTOR\u000110=167\u0001
FIXT.1.1:INITIATOR->ACCEPTOR: 8=FIXT.1.1\u00019=87\u000135=2\u000149=ACCEPTOR\u000156=INITIATOR\u000134=0112\u000152=20240410-07:47:28.574000\u00017=103\u000116=103\u000110=242\u0001
FIXT.1.1:INITIATOR->ACCEPTOR: Enqueued at pos 112: 8=FIXT.1.1\u00019=87\u000135=2\u000134=0112\u000149=ACCEPTOR\u000152=20240410-07:47:28.574000\u000156=INITIATOR\u00017=103\u000116=103\u000110=242\u0001
FIXT.1.1:INITIATOR->ACCEPTOR: Received ResendRequest FROM: 103 TO: 103
.....`

[robotrader]

Hi!
A have received comments from ACCEPTOR side.
"As you can see from the below log, in your 'SequenceReset' messages you specify value of the next sequence number to be expected (NewSeqNo) but the sequence number that follows does not match the value specified (102 but 103 sent, 103 but 104 sent and so on). This creates a loop of the ResendRequests from our side and SequenceResets from yours."

As I can understand this comment, after we send ResendRequest to 102, the next outgoing message should be with 102 SeqNum, but we send 103...

[chrjohn]

It is correct that QFJ should send its next message with seqnum 102 directly after sending a SequenceReset with NewSeqNo=102.

Which version of QFJ are you using?
What are you doing in your fromAdmin/toAdmin or fromApp/toApp callbacks? Is there anything that might block for a longer time?

[robotrader]

We are using quickfixj-2.3.1 inside ApacheCamel quickfixj component.
So, any support handlers (fromAdmin/toAdmin or fromApp/toApp callbacks) implemented by Camel component.

[chrjohn]

OK, but without knowing what is going on in there it is hard to help further. To be honest I never saw the behaviour that QFJ sends out the wrong seqnum in a sequence reset.

1. Does this happen often or can you reproduce it reliably?
2. Could you please post your session settings?
3. Do you have a log available that has timestamps?

[chrjohn]

@robotrader adding to point 3. It would be helpful to have the full message log of the last say 10-20 messages before and after the incident. Best would be to attach the log.

[robotrader]

Maybe we need delay between Logon and sending ResendRequest messages?