4

This page in the QuickFix/J documentation makes the following claim:

Sessions exist whether or not a counter party is connected to it. As soon as a session is created, you can begin sending messages to it. If no one is logged on, the messages will be sent at the time a connection is established with the counterparty.

I have been testing this behaviour via the following steps:

  1. Initialize a new QuickFix session connecting as normal
  2. Interrupt the connection to the remote server so a logout occurs for the session.
  3. Send a message via Session.sendToTarget()
  4. Allow QuickFix to restore the connection (so a login occurs for the session)

As far as I can see, the message is never sent.

Debugging through the code, I hit this line shortly after receiving the toApp() callback. As far as I can see, the message is only sent when isLoggedOn() is true. In the event of it not being true (as here), no alternative action is taken.

My expectation from the documentation quoted above is that QuickFix/J should somehow queue up the message internally so that, when the session is restored, it will be sent. Two questions:

  1. Is this interpretation correct?
  2. If so, where and how is this implemented?

Here are my connection parameters for reference:

[DEFAULT]
ConnectionType=initiator
LogonTimeout=60
ReconnectInterval=30
FileStorePath= ...
HeartBtInt=30
StartTime=22:15:00
EndTime=21:55:00
UseDataDictionary=Y


[SESSION]
BeginString=FIX.4.4
SenderCompID= ...
TargetCompID= ...
PersistMessages=Y
ResetOnLogon=Y
SessionQualifier= ...
SocketConnectHost= ...
SocketConnectPort= ...
Username= ...
Password= ...
DataDictionary=config/dict/fix44.xml

Many thanks in advance

user2248785
  • 385
  • 3
  • 12

1 Answers1

2

OK, so I have the message queuing logic working. The issue was the ResetOnLogon=Y which was presumably messing up the sequence number increments.

user2248785
  • 385
  • 3
  • 12
  • So are you seeing the gap fills? because if you reset the sequence number on logon then presumably you won't get a ResendRequest because the sequence numbers are reset. That means your test fails, no? – rupweb Dec 13 '16 at 19:21
  • No, I didn't see any gap fills. Presumably resetting the sequence on logon has the effect of throwing out any previous state associated with the session. – user2248785 Dec 14 '16 at 09:59
  • well yes I guess it does. So as far as I understand your test it's that a new session can be created and messages stored against that session, but then once that client actually logs in and resets the seq numbers, then none of the stored messages will actually be relayed. Is that right? – rupweb Dec 15 '16 at 10:38
  • Yes, that's what I found. – user2248785 Dec 19 '16 at 09:22