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 <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
