+1 to investigate this for sure. I’ve seen and attended a few of the same Akka presentations.
The main bit is for it to be able to split the work and execute in parallel when possible (divide and conquer) so if the work/code isn’t splittable into smaller units of concurrent work then not going to see much benefit, atm I think our code probably needs a bit of tlc, to make best use of it. Probably best to think what on our hot path is divide-able to be more parallel in the way it could run. I’m thinking deserialisation of buffers to packets, post office delivery to queues. The bits I could think of most is the actor model recently. Cheers Mike Sent from my iPhone > On 13 Apr 2018, at 12:36, nigro_franz <nigro....@gmail.com> wrote: > > HI guys!!! > > after a couple of talks I've seen about Akka and the (seems good) > ForkJoinPool experience and a tons of metrics i have collected on Artemis > related to the current implementation used, I'm starting to believe that the > broker could benefit a lot by using a ForkJoinPool. > > The current implementation is limiting by far the scaling capabilities of > the broker, but I haven't had any experiences yet with FJ pool to know which > impact it should have on the code: did you have any? what do you think about > that? > Any experience, idea on how to apply it and feedback would be > super-appreciated :) > > Cheers, > Franz > > > > > > -- > Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html
