mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guido Medina <oxyg...@gmail.com>
Subject Re: ConcurrentLinkedQueue vs MpscChunkedArrayQueue
Date Sat, 15 Oct 2016 19:12:42 GMT
I will take a look again at the source code but not today, I will let you
know on Monday if is applicable for MINA core, it seems it is not the case,
my application is simply forwarding each decoded FIX message to an Akka
actor which are backed by a high performance queue,
I was thinking (will double check) these ByteBuffers were queue somehow
before they are picked by the handlers which is where a non-blocking MpSc
would play a role.

But maybe I misunderstood the code I saw.

I will check again and let you know,

Have a nice weekend,


On Sat, Oct 15, 2016 at 7:33 PM, Emmanuel Lecharny <elecharny@apache.org>

> Tio be clear : when some sockets are ready for read (ie, the OP_READ flag
> has been set, and there is something in the socket to be read), the
> IoProcessor call to select()) will return and we will have a set of
> SelectionKey returned. Thsi set contains the set of all the channel that
> are ready for some processing. The IoProcessor thread will process them one
> after the other, from top to bottom. That means we don't process multiple
> sessions in parallel when all those sessions are handled by one
> singleIoProcessor. You have to be careful in what you do in your
> application, because any costly processing, or any synchronous access to a
> remote system will block the other sessions processing.
> Now, we always start the server with more than one IoProcessor (typically,
> Nb core + 1 Ioprocessor). You can also fix a higher number of IoProcessor
> if you like, but at some point, if your CPU is 100% used, adding more
> IoProcessor does not help.
> What kind of performance are you expecting to reach ? (ie, how many
> requests per second ?)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message