Overview
This article is intended to describe session management: creation, reconnection, and disconnection of the session in FIX Antenna HFT.
Session creation
There are three cases of the session creation:
- create all sessions at the service start
- create a session on the fly as needed
- create a session on demand as unregistered acceptor (if the engine.properties file is configured to allow this: UnregisteredAcceptor.CreateSession=true)
In the first two cases a session is created ahead and in the last case the engine has to allocate all resources only when a logon message is received.
Resources allocation is quite a heavy operation and one shouldn't use engine's threads in the callbacks to create a session. Creation of the session on demand as unregistered acceptor is performed in a separate thread (one of the engine's general purpose workers).
The reason to create sessions ahead is to better control the sessions' parameters (only defaults can be applied in case of unregistered acceptors).
When a session is created ahead and is not used, it consumes memory and file descriptors but does not consume CPU resources.
The following piece of code shows the creation of the session ahead (either at the service start or on the fly):
The following piece of code shows the creation of the session on demand:
Once the session is created it becomes registered and onUnregisteredAcceptor will not be called until full session destroy, so one should use ssn->connect() to activate this session.
Session storage will be loaded and SeqNums will be continued for unregistered acceptor even after full session destroy if session storage logs are accessible for the engine.
Session disconnection
- NonGraceful disconnection (without a Logout message - just drop TCP link):
ssn->disconnectNonGracefully()
When the counterparty disconnects without sending a Logout onLogoutEvent() is not called for the session.
onNewStateEvent() callback should be used in this situation.
- Graceful disconnection (with a Logout message)
ssn->disconnect(reason)
It is needed to take additional actions to check whether the session is finally disconnected. The session state should become Session::CORRECTLY_TERMINATED or Session::NON_GRACEFULLY_TERMINATED.
When a session is configured to continue SeqNums on the next connect (see IntradayLogoutTolerance) it will be marked as Session::NON_GRACEFULLY_TERMINATED even if logout is received.
The following piece of code shows the session disconnection with the session release:
Session reconnection
Acceptor
According to the FIX protocol standard when connection is terminated unexpectedly, the acceptor is moved to the "Wait for logon" state. It is expected that the initiator on the remote side re-establishes telecommunication link and sends FIX Logon message continuing sequence numbers. When correct logon is received it is accepted by the engine and the session acceptor continues working from the point of termination.
Initiator
In the case that the initiator FIX-session is disconnected nongracefully there is a way to enable automatic reconnection to be able to reconnect as soon as the server or the connection is available again. The reconnection count can be set to -1 in the engine.properties file to make infinite reconnection attempts.
ForcedReconnect = true
ReconnectMaxTries = -1
ReconnectInterval = 5
To interrupt reconnection the Session::disconnectNonGracefully method is called.