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
>
