You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Bilgin Ibryam <bi...@gmail.com> on 2016/04/04 15:45:49 UTC
Re: New camel-hystrix component
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 <bi...@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 <bi...@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 <ra...@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
Re: New camel-hystrix component
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Apr 4, 2016 at 6:22 PM, Raul Kripalani <ra...@apache.org> wrote:
> That was my exact same thought when I took a stab at the camel-hystrix
> component myself:
> https://github.com/apache/camel/commits/feature/camel-hystrix.
>
> For me, Hystrix is not an endpoint but a mechanism to deal with failure, no
> matter if thrown by an endpoint, a processor, or any other element of a
> route.
>
> For Java DSL, I proposed something like:
>
> HystrixComponent hystrix = context.getComponent("hystrix",
> HystrixComponent.class);
>
> from("activemq:queue:abc)
> .to(hystrix.wrapper()
> .forStaticEndpoint("http4://localhost:8080/...", setter)
> .withFallbackProcessor((exchange) ->
> exchange.getIn().setBody("failure!"))
> .withCacheKey(ExpressionBuilder.bodyExpression())
> .suppressFallbackForExceptions(DummyException.class)
> .build());
>
>
> For XML, we could create a DSL too but it would live in the camel-core
> module with a runtime dependency on camel-hystrix and transitives (e.g.
> like we do today with the data formats <xstream/>, expression languages
> <ognl/>, etc.).
>
> I got stuck with my camel-hystrix component at the stage of integrating
> Archaius with the Spring and Blueprint property placeholders.
>
There is already the circuit breaker as a load balancer. It makes more
sense for me to improve on that to offer a way to configure a fallback
processor / endpoint / child route etc.
Or if the load balancer starts to mis-fit then move it out as a
standalone eip. I suspect this is more the case, and do not mind doing
this.
For the actual implementation if people want to use hystrix we can
make it load it if you add camel-hystrix as a dependency. As you say
we can do with data formats. Or recently with camel-java-swagger.
hystrix is not the only CB implementation. vert.x has a implementation
out of the box as well.
And you can say the current implementation in camel-core is also an
implementation.
> Cheers,
>
> *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
> <http://raul.io/?utm_source=email&utm_medium=email&utm_campaign=apache> |
> twitter: @raulvk <https://twitter.com/raulvk>
>
> On Mon, Apr 4, 2016 at 5:07 PM, Preben.Asmussen <pr...@dr.dk> wrote:
>
>> Hi bibryam
>>
>> At first glance it looks a bit intrusive when the usual endpoints are
>> 'wrapped' in the hystrix endpoint.
>>
>> Could it be something like -> psudo code
>>
>> <camelContext id="hystrix-producer"
>> xmlns="http://camel.apache.org/schema/blueprint">
>> <hystrix>
>> <from="run"/>
>> <fallback="http4://www.google.com"/>
>> .............. other options
>> </hystrix>
>>
>> <route>
>> <from
>> uri="timer://local?fixedRate=true&period=50&repeatCount=5"/>
>>
>>
>> <to id="run" uri="http4://localhost"/>
>>
>> <to uri="log:hystrix?level=INFO&showHeaders=true"/>
>> </route>
>> </camelContext>
>>
>> /Preben
>>
>>
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/New-camel-hystrix-component-tp5770955p5780454.html
>> Sent from the Camel Development mailing list archive at Nabble.com.
>>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: New camel-hystrix component
Posted by "Preben.Asmussen" <pr...@dr.dk>.
:-)
Maybe the xml dsl could have it's own namespace like cxf.
Then you can import it and declare the hystrix stuff outside of the camel
context.
Wouldn't this solve having hystrix dependencies in camel core.
Cheers
--
View this message in context: http://camel.465427.n5.nabble.com/New-camel-hystrix-component-tp5770955p5780460.html
Sent from the Camel Development mailing list archive at Nabble.com.
Re: New camel-hystrix component
Posted by Raul Kripalani <ra...@apache.org>.
That was my exact same thought when I took a stab at the camel-hystrix
component myself:
https://github.com/apache/camel/commits/feature/camel-hystrix.
For me, Hystrix is not an endpoint but a mechanism to deal with failure, no
matter if thrown by an endpoint, a processor, or any other element of a
route.
For Java DSL, I proposed something like:
HystrixComponent hystrix = context.getComponent("hystrix",
HystrixComponent.class);
from("activemq:queue:abc)
.to(hystrix.wrapper()
.forStaticEndpoint("http4://localhost:8080/...", setter)
.withFallbackProcessor((exchange) ->
exchange.getIn().setBody("failure!"))
.withCacheKey(ExpressionBuilder.bodyExpression())
.suppressFallbackForExceptions(DummyException.class)
.build());
For XML, we could create a DSL too but it would live in the camel-core
module with a runtime dependency on camel-hystrix and transitives (e.g.
like we do today with the data formats <xstream/>, expression languages
<ognl/>, etc.).
I got stuck with my camel-hystrix component at the stage of integrating
Archaius with the Spring and Blueprint property placeholders.
Cheers,
*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
<http://raul.io/?utm_source=email&utm_medium=email&utm_campaign=apache> |
twitter: @raulvk <https://twitter.com/raulvk>
On Mon, Apr 4, 2016 at 5:07 PM, Preben.Asmussen <pr...@dr.dk> wrote:
> Hi bibryam
>
> At first glance it looks a bit intrusive when the usual endpoints are
> 'wrapped' in the hystrix endpoint.
>
> Could it be something like -> psudo code
>
> <camelContext id="hystrix-producer"
> xmlns="http://camel.apache.org/schema/blueprint">
> <hystrix>
> <from="run"/>
> <fallback="http4://www.google.com"/>
> .............. other options
> </hystrix>
>
> <route>
> <from
> uri="timer://local?fixedRate=true&period=50&repeatCount=5"/>
>
>
> <to id="run" uri="http4://localhost"/>
>
> <to uri="log:hystrix?level=INFO&showHeaders=true"/>
> </route>
> </camelContext>
>
> /Preben
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/New-camel-hystrix-component-tp5770955p5780454.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>
Re: New camel-hystrix component
Posted by Bilgin Ibryam <bi...@gmail.com>.
It was quite hard for me to get confluence styling right/cleaned up.
On 14 April 2016 at 12:46, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> Okay so the good thing is that the cache is only in use if you specify
> a cacheKey, so people can then easily turn on the cache by providing a
> key.
>
> I am adding component docs for the options that lacks those.
>
>
>
> On Thu, Apr 14, 2016 at 11:57 AM, Bilgin Ibryam <bi...@gmail.com> wrote:
>> All changes sounds good to me. I'd like it have default behaviour that
>> is expected by a Camel developer... like no caching and all the rest.
>>
>> On 14 April 2016 at 10:06, Claus Ibsen <cl...@gmail.com> wrote:
>>> Hi
>>>
>>> Okay done some improvements.
>>>
>>> I wonder if the caching should not be disabled by default. Its a bit
>>> annoying to have to specify a cache key for de-dups, if you are really
>>> not using that. I am not sure I would like that enabled by default,
>>> so I would have to disable it all the time.
>>>
>>> Also I think the cacheKey should be a simple expression by default, so
>>> you can just type
>>>
>>> cacheKey=header:foo
>>>
>>> or with the ${ } to make it stand out
>>>
>>> cacheKey=${header:foo}
>>>
>>> And if you want to refer to an expression then you can use
>>>
>>> cacheKey=#myKey
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Apr 14, 2016 at 10:08 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>>> On Sun, Apr 10, 2016 at 3:41 PM, Claus Ibsen <cl...@gmail.com> wrote:
>>>>> Hi
>>>>>
>>>>> Maybe the endpoint can be specified as both id an uri.
>>>>> Then if you want to refer to an existing by id as it does today, you
>>>>> just use ref:
>>>>>
>>>>> runEndpoint=ref:foo
>>>>> runEndpoint=direct:foo
>>>>>
>>>>> This also allows to route to seda / jms etc.
>>>>>
>>>>> runEndpoint=seda:bar
>>>>> runEndpoint=jms:queue:numbers
>>>>>
>>>>> Though if you need to configure the endpoints then you would need to
>>>>> setup the endpoint first and then refer to it by id.
>>>>>
>>>>
>>>> I am working on this and a few other improvements so we create the
>>>> produce once and reuse it as well the resources are shutdown when
>>>> being stopped etc.
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Apr 10, 2016 at 1:03 PM, Bilgin Ibryam <bi...@gmail.com> wrote:
>>>>>> While implementing the hystrix component, I had to choose whether to
>>>>>> use endpoint Ids or direct component for run/faillback endpoints.
>>>>>>
>>>>>> I've chosen endpoints, as it allows defining any kind of endpoints
>>>>>> with all the options and then refer to it by its id. The downside is
>>>>>> that you have to add the endpoint to the registry.
>>>>>>
>>>>>> I think adding also the direct compoent for referring to run/fallback
>>>>>> routes would simplify the use of this component. Something like this:
>>>>>>
>>>>>> public void configure() {
>>>>>>
>>>>>> from("direct:fallback")
>>>>>> .to("mock:error");
>>>>>>
>>>>>> from("direct:run")
>>>>>> .to("mock:result");
>>>>>>
>>>>>> from("direct:start")
>>>>>> .to("hystrix:testKey?runDirectName=run&fallbackName=fallback");
>>>>>>
>>>>>> }
>>>>>>
>>>>>> The advantage is that there is no need of an endpointID and and more
>>>>>> importantly for adding the endpoint to the registry. The downside is
>>>>>> that you have to have a separate route that is using the direct
>>>>>> consume.
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 10 April 2016 at 11:19, Bilgin Ibryam <bi...@gmail.com> wrote:
>>>>>>> Hi chaps,
>>>>>>>
>>>>>>> I'm also not very happy with the way endpointId are part of the
>>>>>>> hystrix URL but that was the only non-intrusive way I manged to
>>>>>>> implement it atm. Keep in mind that we want both Java and XML dsl
>>>>>>> solution. So if you have any ideas to make it easier to use, feel free
>>>>>>> to work on it. I won't have bandwidth to improve it further in near
>>>>>>> future.
>>>>>>>
>>>>>>> The previous time when I implemented the circuit breaker, the most
>>>>>>> appropriate location I found end up being the load balancer. It did
>>>>>>> nicely fit there, bit I think it is still not natural to say that CB
>>>>>>> is a LB strategy.
>>>>>>>
>>>>>>> This time I decided to use a component as I think hystrix is only one
>>>>>>> implementation of CB.
>>>>>>>
>>>>>>> In addition, hystrix does not implement only CB, but more and more
>>>>>>> things, which I find confusing. It does bulkheading (which is fine),
>>>>>>> but also request collapsing, and also caching.
>>>>>>> For something like request collapsing, the more natural way would be
>>>>>>> to have aggregator in Camel, and for the caching it would be better if
>>>>>>> we had caching DSL with various implementations (very importantly:
>>>>>>> distributed cache).
>>>>>>>
>>>>>>> I think for CB we need a new EIP, and not LB and a component. Hystrix
>>>>>>> can be an implementation of the EIP. And it might be better if the
>>>>>>> caching, request collapsing concepts are not mixed with the CB EIP.
>>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 6 April 2016 at 07:43, Claus Ibsen <cl...@gmail.com> wrote:
>>>>>>>> There is some pros with being an endpoint configuration only, as it
>>>>>>>> can make it easy for tooling and some developers to use it (when they
>>>>>>>> are used to configure uris, and just use from -> to -> to etc). I
>>>>>>>> guess the bit unusual part is that you refer to endpoint by id's which
>>>>>>>> is not so commonly in use by Camel.
>>>>>>>>
>>>>>>>> You could also have CB as a kind of error handler, aka onException,
>>>>>>>> but have it as onCircuitBreaker, where you can setup those breaker
>>>>>>>> configs and fallback routes / endpoint etc. And whether to use a
>>>>>>>> fallback or reject or whatnot.
>>>>>>>>
>>>>>>>> Just a quick pseudo code / braindump
>>>>>>>>
>>>>>>>> <onCurcuitBreaker threshold="2" halfOpenAfter="1000">
>>>>>>>> <exception>IOException</exception>
>>>>>>>> <to uri="bean:fallbackStuff"/>
>>>>>>>> </onCurcuitBreaker>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Apr 4, 2016 at 6:07 PM, Preben.Asmussen <pr...@dr.dk> wrote:
>>>>>>>>> Hi bibryam
>>>>>>>>>
>>>>>>>>> At first glance it looks a bit intrusive when the usual endpoints are
>>>>>>>>> 'wrapped' in the hystrix endpoint.
>>>>>>>>>
>>>>>>>>> Could it be something like -> psudo code
>>>>>>>>>
>>>>>>>>> <camelContext id="hystrix-producer"
>>>>>>>>> xmlns="http://camel.apache.org/schema/blueprint">
>>>>>>>>> <hystrix>
>>>>>>>>> <from="run"/>
>>>>>>>>> <fallback="http4://www.google.com"/>
>>>>>>>>> .............. other options
>>>>>>>>> </hystrix>
>>>>>>>>>
>>>>>>>>> <route>
>>>>>>>>> <from
>>>>>>>>> uri="timer://local?fixedRate=true&period=50&repeatCount=5"/>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <to id="run" uri="http4://localhost"/>
>>>>>>>>>
>>>>>>>>> <to uri="log:hystrix?level=INFO&showHeaders=true"/>
>>>>>>>>> </route>
>>>>>>>>> </camelContext>
>>>>>>>>>
>>>>>>>>> /Preben
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> View this message in context: http://camel.465427.n5.nabble.com/New-camel-hystrix-component-tp5770955p5780454.html
>>>>>>>>> Sent from the Camel Development mailing list archive at Nabble.com.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Claus Ibsen
>>>>>>>> -----------------
>>>>>>>> http://davsclaus.com @davsclaus
>>>>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Claus Ibsen
>>>>> -----------------
>>>>> http://davsclaus.com @davsclaus
>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>>
>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> -----------------
>>>> http://davsclaus.com @davsclaus
>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
>>
>>
>>
>> --
>> 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
--
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
Re: New camel-hystrix component
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Okay so the good thing is that the cache is only in use if you specify
a cacheKey, so people can then easily turn on the cache by providing a
key.
I am adding component docs for the options that lacks those.
On Thu, Apr 14, 2016 at 11:57 AM, Bilgin Ibryam <bi...@gmail.com> wrote:
> All changes sounds good to me. I'd like it have default behaviour that
> is expected by a Camel developer... like no caching and all the rest.
>
> On 14 April 2016 at 10:06, Claus Ibsen <cl...@gmail.com> wrote:
>> Hi
>>
>> Okay done some improvements.
>>
>> I wonder if the caching should not be disabled by default. Its a bit
>> annoying to have to specify a cache key for de-dups, if you are really
>> not using that. I am not sure I would like that enabled by default,
>> so I would have to disable it all the time.
>>
>> Also I think the cacheKey should be a simple expression by default, so
>> you can just type
>>
>> cacheKey=header:foo
>>
>> or with the ${ } to make it stand out
>>
>> cacheKey=${header:foo}
>>
>> And if you want to refer to an expression then you can use
>>
>> cacheKey=#myKey
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Apr 14, 2016 at 10:08 AM, Claus Ibsen <cl...@gmail.com> wrote:
>>> On Sun, Apr 10, 2016 at 3:41 PM, Claus Ibsen <cl...@gmail.com> wrote:
>>>> Hi
>>>>
>>>> Maybe the endpoint can be specified as both id an uri.
>>>> Then if you want to refer to an existing by id as it does today, you
>>>> just use ref:
>>>>
>>>> runEndpoint=ref:foo
>>>> runEndpoint=direct:foo
>>>>
>>>> This also allows to route to seda / jms etc.
>>>>
>>>> runEndpoint=seda:bar
>>>> runEndpoint=jms:queue:numbers
>>>>
>>>> Though if you need to configure the endpoints then you would need to
>>>> setup the endpoint first and then refer to it by id.
>>>>
>>>
>>> I am working on this and a few other improvements so we create the
>>> produce once and reuse it as well the resources are shutdown when
>>> being stopped etc.
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, Apr 10, 2016 at 1:03 PM, Bilgin Ibryam <bi...@gmail.com> wrote:
>>>>> While implementing the hystrix component, I had to choose whether to
>>>>> use endpoint Ids or direct component for run/faillback endpoints.
>>>>>
>>>>> I've chosen endpoints, as it allows defining any kind of endpoints
>>>>> with all the options and then refer to it by its id. The downside is
>>>>> that you have to add the endpoint to the registry.
>>>>>
>>>>> I think adding also the direct compoent for referring to run/fallback
>>>>> routes would simplify the use of this component. Something like this:
>>>>>
>>>>> public void configure() {
>>>>>
>>>>> from("direct:fallback")
>>>>> .to("mock:error");
>>>>>
>>>>> from("direct:run")
>>>>> .to("mock:result");
>>>>>
>>>>> from("direct:start")
>>>>> .to("hystrix:testKey?runDirectName=run&fallbackName=fallback");
>>>>>
>>>>> }
>>>>>
>>>>> The advantage is that there is no need of an endpointID and and more
>>>>> importantly for adding the endpoint to the registry. The downside is
>>>>> that you have to have a separate route that is using the direct
>>>>> consume.
>>>>>
>>>>> WDYT?
>>>>>
>>>>>
>>>>>
>>>>> On 10 April 2016 at 11:19, Bilgin Ibryam <bi...@gmail.com> wrote:
>>>>>> Hi chaps,
>>>>>>
>>>>>> I'm also not very happy with the way endpointId are part of the
>>>>>> hystrix URL but that was the only non-intrusive way I manged to
>>>>>> implement it atm. Keep in mind that we want both Java and XML dsl
>>>>>> solution. So if you have any ideas to make it easier to use, feel free
>>>>>> to work on it. I won't have bandwidth to improve it further in near
>>>>>> future.
>>>>>>
>>>>>> The previous time when I implemented the circuit breaker, the most
>>>>>> appropriate location I found end up being the load balancer. It did
>>>>>> nicely fit there, bit I think it is still not natural to say that CB
>>>>>> is a LB strategy.
>>>>>>
>>>>>> This time I decided to use a component as I think hystrix is only one
>>>>>> implementation of CB.
>>>>>>
>>>>>> In addition, hystrix does not implement only CB, but more and more
>>>>>> things, which I find confusing. It does bulkheading (which is fine),
>>>>>> but also request collapsing, and also caching.
>>>>>> For something like request collapsing, the more natural way would be
>>>>>> to have aggregator in Camel, and for the caching it would be better if
>>>>>> we had caching DSL with various implementations (very importantly:
>>>>>> distributed cache).
>>>>>>
>>>>>> I think for CB we need a new EIP, and not LB and a component. Hystrix
>>>>>> can be an implementation of the EIP. And it might be better if the
>>>>>> caching, request collapsing concepts are not mixed with the CB EIP.
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 6 April 2016 at 07:43, Claus Ibsen <cl...@gmail.com> wrote:
>>>>>>> There is some pros with being an endpoint configuration only, as it
>>>>>>> can make it easy for tooling and some developers to use it (when they
>>>>>>> are used to configure uris, and just use from -> to -> to etc). I
>>>>>>> guess the bit unusual part is that you refer to endpoint by id's which
>>>>>>> is not so commonly in use by Camel.
>>>>>>>
>>>>>>> You could also have CB as a kind of error handler, aka onException,
>>>>>>> but have it as onCircuitBreaker, where you can setup those breaker
>>>>>>> configs and fallback routes / endpoint etc. And whether to use a
>>>>>>> fallback or reject or whatnot.
>>>>>>>
>>>>>>> Just a quick pseudo code / braindump
>>>>>>>
>>>>>>> <onCurcuitBreaker threshold="2" halfOpenAfter="1000">
>>>>>>> <exception>IOException</exception>
>>>>>>> <to uri="bean:fallbackStuff"/>
>>>>>>> </onCurcuitBreaker>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Apr 4, 2016 at 6:07 PM, Preben.Asmussen <pr...@dr.dk> wrote:
>>>>>>>> Hi bibryam
>>>>>>>>
>>>>>>>> At first glance it looks a bit intrusive when the usual endpoints are
>>>>>>>> 'wrapped' in the hystrix endpoint.
>>>>>>>>
>>>>>>>> Could it be something like -> psudo code
>>>>>>>>
>>>>>>>> <camelContext id="hystrix-producer"
>>>>>>>> xmlns="http://camel.apache.org/schema/blueprint">
>>>>>>>> <hystrix>
>>>>>>>> <from="run"/>
>>>>>>>> <fallback="http4://www.google.com"/>
>>>>>>>> .............. other options
>>>>>>>> </hystrix>
>>>>>>>>
>>>>>>>> <route>
>>>>>>>> <from
>>>>>>>> uri="timer://local?fixedRate=true&period=50&repeatCount=5"/>
>>>>>>>>
>>>>>>>>
>>>>>>>> <to id="run" uri="http4://localhost"/>
>>>>>>>>
>>>>>>>> <to uri="log:hystrix?level=INFO&showHeaders=true"/>
>>>>>>>> </route>
>>>>>>>> </camelContext>
>>>>>>>>
>>>>>>>> /Preben
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> View this message in context: http://camel.465427.n5.nabble.com/New-camel-hystrix-component-tp5770955p5780454.html
>>>>>>>> Sent from the Camel Development mailing list archive at Nabble.com.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Claus Ibsen
>>>>>>> -----------------
>>>>>>> http://davsclaus.com @davsclaus
>>>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>
>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> -----------------
>>>> http://davsclaus.com @davsclaus
>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>
>
>
> --
> 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
Re: New camel-hystrix component
Posted by Bilgin Ibryam <bi...@gmail.com>.
All changes sounds good to me. I'd like it have default behaviour that
is expected by a Camel developer... like no caching and all the rest.
On 14 April 2016 at 10:06, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> Okay done some improvements.
>
> I wonder if the caching should not be disabled by default. Its a bit
> annoying to have to specify a cache key for de-dups, if you are really
> not using that. I am not sure I would like that enabled by default,
> so I would have to disable it all the time.
>
> Also I think the cacheKey should be a simple expression by default, so
> you can just type
>
> cacheKey=header:foo
>
> or with the ${ } to make it stand out
>
> cacheKey=${header:foo}
>
> And if you want to refer to an expression then you can use
>
> cacheKey=#myKey
>
>
>
>
>
>
>
>
>
> On Thu, Apr 14, 2016 at 10:08 AM, Claus Ibsen <cl...@gmail.com> wrote:
>> On Sun, Apr 10, 2016 at 3:41 PM, Claus Ibsen <cl...@gmail.com> wrote:
>>> Hi
>>>
>>> Maybe the endpoint can be specified as both id an uri.
>>> Then if you want to refer to an existing by id as it does today, you
>>> just use ref:
>>>
>>> runEndpoint=ref:foo
>>> runEndpoint=direct:foo
>>>
>>> This also allows to route to seda / jms etc.
>>>
>>> runEndpoint=seda:bar
>>> runEndpoint=jms:queue:numbers
>>>
>>> Though if you need to configure the endpoints then you would need to
>>> setup the endpoint first and then refer to it by id.
>>>
>>
>> I am working on this and a few other improvements so we create the
>> produce once and reuse it as well the resources are shutdown when
>> being stopped etc.
>>
>>>
>>>
>>>
>>>
>>>
>>> On Sun, Apr 10, 2016 at 1:03 PM, Bilgin Ibryam <bi...@gmail.com> wrote:
>>>> While implementing the hystrix component, I had to choose whether to
>>>> use endpoint Ids or direct component for run/faillback endpoints.
>>>>
>>>> I've chosen endpoints, as it allows defining any kind of endpoints
>>>> with all the options and then refer to it by its id. The downside is
>>>> that you have to add the endpoint to the registry.
>>>>
>>>> I think adding also the direct compoent for referring to run/fallback
>>>> routes would simplify the use of this component. Something like this:
>>>>
>>>> public void configure() {
>>>>
>>>> from("direct:fallback")
>>>> .to("mock:error");
>>>>
>>>> from("direct:run")
>>>> .to("mock:result");
>>>>
>>>> from("direct:start")
>>>> .to("hystrix:testKey?runDirectName=run&fallbackName=fallback");
>>>>
>>>> }
>>>>
>>>> The advantage is that there is no need of an endpointID and and more
>>>> importantly for adding the endpoint to the registry. The downside is
>>>> that you have to have a separate route that is using the direct
>>>> consume.
>>>>
>>>> WDYT?
>>>>
>>>>
>>>>
>>>> On 10 April 2016 at 11:19, Bilgin Ibryam <bi...@gmail.com> wrote:
>>>>> Hi chaps,
>>>>>
>>>>> I'm also not very happy with the way endpointId are part of the
>>>>> hystrix URL but that was the only non-intrusive way I manged to
>>>>> implement it atm. Keep in mind that we want both Java and XML dsl
>>>>> solution. So if you have any ideas to make it easier to use, feel free
>>>>> to work on it. I won't have bandwidth to improve it further in near
>>>>> future.
>>>>>
>>>>> The previous time when I implemented the circuit breaker, the most
>>>>> appropriate location I found end up being the load balancer. It did
>>>>> nicely fit there, bit I think it is still not natural to say that CB
>>>>> is a LB strategy.
>>>>>
>>>>> This time I decided to use a component as I think hystrix is only one
>>>>> implementation of CB.
>>>>>
>>>>> In addition, hystrix does not implement only CB, but more and more
>>>>> things, which I find confusing. It does bulkheading (which is fine),
>>>>> but also request collapsing, and also caching.
>>>>> For something like request collapsing, the more natural way would be
>>>>> to have aggregator in Camel, and for the caching it would be better if
>>>>> we had caching DSL with various implementations (very importantly:
>>>>> distributed cache).
>>>>>
>>>>> I think for CB we need a new EIP, and not LB and a component. Hystrix
>>>>> can be an implementation of the EIP. And it might be better if the
>>>>> caching, request collapsing concepts are not mixed with the CB EIP.
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 6 April 2016 at 07:43, Claus Ibsen <cl...@gmail.com> wrote:
>>>>>> There is some pros with being an endpoint configuration only, as it
>>>>>> can make it easy for tooling and some developers to use it (when they
>>>>>> are used to configure uris, and just use from -> to -> to etc). I
>>>>>> guess the bit unusual part is that you refer to endpoint by id's which
>>>>>> is not so commonly in use by Camel.
>>>>>>
>>>>>> You could also have CB as a kind of error handler, aka onException,
>>>>>> but have it as onCircuitBreaker, where you can setup those breaker
>>>>>> configs and fallback routes / endpoint etc. And whether to use a
>>>>>> fallback or reject or whatnot.
>>>>>>
>>>>>> Just a quick pseudo code / braindump
>>>>>>
>>>>>> <onCurcuitBreaker threshold="2" halfOpenAfter="1000">
>>>>>> <exception>IOException</exception>
>>>>>> <to uri="bean:fallbackStuff"/>
>>>>>> </onCurcuitBreaker>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 4, 2016 at 6:07 PM, Preben.Asmussen <pr...@dr.dk> wrote:
>>>>>>> Hi bibryam
>>>>>>>
>>>>>>> At first glance it looks a bit intrusive when the usual endpoints are
>>>>>>> 'wrapped' in the hystrix endpoint.
>>>>>>>
>>>>>>> Could it be something like -> psudo code
>>>>>>>
>>>>>>> <camelContext id="hystrix-producer"
>>>>>>> xmlns="http://camel.apache.org/schema/blueprint">
>>>>>>> <hystrix>
>>>>>>> <from="run"/>
>>>>>>> <fallback="http4://www.google.com"/>
>>>>>>> .............. other options
>>>>>>> </hystrix>
>>>>>>>
>>>>>>> <route>
>>>>>>> <from
>>>>>>> uri="timer://local?fixedRate=true&period=50&repeatCount=5"/>
>>>>>>>
>>>>>>>
>>>>>>> <to id="run" uri="http4://localhost"/>
>>>>>>>
>>>>>>> <to uri="log:hystrix?level=INFO&showHeaders=true"/>
>>>>>>> </route>
>>>>>>> </camelContext>
>>>>>>>
>>>>>>> /Preben
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> View this message in context: http://camel.465427.n5.nabble.com/New-camel-hystrix-component-tp5770955p5780454.html
>>>>>>> Sent from the Camel Development mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Claus Ibsen
>>>>>> -----------------
>>>>>> http://davsclaus.com @davsclaus
>>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
--
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
Re: New camel-hystrix component
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Okay done some improvements.
I wonder if the caching should not be disabled by default. Its a bit
annoying to have to specify a cache key for de-dups, if you are really
not using that. I am not sure I would like that enabled by default,
so I would have to disable it all the time.
Also I think the cacheKey should be a simple expression by default, so
you can just type
cacheKey=header:foo
or with the ${ } to make it stand out
cacheKey=${header:foo}
And if you want to refer to an expression then you can use
cacheKey=#myKey
On Thu, Apr 14, 2016 at 10:08 AM, Claus Ibsen <cl...@gmail.com> wrote:
> On Sun, Apr 10, 2016 at 3:41 PM, Claus Ibsen <cl...@gmail.com> wrote:
>> Hi
>>
>> Maybe the endpoint can be specified as both id an uri.
>> Then if you want to refer to an existing by id as it does today, you
>> just use ref:
>>
>> runEndpoint=ref:foo
>> runEndpoint=direct:foo
>>
>> This also allows to route to seda / jms etc.
>>
>> runEndpoint=seda:bar
>> runEndpoint=jms:queue:numbers
>>
>> Though if you need to configure the endpoints then you would need to
>> setup the endpoint first and then refer to it by id.
>>
>
> I am working on this and a few other improvements so we create the
> produce once and reuse it as well the resources are shutdown when
> being stopped etc.
>
>>
>>
>>
>>
>>
>> On Sun, Apr 10, 2016 at 1:03 PM, Bilgin Ibryam <bi...@gmail.com> wrote:
>>> While implementing the hystrix component, I had to choose whether to
>>> use endpoint Ids or direct component for run/faillback endpoints.
>>>
>>> I've chosen endpoints, as it allows defining any kind of endpoints
>>> with all the options and then refer to it by its id. The downside is
>>> that you have to add the endpoint to the registry.
>>>
>>> I think adding also the direct compoent for referring to run/fallback
>>> routes would simplify the use of this component. Something like this:
>>>
>>> public void configure() {
>>>
>>> from("direct:fallback")
>>> .to("mock:error");
>>>
>>> from("direct:run")
>>> .to("mock:result");
>>>
>>> from("direct:start")
>>> .to("hystrix:testKey?runDirectName=run&fallbackName=fallback");
>>>
>>> }
>>>
>>> The advantage is that there is no need of an endpointID and and more
>>> importantly for adding the endpoint to the registry. The downside is
>>> that you have to have a separate route that is using the direct
>>> consume.
>>>
>>> WDYT?
>>>
>>>
>>>
>>> On 10 April 2016 at 11:19, Bilgin Ibryam <bi...@gmail.com> wrote:
>>>> Hi chaps,
>>>>
>>>> I'm also not very happy with the way endpointId are part of the
>>>> hystrix URL but that was the only non-intrusive way I manged to
>>>> implement it atm. Keep in mind that we want both Java and XML dsl
>>>> solution. So if you have any ideas to make it easier to use, feel free
>>>> to work on it. I won't have bandwidth to improve it further in near
>>>> future.
>>>>
>>>> The previous time when I implemented the circuit breaker, the most
>>>> appropriate location I found end up being the load balancer. It did
>>>> nicely fit there, bit I think it is still not natural to say that CB
>>>> is a LB strategy.
>>>>
>>>> This time I decided to use a component as I think hystrix is only one
>>>> implementation of CB.
>>>>
>>>> In addition, hystrix does not implement only CB, but more and more
>>>> things, which I find confusing. It does bulkheading (which is fine),
>>>> but also request collapsing, and also caching.
>>>> For something like request collapsing, the more natural way would be
>>>> to have aggregator in Camel, and for the caching it would be better if
>>>> we had caching DSL with various implementations (very importantly:
>>>> distributed cache).
>>>>
>>>> I think for CB we need a new EIP, and not LB and a component. Hystrix
>>>> can be an implementation of the EIP. And it might be better if the
>>>> caching, request collapsing concepts are not mixed with the CB EIP.
>>>>
>>>>
>>>> Cheers,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 6 April 2016 at 07:43, Claus Ibsen <cl...@gmail.com> wrote:
>>>>> There is some pros with being an endpoint configuration only, as it
>>>>> can make it easy for tooling and some developers to use it (when they
>>>>> are used to configure uris, and just use from -> to -> to etc). I
>>>>> guess the bit unusual part is that you refer to endpoint by id's which
>>>>> is not so commonly in use by Camel.
>>>>>
>>>>> You could also have CB as a kind of error handler, aka onException,
>>>>> but have it as onCircuitBreaker, where you can setup those breaker
>>>>> configs and fallback routes / endpoint etc. And whether to use a
>>>>> fallback or reject or whatnot.
>>>>>
>>>>> Just a quick pseudo code / braindump
>>>>>
>>>>> <onCurcuitBreaker threshold="2" halfOpenAfter="1000">
>>>>> <exception>IOException</exception>
>>>>> <to uri="bean:fallbackStuff"/>
>>>>> </onCurcuitBreaker>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Apr 4, 2016 at 6:07 PM, Preben.Asmussen <pr...@dr.dk> wrote:
>>>>>> Hi bibryam
>>>>>>
>>>>>> At first glance it looks a bit intrusive when the usual endpoints are
>>>>>> 'wrapped' in the hystrix endpoint.
>>>>>>
>>>>>> Could it be something like -> psudo code
>>>>>>
>>>>>> <camelContext id="hystrix-producer"
>>>>>> xmlns="http://camel.apache.org/schema/blueprint">
>>>>>> <hystrix>
>>>>>> <from="run"/>
>>>>>> <fallback="http4://www.google.com"/>
>>>>>> .............. other options
>>>>>> </hystrix>
>>>>>>
>>>>>> <route>
>>>>>> <from
>>>>>> uri="timer://local?fixedRate=true&period=50&repeatCount=5"/>
>>>>>>
>>>>>>
>>>>>> <to id="run" uri="http4://localhost"/>
>>>>>>
>>>>>> <to uri="log:hystrix?level=INFO&showHeaders=true"/>
>>>>>> </route>
>>>>>> </camelContext>
>>>>>>
>>>>>> /Preben
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context: http://camel.465427.n5.nabble.com/New-camel-hystrix-component-tp5770955p5780454.html
>>>>>> Sent from the Camel Development mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Claus Ibsen
>>>>> -----------------
>>>>> http://davsclaus.com @davsclaus
>>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: New camel-hystrix component
Posted by Claus Ibsen <cl...@gmail.com>.
On Sun, Apr 10, 2016 at 3:41 PM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> Maybe the endpoint can be specified as both id an uri.
> Then if you want to refer to an existing by id as it does today, you
> just use ref:
>
> runEndpoint=ref:foo
> runEndpoint=direct:foo
>
> This also allows to route to seda / jms etc.
>
> runEndpoint=seda:bar
> runEndpoint=jms:queue:numbers
>
> Though if you need to configure the endpoints then you would need to
> setup the endpoint first and then refer to it by id.
>
I am working on this and a few other improvements so we create the
produce once and reuse it as well the resources are shutdown when
being stopped etc.
>
>
>
>
>
> On Sun, Apr 10, 2016 at 1:03 PM, Bilgin Ibryam <bi...@gmail.com> wrote:
>> While implementing the hystrix component, I had to choose whether to
>> use endpoint Ids or direct component for run/faillback endpoints.
>>
>> I've chosen endpoints, as it allows defining any kind of endpoints
>> with all the options and then refer to it by its id. The downside is
>> that you have to add the endpoint to the registry.
>>
>> I think adding also the direct compoent for referring to run/fallback
>> routes would simplify the use of this component. Something like this:
>>
>> public void configure() {
>>
>> from("direct:fallback")
>> .to("mock:error");
>>
>> from("direct:run")
>> .to("mock:result");
>>
>> from("direct:start")
>> .to("hystrix:testKey?runDirectName=run&fallbackName=fallback");
>>
>> }
>>
>> The advantage is that there is no need of an endpointID and and more
>> importantly for adding the endpoint to the registry. The downside is
>> that you have to have a separate route that is using the direct
>> consume.
>>
>> WDYT?
>>
>>
>>
>> On 10 April 2016 at 11:19, Bilgin Ibryam <bi...@gmail.com> wrote:
>>> Hi chaps,
>>>
>>> I'm also not very happy with the way endpointId are part of the
>>> hystrix URL but that was the only non-intrusive way I manged to
>>> implement it atm. Keep in mind that we want both Java and XML dsl
>>> solution. So if you have any ideas to make it easier to use, feel free
>>> to work on it. I won't have bandwidth to improve it further in near
>>> future.
>>>
>>> The previous time when I implemented the circuit breaker, the most
>>> appropriate location I found end up being the load balancer. It did
>>> nicely fit there, bit I think it is still not natural to say that CB
>>> is a LB strategy.
>>>
>>> This time I decided to use a component as I think hystrix is only one
>>> implementation of CB.
>>>
>>> In addition, hystrix does not implement only CB, but more and more
>>> things, which I find confusing. It does bulkheading (which is fine),
>>> but also request collapsing, and also caching.
>>> For something like request collapsing, the more natural way would be
>>> to have aggregator in Camel, and for the caching it would be better if
>>> we had caching DSL with various implementations (very importantly:
>>> distributed cache).
>>>
>>> I think for CB we need a new EIP, and not LB and a component. Hystrix
>>> can be an implementation of the EIP. And it might be better if the
>>> caching, request collapsing concepts are not mixed with the CB EIP.
>>>
>>>
>>> Cheers,
>>>
>>>
>>>
>>>
>>>
>>> On 6 April 2016 at 07:43, Claus Ibsen <cl...@gmail.com> wrote:
>>>> There is some pros with being an endpoint configuration only, as it
>>>> can make it easy for tooling and some developers to use it (when they
>>>> are used to configure uris, and just use from -> to -> to etc). I
>>>> guess the bit unusual part is that you refer to endpoint by id's which
>>>> is not so commonly in use by Camel.
>>>>
>>>> You could also have CB as a kind of error handler, aka onException,
>>>> but have it as onCircuitBreaker, where you can setup those breaker
>>>> configs and fallback routes / endpoint etc. And whether to use a
>>>> fallback or reject or whatnot.
>>>>
>>>> Just a quick pseudo code / braindump
>>>>
>>>> <onCurcuitBreaker threshold="2" halfOpenAfter="1000">
>>>> <exception>IOException</exception>
>>>> <to uri="bean:fallbackStuff"/>
>>>> </onCurcuitBreaker>
>>>>
>>>>
>>>>
>>>> On Mon, Apr 4, 2016 at 6:07 PM, Preben.Asmussen <pr...@dr.dk> wrote:
>>>>> Hi bibryam
>>>>>
>>>>> At first glance it looks a bit intrusive when the usual endpoints are
>>>>> 'wrapped' in the hystrix endpoint.
>>>>>
>>>>> Could it be something like -> psudo code
>>>>>
>>>>> <camelContext id="hystrix-producer"
>>>>> xmlns="http://camel.apache.org/schema/blueprint">
>>>>> <hystrix>
>>>>> <from="run"/>
>>>>> <fallback="http4://www.google.com"/>
>>>>> .............. other options
>>>>> </hystrix>
>>>>>
>>>>> <route>
>>>>> <from
>>>>> uri="timer://local?fixedRate=true&period=50&repeatCount=5"/>
>>>>>
>>>>>
>>>>> <to id="run" uri="http4://localhost"/>
>>>>>
>>>>> <to uri="log:hystrix?level=INFO&showHeaders=true"/>
>>>>> </route>
>>>>> </camelContext>
>>>>>
>>>>> /Preben
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context: http://camel.465427.n5.nabble.com/New-camel-hystrix-component-tp5770955p5780454.html
>>>>> Sent from the Camel Development mailing list archive at Nabble.com.
>>>>
>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> -----------------
>>>> http://davsclaus.com @davsclaus
>>>> Camel in Action 2: https://www.manning.com/ibsen2
>>>
>>>
>>>
>>> --
>>> 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
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: New camel-hystrix component
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Maybe the endpoint can be specified as both id an uri.
Then if you want to refer to an existing by id as it does today, you
just use ref:
runEndpoint=ref:foo
runEndpoint=direct:foo
This also allows to route to seda / jms etc.
runEndpoint=seda:bar
runEndpoint=jms:queue:numbers
Though if you need to configure the endpoints then you would need to
setup the endpoint first and then refer to it by id.
On Sun, Apr 10, 2016 at 1:03 PM, Bilgin Ibryam <bi...@gmail.com> wrote:
> While implementing the hystrix component, I had to choose whether to
> use endpoint Ids or direct component for run/faillback endpoints.
>
> I've chosen endpoints, as it allows defining any kind of endpoints
> with all the options and then refer to it by its id. The downside is
> that you have to add the endpoint to the registry.
>
> I think adding also the direct compoent for referring to run/fallback
> routes would simplify the use of this component. Something like this:
>
> public void configure() {
>
> from("direct:fallback")
> .to("mock:error");
>
> from("direct:run")
> .to("mock:result");
>
> from("direct:start")
> .to("hystrix:testKey?runDirectName=run&fallbackName=fallback");
>
> }
>
> The advantage is that there is no need of an endpointID and and more
> importantly for adding the endpoint to the registry. The downside is
> that you have to have a separate route that is using the direct
> consume.
>
> WDYT?
>
>
>
> On 10 April 2016 at 11:19, Bilgin Ibryam <bi...@gmail.com> wrote:
>> Hi chaps,
>>
>> I'm also not very happy with the way endpointId are part of the
>> hystrix URL but that was the only non-intrusive way I manged to
>> implement it atm. Keep in mind that we want both Java and XML dsl
>> solution. So if you have any ideas to make it easier to use, feel free
>> to work on it. I won't have bandwidth to improve it further in near
>> future.
>>
>> The previous time when I implemented the circuit breaker, the most
>> appropriate location I found end up being the load balancer. It did
>> nicely fit there, bit I think it is still not natural to say that CB
>> is a LB strategy.
>>
>> This time I decided to use a component as I think hystrix is only one
>> implementation of CB.
>>
>> In addition, hystrix does not implement only CB, but more and more
>> things, which I find confusing. It does bulkheading (which is fine),
>> but also request collapsing, and also caching.
>> For something like request collapsing, the more natural way would be
>> to have aggregator in Camel, and for the caching it would be better if
>> we had caching DSL with various implementations (very importantly:
>> distributed cache).
>>
>> I think for CB we need a new EIP, and not LB and a component. Hystrix
>> can be an implementation of the EIP. And it might be better if the
>> caching, request collapsing concepts are not mixed with the CB EIP.
>>
>>
>> Cheers,
>>
>>
>>
>>
>>
>> On 6 April 2016 at 07:43, Claus Ibsen <cl...@gmail.com> wrote:
>>> There is some pros with being an endpoint configuration only, as it
>>> can make it easy for tooling and some developers to use it (when they
>>> are used to configure uris, and just use from -> to -> to etc). I
>>> guess the bit unusual part is that you refer to endpoint by id's which
>>> is not so commonly in use by Camel.
>>>
>>> You could also have CB as a kind of error handler, aka onException,
>>> but have it as onCircuitBreaker, where you can setup those breaker
>>> configs and fallback routes / endpoint etc. And whether to use a
>>> fallback or reject or whatnot.
>>>
>>> Just a quick pseudo code / braindump
>>>
>>> <onCurcuitBreaker threshold="2" halfOpenAfter="1000">
>>> <exception>IOException</exception>
>>> <to uri="bean:fallbackStuff"/>
>>> </onCurcuitBreaker>
>>>
>>>
>>>
>>> On Mon, Apr 4, 2016 at 6:07 PM, Preben.Asmussen <pr...@dr.dk> wrote:
>>>> Hi bibryam
>>>>
>>>> At first glance it looks a bit intrusive when the usual endpoints are
>>>> 'wrapped' in the hystrix endpoint.
>>>>
>>>> Could it be something like -> psudo code
>>>>
>>>> <camelContext id="hystrix-producer"
>>>> xmlns="http://camel.apache.org/schema/blueprint">
>>>> <hystrix>
>>>> <from="run"/>
>>>> <fallback="http4://www.google.com"/>
>>>> .............. other options
>>>> </hystrix>
>>>>
>>>> <route>
>>>> <from
>>>> uri="timer://local?fixedRate=true&period=50&repeatCount=5"/>
>>>>
>>>>
>>>> <to id="run" uri="http4://localhost"/>
>>>>
>>>> <to uri="log:hystrix?level=INFO&showHeaders=true"/>
>>>> </route>
>>>> </camelContext>
>>>>
>>>> /Preben
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context: http://camel.465427.n5.nabble.com/New-camel-hystrix-component-tp5770955p5780454.html
>>>> Sent from the Camel Development mailing list archive at Nabble.com.
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> http://davsclaus.com @davsclaus
>>> Camel in Action 2: https://www.manning.com/ibsen2
>>
>>
>>
>> --
>> 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
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: New camel-hystrix component
Posted by Bilgin Ibryam <bi...@gmail.com>.
While implementing the hystrix component, I had to choose whether to
use endpoint Ids or direct component for run/faillback endpoints.
I've chosen endpoints, as it allows defining any kind of endpoints
with all the options and then refer to it by its id. The downside is
that you have to add the endpoint to the registry.
I think adding also the direct compoent for referring to run/fallback
routes would simplify the use of this component. Something like this:
public void configure() {
from("direct:fallback")
.to("mock:error");
from("direct:run")
.to("mock:result");
from("direct:start")
.to("hystrix:testKey?runDirectName=run&fallbackName=fallback");
}
The advantage is that there is no need of an endpointID and and more
importantly for adding the endpoint to the registry. The downside is
that you have to have a separate route that is using the direct
consume.
WDYT?
On 10 April 2016 at 11:19, Bilgin Ibryam <bi...@gmail.com> wrote:
> Hi chaps,
>
> I'm also not very happy with the way endpointId are part of the
> hystrix URL but that was the only non-intrusive way I manged to
> implement it atm. Keep in mind that we want both Java and XML dsl
> solution. So if you have any ideas to make it easier to use, feel free
> to work on it. I won't have bandwidth to improve it further in near
> future.
>
> The previous time when I implemented the circuit breaker, the most
> appropriate location I found end up being the load balancer. It did
> nicely fit there, bit I think it is still not natural to say that CB
> is a LB strategy.
>
> This time I decided to use a component as I think hystrix is only one
> implementation of CB.
>
> In addition, hystrix does not implement only CB, but more and more
> things, which I find confusing. It does bulkheading (which is fine),
> but also request collapsing, and also caching.
> For something like request collapsing, the more natural way would be
> to have aggregator in Camel, and for the caching it would be better if
> we had caching DSL with various implementations (very importantly:
> distributed cache).
>
> I think for CB we need a new EIP, and not LB and a component. Hystrix
> can be an implementation of the EIP. And it might be better if the
> caching, request collapsing concepts are not mixed with the CB EIP.
>
>
> Cheers,
>
>
>
>
>
> On 6 April 2016 at 07:43, Claus Ibsen <cl...@gmail.com> wrote:
>> There is some pros with being an endpoint configuration only, as it
>> can make it easy for tooling and some developers to use it (when they
>> are used to configure uris, and just use from -> to -> to etc). I
>> guess the bit unusual part is that you refer to endpoint by id's which
>> is not so commonly in use by Camel.
>>
>> You could also have CB as a kind of error handler, aka onException,
>> but have it as onCircuitBreaker, where you can setup those breaker
>> configs and fallback routes / endpoint etc. And whether to use a
>> fallback or reject or whatnot.
>>
>> Just a quick pseudo code / braindump
>>
>> <onCurcuitBreaker threshold="2" halfOpenAfter="1000">
>> <exception>IOException</exception>
>> <to uri="bean:fallbackStuff"/>
>> </onCurcuitBreaker>
>>
>>
>>
>> On Mon, Apr 4, 2016 at 6:07 PM, Preben.Asmussen <pr...@dr.dk> wrote:
>>> Hi bibryam
>>>
>>> At first glance it looks a bit intrusive when the usual endpoints are
>>> 'wrapped' in the hystrix endpoint.
>>>
>>> Could it be something like -> psudo code
>>>
>>> <camelContext id="hystrix-producer"
>>> xmlns="http://camel.apache.org/schema/blueprint">
>>> <hystrix>
>>> <from="run"/>
>>> <fallback="http4://www.google.com"/>
>>> .............. other options
>>> </hystrix>
>>>
>>> <route>
>>> <from
>>> uri="timer://local?fixedRate=true&period=50&repeatCount=5"/>
>>>
>>>
>>> <to id="run" uri="http4://localhost"/>
>>>
>>> <to uri="log:hystrix?level=INFO&showHeaders=true"/>
>>> </route>
>>> </camelContext>
>>>
>>> /Preben
>>>
>>>
>>>
>>> --
>>> View this message in context: http://camel.465427.n5.nabble.com/New-camel-hystrix-component-tp5770955p5780454.html
>>> Sent from the Camel Development mailing list archive at Nabble.com.
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> http://davsclaus.com @davsclaus
>> Camel in Action 2: https://www.manning.com/ibsen2
>
>
>
> --
> 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
Re: New camel-hystrix component
Posted by Bilgin Ibryam <bi...@gmail.com>.
Hi chaps,
I'm also not very happy with the way endpointId are part of the
hystrix URL but that was the only non-intrusive way I manged to
implement it atm. Keep in mind that we want both Java and XML dsl
solution. So if you have any ideas to make it easier to use, feel free
to work on it. I won't have bandwidth to improve it further in near
future.
The previous time when I implemented the circuit breaker, the most
appropriate location I found end up being the load balancer. It did
nicely fit there, bit I think it is still not natural to say that CB
is a LB strategy.
This time I decided to use a component as I think hystrix is only one
implementation of CB.
In addition, hystrix does not implement only CB, but more and more
things, which I find confusing. It does bulkheading (which is fine),
but also request collapsing, and also caching.
For something like request collapsing, the more natural way would be
to have aggregator in Camel, and for the caching it would be better if
we had caching DSL with various implementations (very importantly:
distributed cache).
I think for CB we need a new EIP, and not LB and a component. Hystrix
can be an implementation of the EIP. And it might be better if the
caching, request collapsing concepts are not mixed with the CB EIP.
Cheers,
On 6 April 2016 at 07:43, Claus Ibsen <cl...@gmail.com> wrote:
> There is some pros with being an endpoint configuration only, as it
> can make it easy for tooling and some developers to use it (when they
> are used to configure uris, and just use from -> to -> to etc). I
> guess the bit unusual part is that you refer to endpoint by id's which
> is not so commonly in use by Camel.
>
> You could also have CB as a kind of error handler, aka onException,
> but have it as onCircuitBreaker, where you can setup those breaker
> configs and fallback routes / endpoint etc. And whether to use a
> fallback or reject or whatnot.
>
> Just a quick pseudo code / braindump
>
> <onCurcuitBreaker threshold="2" halfOpenAfter="1000">
> <exception>IOException</exception>
> <to uri="bean:fallbackStuff"/>
> </onCurcuitBreaker>
>
>
>
> On Mon, Apr 4, 2016 at 6:07 PM, Preben.Asmussen <pr...@dr.dk> wrote:
>> Hi bibryam
>>
>> At first glance it looks a bit intrusive when the usual endpoints are
>> 'wrapped' in the hystrix endpoint.
>>
>> Could it be something like -> psudo code
>>
>> <camelContext id="hystrix-producer"
>> xmlns="http://camel.apache.org/schema/blueprint">
>> <hystrix>
>> <from="run"/>
>> <fallback="http4://www.google.com"/>
>> .............. other options
>> </hystrix>
>>
>> <route>
>> <from
>> uri="timer://local?fixedRate=true&period=50&repeatCount=5"/>
>>
>>
>> <to id="run" uri="http4://localhost"/>
>>
>> <to uri="log:hystrix?level=INFO&showHeaders=true"/>
>> </route>
>> </camelContext>
>>
>> /Preben
>>
>>
>>
>> --
>> View this message in context: http://camel.465427.n5.nabble.com/New-camel-hystrix-component-tp5770955p5780454.html
>> Sent from the Camel Development mailing list archive at Nabble.com.
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
--
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
Re: New camel-hystrix component
Posted by Claus Ibsen <cl...@gmail.com>.
There is some pros with being an endpoint configuration only, as it
can make it easy for tooling and some developers to use it (when they
are used to configure uris, and just use from -> to -> to etc). I
guess the bit unusual part is that you refer to endpoint by id's which
is not so commonly in use by Camel.
You could also have CB as a kind of error handler, aka onException,
but have it as onCircuitBreaker, where you can setup those breaker
configs and fallback routes / endpoint etc. And whether to use a
fallback or reject or whatnot.
Just a quick pseudo code / braindump
<onCurcuitBreaker threshold="2" halfOpenAfter="1000">
<exception>IOException</exception>
<to uri="bean:fallbackStuff"/>
</onCurcuitBreaker>
On Mon, Apr 4, 2016 at 6:07 PM, Preben.Asmussen <pr...@dr.dk> wrote:
> Hi bibryam
>
> At first glance it looks a bit intrusive when the usual endpoints are
> 'wrapped' in the hystrix endpoint.
>
> Could it be something like -> psudo code
>
> <camelContext id="hystrix-producer"
> xmlns="http://camel.apache.org/schema/blueprint">
> <hystrix>
> <from="run"/>
> <fallback="http4://www.google.com"/>
> .............. other options
> </hystrix>
>
> <route>
> <from
> uri="timer://local?fixedRate=true&period=50&repeatCount=5"/>
>
>
> <to id="run" uri="http4://localhost"/>
>
> <to uri="log:hystrix?level=INFO&showHeaders=true"/>
> </route>
> </camelContext>
>
> /Preben
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/New-camel-hystrix-component-tp5770955p5780454.html
> Sent from the Camel Development mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: New camel-hystrix component
Posted by "Preben.Asmussen" <pr...@dr.dk>.
Hi bibryam
At first glance it looks a bit intrusive when the usual endpoints are
'wrapped' in the hystrix endpoint.
Could it be something like -> psudo code
<camelContext id="hystrix-producer"
xmlns="http://camel.apache.org/schema/blueprint">
<hystrix>
<from="run"/>
<fallback="http4://www.google.com"/>
.............. other options
</hystrix>
<route>
<from
uri="timer://local?fixedRate=true&period=50&repeatCount=5"/>
<to id="run" uri="http4://localhost"/>
<to uri="log:hystrix?level=INFO&showHeaders=true"/>
</route>
</camelContext>
/Preben
--
View this message in context: http://camel.465427.n5.nabble.com/New-camel-hystrix-component-tp5770955p5780454.html
Sent from the Camel Development mailing list archive at Nabble.com.