QuickFIX/J

Threaded vs Non threaded implementations

Classic

List

Threaded

5 messages Options

Guido Medina

Threaded vs Non threaded implementations

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/

Hi,

I have always been curious about the threaded vs non-threaded implementations of both initiators and acceptors,

I have a system which is inspired by reactive platforms, in this case I'm using Java 8 + Akka, here are the aspects of my system:

Each initiator creates an actor that acts as an in-memory queue (The Akka's actor's mailbox)
The initiator life cycle is managed by the actor, when it starts the initiator starts, when it stops the initiator stops, all done by message passing.
Initiator FIX messages are forwarded to its corresponding actor and then the actor process them - asynchronously.
Messages sent thru the initiator are sent using the thread pool that runs the actor.

Questions:

If I have 2 initiators, what happens when each actor tries to send messages to the other side? will it run on each's actor's thread pool or will it queue them to some QFJ single thread?
I do understand that incoming messages will be process by a single thread but if they forward the messages they receive and process them asynchronously no performance penalty should be paid right?

I have the same design for acceptors and the same questions.

Best regards,

Guido.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

Guido Medina

Re: Threaded vs Non threaded implementations

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/

I think I know the answer, threaded implementations are there to use a dedicated thread for the Application subclass methods call,

so if you block because of a DB call during an income message then all of the other initiators will be blocked at that moment.

But if your system is asynchronous and no blocking operation happens in your Application subclass implementation then there is no point using the threaded implementation.

Correct me if I'm wrong please.

Guido.

On Sat, Mar 4, 2017 at 11:55 AM, Guido Medina <[hidden email]> wrote:

Hi,

I have always been curious about the threaded vs non-threaded implementations of both initiators and acceptors,
I have a system which is inspired by reactive platforms, in this case I'm using Java 8 + Akka, here are the aspects of my system:
Each initiator creates an actor that acts as an in-memory queue (The Akka's actor's mailbox)
The initiator life cycle is managed by the actor, when it starts the initiator starts, when it stops the initiator stops, all done by message passing.
Initiator FIX messages are forwarded to its corresponding actor and then the actor process them - asynchronously.
Messages sent thru the initiator are sent using the thread pool that runs the actor.
Questions:
If I have 2 initiators, what happens when each actor tries to send messages to the other side? will it run on each's actor's thread pool or will it queue them to some QFJ single thread?
I do understand that incoming messages will be process by a single thread but if they forward the messages they receive and process them asynchronously no performance penalty should be paid right?
I have the same design for acceptors and the same questions.

Best regards,

Guido.

Colin DuPlantis

Re: Threaded vs Non threaded implementations

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/

Threaded implementations assign a thread for each session. Non-threaded implementations use a single thread for all sessions.

Depending on your message volume and how long it takes you to hand the messages off to a thread pool, you might or might not see a big difference.

If you have a single session, it won't make any difference at all.

On 03/04/2017 04:14 AM, Guido Medina wrote:

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/
I think I know the answer, threaded implementations are there to use a dedicated thread for the Application subclass methods call,
so if you block because of a DB call during an income message then all of the other initiators will be blocked at that moment.

But if your system is asynchronous and no blocking operation happens in your Application subclass implementation then there is no point using the threaded implementation.

Correct me if I'm wrong please.

Guido.

On Sat, Mar 4, 2017 at 11:55 AM, Guido Medina <[hidden email]> wrote:

Hi,

I have always been curious about the threaded vs non-threaded implementations of both initiators and acceptors,

I have a system which is inspired by reactive platforms, in this case I'm using Java 8 + Akka, here are the aspects of my system:

Each initiator creates an actor that acts as an in-memory queue (The Akka's actor's mailbox)

The initiator life cycle is managed by the actor, when it starts the initiator starts, when it stops the initiator stops, all done by message passing.

Initiator FIX messages are forwarded to its corresponding actor and then the actor process them - asynchronously.

Messages sent thru the initiator are sent using the thread pool that runs the actor.

Questions:

If I have 2 initiators, what happens when each actor tries to send messages to the other side? will it run on each's actor's thread pool or will it queue them to some QFJ single thread?

I do understand that incoming messages will be process by a single thread but if they forward the messages they receive and process them asynchronously no performance penalty should be paid right?

I have the same design for acceptors and the same questions.

Best regards,

Guido.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

Guido Medina

Re: Threaded vs Non threaded implementations

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/

I do have several initiator and acceptor sessions but the messages are hand off immediately, but what about sending messages?

The messages are hand off by putting them into non-blocking MPSC (Multiple Producer, Single Consumer) queue implementation.

On Sat, Mar 4, 2017 at 2:21 PM, Colin DuPlantis <[hidden email]> wrote:

QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/ QuickFIX/J" rel="noreferrer" target="_blank">http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/
Threaded implementations assign a thread for each session. Non-threaded implementations use a single thread for all sessions.

Depending on your message volume and how long it takes you to hand the messages off to a thread pool, you might or might not see a big difference.

If you have a single session, it won't make any difference at all.

On 03/04/2017 04:14 AM, Guido Medina wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/
I think I know the answer, threaded implementations are there to use a dedicated thread for the Application subclass methods call,
so if you block because of a DB call during an income message then all of the other initiators will be blocked at that moment.

