The connections count is usually "finite" (not worth the effort), but the
queue for packets, isn't also a ConcurrentLinkedQueue?
I'm not sure how MINA core stores the packets received before they are
passed to their handler.

On Sat, Oct 15, 2016 at 2:27 PM, Emmanuel Lecharny <elecha...@apache.org>
wrote:

> On Sat, Oct 15, 2016 at 1:20 PM, Guido Medina <oxyg...@gmail.com> wrote:
>
> > Hi,
> >
> > I was looking at MINA core source code and I noticed events are publish
> to
> > a ConcurrentLinkedQueue so here are my questions and suggestions:
> >
> >    - Does ConcurrentLinkedQueue for these cases use the Pattern of
> > *Multiple
> >    Producer/Single Consumer* (MpSc) or *Multiple Producer/Multiple
> > Consumer*
> >    (MpMc)
> >
>
> MpMc.
>
>
>
> >    - For low latency applications (in my case I'm talking QuickFixJ for
> the
> >    financial industry) would it benefit from a MpSc that has low memory
> >    footprint (more like low GC footprint)?
> >
> > If that is the case I would shade JCtools dependency and use the queue:
> > https://github.com/JCTools/JCTools/blob/master/jctools-
> > core/src/main/java/org/jctools/queues/MpscChunkedArrayQueue.java
> >
> > Such queue uses ring buffers (power of two arrays) and linked them if
> they
> > need to expand, which is great for theoretically unbounded queues but
> with
> > the benefit of not used linked nodes per element but linked arrays.
> >
> > Recently Netty replaced their non-blocking linked queues for that one.
> >
>
> That is an option.
>
> Now, I would say that for an application requiring low latency, basing it
> on top of NIO makes littel sense, considering the extra cost compared to a
> Blocking IO solution (and we are talking about 30% performance penalty, at
> least).
>
> Do you need to handle potentially millions of connections ?
>

Reply via email to