camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bilgin Ibryam <bibr...@gmail.com>
Subject Re: New camel-hystrix component
Date Fri, 29 Jan 2016 14:09:30 GMT
Thanks Raul, I will go further and merge my implementation to master.
Before that I will see what ideas I can take from your branch.
Going forward, we may have to consdier what new versions of Java is
bringing to the table for Camel Java DSL in general anyway.

Cheers,


On 28 January 2016 at 14:12, Raul Kripalani <raulk@apache.org> wrote:
> Hey Bilgin,
>
> I agree with you. My implementation started as a experiment, to be honest.
>
> My vision was deep and fluent integration between Camel and Hystrix, that's
> why I started experimenting with a fluent DSL. To me, Hystrix is not just
> an external thing to integrate in Camel, but it should play a larger role
> in changing how Camel fundamentally deals with exceptions in endpoints,
> processors and routing.
>
> However, I do agree that ultimately we would need to offer URI
> configuration (especially for Spring/Blueprint DSL users) before merging
> the component into master. But I wanted to get the enginery working first
> and the right level of fluency, to then add the URI logic because the
> latter is simpler. The "hardcore" part is actually supporting all of the
> magic that Hystrix offers.
>
> I agree that my implementation may be more complex to use in some
> scenarios. But I was focusing on not having to register objects in the
> Registry, because I particularly hate that amount of indirection ;-) Having
> to register endpoints and processors in the Registry just to be able to use
> them from the Hystrix endpoint seems a bit too much, and I wanted to
> achieve this level of fluency with JDK8:
>
>          hystrix.wrapper()
>                 .forProcessor((exchange) -> throw new
> DummyException("Bang!")), setter)
>                 .withFallbackProcessor((exchange) ->
> exchange.getOut().setBody("Sorry, something happened"))
>                 .suppressFallbackForExceptions(DummyException.class)
>                 .build();
>
> Or to be able to specify endpoint URIs inline, rather than having to
> register them in the registry to then reference them via # pound notation:
>
>           hystrix.wrapper()
>                 .forStaticEndpoint("http://google.com", setter)
>                 .withFallbackProcessor((exchange) ->
> exchange.getOut().setBody("Could not reach Google. Is it the end of the
> world?"))
>                 .build();
>
> Setters should be optional, BTW. And we should offer convenience methods to
> set typical Setter parameters (command name, group key, etc.). And I think
> my starting of services in Processors in a test was actually redundant.
>
> If you are actively working on the Hystrix component, go ahead! I can then
> enhance your implementation with a DSL, and you can take stuff from my
> implementation so far. The point where I got stuck was bridging Archaius
> (Hystrix configuration library) with our Camel Property Placeholders,
> Spring and Blueprint. Ideally Hystrix commands would be able to configure
> themselves by introspecting our existing properties in the context... :-(
>
> WDYT?
>
> Regards,
>
> *Raúl Kripalani*
> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
> Messaging Engineer
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> Blog: raul.io | twitter: @raulvk <https://twitter.com/raulvk>
>
> On Thu, Jan 28, 2016 at 1:43 PM, Bilgin Ibryam <bibryam@gmail.com> wrote:
>
>> Hi Raul,
>>
>> More or less the same time you published the first email about
>> camel-hystrix component, I also created camel-hystrix component [1]
>> (it is not finished yet!). But I took the typical (boring ;-))
>> approach where the hystix support can be used as a regular component
>> through URI configuration. Since you announced first and started the
>> effort more visibly on jira/git/list I decided not to duplicate effort
>> and wait for your progress.
>>
>> Now looking at your implementation, I see it is quite advance and
>> offers many intersting features, great work. But my concernds are
>> primarily around using the fluent API rather than Camel URIs. In my
>> opinion Camel URI is a nice abstraction and using it should be default
>> option for any component. It makes easy for existing Camel users to
>> strat using a component.
>> Also not sure how the fluent API can be used from XML based DSL, may
>> be I'm missing something.
>>
>> IMHO, your implementation is more advanced, but also more complicated
>> to use. Using a builder, then setting some Histryx specific objects (I
>> think it was the HystrixObservableCommand.Setter), starting services
>> manually, seems too much work to me. I believe all that can be
>> expressed through a regular component.
>>
>> Not sure way would be the better approach going forward. May be we can
>> merge both approaches and offer the regular URI based component usage
>> and also the additional fluent API.
>>
>> WDYT?
>>
>>
>> [1] https://github.com/bibryam/camel-hystrix
>>
>> Bilgin
>>
>>
>> On 25 August 2015 at 02:13, Raul Kripalani <raul@evosent.com> wrote:
>> > Hi team,
>> >
>> > Hystrix [1] is a powerful toolbox framework based on RxJava for building
>> > JVM-based fault-tolerant distributed systems, made OSS by Netflix.
>> >
>> > Due to the nature of Camel, our users inherently deal with distributed
>> > systems and therefore I thought integrating this framework into Camel
>> would
>> > be useful.
>> >
>> > I wanted to go beyond the typical (boring ;-)) URI-based component.
>> Hystrix
>> > has lots of features, some of which can take predicates (which in our
>> world
>> > translate to Processors and Expressions), so a fluent DSL is especially
>> > appealing here.
>> >
>> > I'm doing this work in the feature/camel-hystrix branch at the ASF Git
>> [2].
>> > I created a ticket with my functionality roadmap [3], and ticked out what
>> > has already been implemented.
>> >
>> > I foresee some difficulty with integrating Archaius (Netflix' config
>> > framework) with our Camel property placeholders and OSGi Config Admin.
>> I'd
>> > also like to achieve Turbine integration to enable the awesome Hystrix
>> > dashboard across clusters [4].
>> >
>> > If you have ideas, feel free to post them. If you have spare cycles, feel
>> > free to contact me if you'd like to participate in the development so we
>> > can coordinate.
>> >
>> > [1] https://github.com/Netflix/Hystrix
>> > [2] https://github.com/apache/camel/tree/feature/camel-hystrix
>> > [3] https://issues.apache.org/jira/browse/CAMEL-9098
>> > [4] https://github.com/Netflix/Hystrix/tree/master/hystrix-dashboard
>> >
>> > Regards,
>> >
>> > *Raúl Kripalani*
>> > Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
>> > Integration specialist
>> > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
>> > http://blog.raulkr.net | twitter: @raulvk
>>
>>
>>
>> --
>> Bilgin Ibryam
>> Camel Committer at ASF & Integration Architect at Red Hat
>> Blog: http://ofbizian.com | Twitter: @bibryam
>>
>> Camel Design Patterns https://leanpub.com/camel-design-patterns
>> Instant Apache Camel Message Routing http://www.amazon.com/dp/1783283475
>>



-- 
Bilgin Ibryam
Camel Committer at ASF & Integration Architect at Red Hat
Blog: http://ofbizian.com | Twitter: @bibryam

Camel Design Patterns https://leanpub.com/camel-design-patterns
Instant Apache Camel Message Routing http://www.amazon.com/dp/1783283475

Mime
View raw message