Is Session.sendToTarget() thread-safe?

Question

I am trying to integrate QFJ into a single-threaded application. At first I was trying to utilize QFJ with my own TCP layer, but I haven't been able to work that out. Now I am just trying to integrate an initiator. Based on my research into QFJ, I would think the overall design should be as follows:

The application will no longer be single-threaded, since the QFJ initiator will create threads, so some synchronization is needed. Here I am using an SocketInitiator (I only handle a single FIX session), but I would expect a similar setup should I go for the threaded version later on.

There are 2 aspects to the integration of the initiator into my application:

Receiving side (fromApp callback): I believe this is straightforward, I simply push messages to a thread-safe queue consumed by my MainProcessThread.
Sending side: I'm struggling to find documentation on this front. How should I handle synchronization? Is it safe to call Session.sendToTarget() from the MainProcessThread? Or is there some synchronization I need to put in place?

Not sure what your question is. "Is the class `quickfix.Session` thread-safe?", perhaps? Yes. — Michael, May 12 '21 at 16:46
Thank you Michael! In effect since the answer is yes, that is the only question, I'll reformulate. I have had difficulties finding this kind of info on the quickfix javadoc or on github. Do you have a link to back this up? If so could you put it an answer so I can mark this as answered. — MarkoPaulo, May 12 '21 at 17:09
Three things really. 1) I've used quickfix a fair bit at work and know that we don't wrap those components with anything to achieve thread-safety, and we've never had any issues 2) given that quickfix as a framework is based on the idea of using multiple threads, it would be quite irresponsible of them to provide primitives which are not thread-safe 3) I checked the implementation of `quickfix.Session` just now and saw they are using reentrant locks. — Michael, May 12 '21 at 18:22

Christoph John · Accepted Answer · 2021-05-12T23:47:35.407

As Michael already said, it is perfectly safe to call Session.sendToTarget() from multiple threads, even concurrently. But as far as I see it you only utilize one thread anyway (MainProcessThread).

The relevant part of the Session class is in method sendRaw():

    private boolean sendRaw(Message message, int num) {
        // sequence number must be locked until application
        // callback returns since it may be effectively rolled
        // back if the callback fails.
        state.lockSenderMsgSeqNum();
        try {
        .... some logic here
        } finally {
            state.unlockSenderMsgSeqNum();
        }

Other points:

Here I am using an SocketInitiator (I only handle a single FIX session), but I would expect a similar setup should I go for the threaded version later on.

Will you always use only one Session? If yes, then there is no use in utilizing the ThreadedSocketInitiator since all it does is creating a thread per Session.

The application will no longer be single threaded, since the QFJ initiator will create threads

As already stated here Use own TCP layer implementation with QuickFIX/J you could try passing an ExecutorFactory. But this might not be applicable to your specific use case.

Is Session.sendToTarget() thread-safe?

1 Answers1