But if your system is asynchronous and no blocking operation happens in your Application subclass implementation then there is no point using the threaded implementation.

Correct me if I'm wrong please.

Guido.

On Sat, Mar 4, 2017 at 11:55 AM, Guido Medina <[hidden email]> wrote:

Hi,

I have always been curious about the threaded vs non-threaded implementations of both initiators and acceptors,

I have a system which is inspired by reactive platforms, in this case I'm using Java 8 + Akka, here are the aspects of my system:

Each initiator creates an actor that acts as an in-memory queue (The Akka's actor's mailbox)

The initiator life cycle is managed by the actor, when it starts the initiator starts, when it stops the initiator stops, all done by message passing.

Initiator FIX messages are forwarded to its corresponding actor and then the actor process them - asynchronously.

Messages sent thru the initiator are sent using the thread pool that runs the actor.

Questions:

If I have 2 initiators, what happens when each actor tries to send messages to the other side? will it run on each's actor's thread pool or will it queue them to some QFJ single thread?

I do understand that incoming messages will be process by a single thread but if they forward the messages they receive and process them asynchronously no performance penalty should be paid right?

I have the same design for acceptors and the same questions.

Best regards,

Guido.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users

Christoph John

Re: Threaded vs Non threaded implementations

QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/

Hi,

how do you send your messages? I assume using lookupSession(sessionID) and then send(). So when you
have looked up a Session object for each FIX session then you can use them with a thread per Session
each. You could also try to send messages to a session with multiple threads. There is some locking
around the sender sequence number, which should hopefully work. ;)

Cheers,
Chris.

On 04/03/17 16:40, Guido Medina wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
>
> I do have several initiator and acceptor sessions but the messages are hand off immediately, but
> what about sending messages?
> The messages are hand off by putting them into non-blocking MPSC (Multiple Producer, Single
> Consumer) queue implementation.
>
> On Sat, Mar 4, 2017 at 2:21 PM, Colin DuPlantis <[hidden email]
> <mailto:[hidden email]>> wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J <http://www.quickfixj.org/documentation/%0AQuickFIX/J> Support:
> http://www.quickfixj.org/support/ <http://www.quickfixj.org/support/>
>
>
>
> Threaded implementations assign a thread for each session. Non-threaded implementations use a
> single thread for all sessions.
>
> Depending on your message volume and how long it takes you to hand the messages off to a
> thread pool, you might or might not see a big difference.
>
> If you have a single session, it won't make any difference at all.
>
>
> On 03/04/2017 04:14 AM, Guido Medina wrote:
>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ <http://www.quickfixj.org/documentation/>
>> QuickFIX/J Support:http://www.quickfixj.org/support/ <http://www.quickfixj.org/support/>
>>
>>
>> I think I know the answer, threaded implementations are there to use a dedicated thread for
>> the Application subclass methods call,
>> so if you block because of a DB call during an income message then all of the other
>> initiators will be blocked at that moment.
>> But if your system is asynchronous and no blocking operation happens in your Application
>> subclass implementation then there is no point using the threaded implementation.
>> Correct me if I'm wrong please.
>> Guido.
>> On Sat, Mar 4, 2017 at 11:55 AM, Guido Medina <[hidden email] <mailto:[hidden email]>>
>> wrote:
>>
>> Hi,
>> I have always been curious about the threaded vs non-threaded implementations of both
>> initiators and acceptors,
>> I have a system which is inspired by reactive platforms, in this case I'm using Java 8 +
>> Akka, here are the aspects of my system:
>>
>> * Each initiator creates an actor that acts as an in-memory queue (The Akka's actor's
>> mailbox)
>> * The initiator life cycle is managed by the actor, when it starts the initiator
>> starts, when it stops the initiator stops, all done by message passing.
>> * Initiator FIX messages are forwarded to its corresponding actor and then the actor
>> process them - asynchronously.
>> * Messages sent thru the initiator are sent using the thread pool that runs the actor.
>>
>> Questions:
>>
>> * If I have 2 initiators, what happens when each actor tries to send messages to the
>> other side? will it run on each's actor's thread pool or will it queue them to some
>> QFJ single thread?
>> * I do understand that incoming messages will be process by a single thread but if they
>> forward the messages they receive and process them asynchronously no performance
>> penalty should be paid right?
>>
>> I have the same design for acceptors and the same questions.
>> Best regards,
>> Guido.
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org!http://sdm.link/slashdot
>>
>> _______________________________________________
>> Quickfixj-users mailing list
>> [hidden email] <mailto:[hidden email]>
>> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>> <https://lists.sourceforge.net/lists/listinfo/quickfixj-users>
> ------------------------------------------------------------------------------ Check out the
> vibrant tech community on one of the world's most engaging tech sites, SlashDot.org!
> http://sdm.link/slashdot _______________________________________________ Quickfixj-users
> mailing list [hidden email]
> <mailto:[hidden email]>
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
> <https://lists.sourceforge.net/lists/listinfo/quickfixj-users>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

--
Christoph John Development & Support Direct: +49 241 557080-28 Mailto:[hidden email]
http://www.macd.com <http://www.macd.com/>
----------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------
MACD GmbH Oppenhoffallee 103 D-52066 Aachen Tel: +49 241 557080-0 | Fax: +49 241 557080-10
Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald
----------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------

take care of the environment - print only if necessary

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users