FYI, I've pushed the camel-hystrix component to master. Currently it doesn't support request collapsing and the threading aspects needs more testing and possibly improving.
Here is a small example how the new component can be used: https://github.com/bibryam/camel-hystrix-demo/blob/master/src/main/resources/OSGI-INF/blueprint/hystrix-producer.xml Cheers, On 29 January 2016 at 14:09, Bilgin Ibryam <bibr...@gmail.com> wrote: > 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 <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 >>> > > > > -- > 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
