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 ? >