camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Pavlovich <mattr...@gmail.com>
Subject Re: [DISCUSS] - Thoughts on Apache Camel 2.18 and towards 3.0
Date Mon, 04 Apr 2016 16:59:54 GMT
Johan-

I'm a big fan of long winded statements as well, but not following this 
one =)

Are you suggesting the current core architecture is problematic or that 
a conversion to something like reactive would result in "strange" bugs?

Thanks,
Matt

On 4/4/16 10:52 AM, Johan Edstrom wrote:
> I think the core should focus on speed, consistency, reliability
> and last extensibility; Camel has a nice traction but we don’t
> want to see “strange” bugs from new features if that makes
> sense as a long windy sentence…..
>
>
>
>> On Apr 4, 2016, at 9:36 AM, Matt Pavlovich <mattrpav@gmail.com> wrote:
>>
>>
>>
>> On 3/24/16 3:27 PM, Raul Kripalani wrote:
>>> On Thu, Mar 24, 2016 at 5:24 PM, Krzysztof Sobkowiak <
>>> krzys.sobkowiak@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


Mime
View raw message