Hi
Good to hear that you guys will pickup this and work on a
camel-hystrix component.
I agree with Bilgin that the component should be similar to how you
use all the other components using the endpoints and how they are
configured.
PS: Another cool component would be a Apache Storm component.
On Thu, Jan 28, 2016 at 3:12 PM, Raul Kripalani <ra...@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 <bibr...@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 <r...@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
>>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
