Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FIXEngine can take over sessions even when using SOLE_LIBRARY mode or using SessionProxy #502

Open
pcdv opened this issue Feb 14, 2024 · 4 comments

Comments

@pcdv
Copy link
Contributor

pcdv commented Feb 14, 2024

In case of library timeout, the Framer acquires the sessions of the library. Once acquired, messages can be sent to the session without going through the library (e.g. Heartbeat or Logout).

When using SOLE_LIBRARY mode, this seems counter-intuitive:

  • in this mode, TCP connections are not managed while the library is not connected, Logon messages are ignored by the Framer etc.
  • shouldn't the Framer be more passive wrt sessions when the library is disconnected with a timeout?

Even without SOLE_LIBRARY, this is problematic when one needs to control the sending of FIX messages through a SessionProxy (known only at library level): it the library times out, messages will be sent circumventing the SessionProxy.

The problem with this is that it becomes impossible to keep track of sent MsgSeqNum in a clustered solution.

A configuration parameter should allow to prevent the engine from autonomously sending messages to sessions.

@pcdv
Copy link
Contributor Author

pcdv commented Feb 14, 2024

Reading #361 (Don't revert ownership of offline sessions to the Engine in Sole Library mode) seems to indicate that this is a bug.

@haoyang1994
Copy link

I have the same confusion. The existing tcp connection will not be released when the sole library is disconnected, but will be taken over by the Gateway Library. As a result, SessionProxy cannot track all outbound messages. I'm wondering whether to put Engine and Library in the same process and release the engine's tcp connection in the library disconnect callback.

@pcdv
Copy link
Contributor Author

pcdv commented Feb 20, 2024

FYI this is what I do: several processes embed their own engine + library, even though that is not the original philosophy behind artio (and is heavier in terms of processing).

Nevertheless, disconnections between engine and library due to timeout can still happen. I've seen it in two scenarios:

  • invalid shutdown implementation on my side: the library would time out while the engine was closing (hopefully fixed now)
  • attaching a debugger to the process

I'm wondering whether I should take care of closing all sessions from the library before shutting down the engine, to avoid the risk of having sending uncontrolled outbound messages because of this issue.

@pcdv
Copy link
Contributor Author

pcdv commented Mar 15, 2024

In issue #503, another example of message (SequenceReset) sent without going through SessionProxy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants