On 3/24/16 3:27 PM, Raul Kripalani wrote:
On Thu, Mar 24, 2016 at 5:24 PM, Krzysztof Sobkowiak <
krzys.sobkow...@gmail.com> wrote:
I think, the way to Camel 3 should also include the renovation of the Core
(if really necessary) or even rewriting and
making it more asynchronous, e.g. using rx.java (the later can be
eventually part of Camel 4 roadmap if too dangerous
for Camel 3).
This also relates to the concurrency model. Camel revolves around the idea
that more threads == more performance. Our processing actually
hijacks/piggy-backs the threads of the 3rd party library of the component
(Netty, Jetty, Spring JMS, etc. threads), and this is not good. One just
needs to look around: reactive programming, coroutines, event loops,
generators, goroutines (in Go), etc. to realise we're kinda obsolete by now.
"Obsolete" by what standard?
The async routing engine was a step in the right direction, but most
components don't even support it.
Now that we know the reactive programming model is here to stay and it
wasn't a fad, I feel we should definitely go in that direction. We should
look at Akka, RxJava and the Reactive Streams [3] spec.
I expect there will be long term valuable pieces pulled from reactive
programming, just as there are from virtually every new "paradigm" that
pops up every few years-- but there will also be a balance of "doesn't
meet the hype". Anyone remember AOP (Btw-- which now has 3-4
sub-derivatives)? I suggest letting the dust settle to see what the
benefits-tradeoffs matrix looks like before committing to overhauling
Camel core.
-Matt
