camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bilgin Ibryam <bibr...@gmail.com>
Subject Re: New camel-hystrix component
Date Thu, 14 Apr 2016 09:57:53 GMT
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 <claus.ibsen@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 <claus.ibsen@gmail.com> wrote:
>> On Sun, Apr 10, 2016 at 3:41 PM, Claus Ibsen <claus.ibsen@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 <bibryam@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 <bibryam@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.ibsen@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 <pras@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=&quot;run&quot;/>
>>>>>>>            <fallback=&quot;http4://www.google.com&quot;/>
>>>>>>>             .............. other options
>>>>>>>         </hystrix>
>>>>>>>
>>>>>>>         <route>
>>>>>>>           <from
>>>>>>> uri="timer://local?fixedRate=true&amp;period=50&amp;repeatCount=5"/>
>>>>>>>
>>>>>>>
>>>>>>>           <to id="run" uri="http4://localhost"/>
>>>>>>>
>>>>>>>           <to uri="log:hystrix?level=INFO&amp;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

Mime
View raw message