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
Locked
