+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 

The bits I could think of most is the actor model recently. 


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

Reply via email to