On Sun, Apr 10, 2016 at 3:41 PM, Claus Ibsen <claus.ib...@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 <bibr...@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 <bibr...@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 <claus.ib...@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 <p...@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
