You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by David Karlsen <da...@gmail.com> on 2015/02/23 10:03:11 UTC

Hystrix feature?

Hi.

I'm wondering about creating an Interceptor for outgoing requests
(isRequestor()==true) to wrap these (synchronously) in a Hystrix [1]
executable [2].

Instead of having this as an inhouse custom component, I wonder about
creating a branch of cxf and adding a features/hystrix component (like for
the clustering support). Is this a component you would accept and be
willing to merge into master? I'm asking upfront so I don't end in a
dead-end with it and have to port it back to an inhouse-component.
I thought I'd use the serviceQname as commandGroup (namespace) and key
(localname). I also thought I'd add a protected method resolveTenant
(returning null for default) so that multitenant solutions are well
supported (e.g. the same service may be ok for one tenant and failing for
another, so be able to differenciate config).

[1] https://github.com/Netflix/Hystrix
[2]
https://netflix.github.io/Hystrix/javadoc/com/netflix/hystrix/HystrixCommand.html


WDYT?

-- 
--
David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen

Re: Fwd: Hystrix feature?

Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Andriy

But please, do reply to David K and work with him - IMHO CXF won't have 
to ship Hystrix - but making sure various CXF (client) Failover 
interfaces can be extended to accommodate a Hystrix feature would be a 
good idea IMHO. We can then start with adding a  Hystrix failover system 
test.

Thanks, Sergey


On 24/02/15 13:00, Sergey Beryozkin wrote:
> Hi Andriy,
>
> David Karlsen is def not proposing to start supporting reactive client
> API, it is more about about some advanced fault-tolerance support - we
> should actually reply to him I guess.
>
> Thanks for sharing a link though. We will have to implement it as part
> of JAX-RS 2.1 work, and we'd need to have a Java 8 trunk opened for it.
>
> It does appear Jersey is already full steam into a Java 8 based 2.1
> development (note: no spec api proposals have been made - but I expect
> them coming soon enough once they have finished experimenting). Dan,
>
> IMHO it would be right to have a Java 8 trunk opened in the last quarter
> of the year to give CXF a better chance of catching up sooner than later
> with Jersey. I'm not trying to extend the dev discussion here though -
> more or less what I said there :-)
>
> Cheers, Sergey
>
>
> On 24/02/15 12:30, Andrey Redko wrote:
>> Hi Sergey,
>>
>> What do you think about looking into this feature? I do have some
>> knowledge about Hystrix and it
>> has gained some traction in the community. I am not sure though what
>> exactly this guy has
>> in mind BUT if you don't mind, I can work with him to outline his design
>> / intentions and make sure
>> it would make sense for the CXF project (I can reply to him and work
>> with him directly).
>>
>> What do you think?
>>
>> PS: FYI, Jersey has started to integrate Netflix projects
>> (http://blog.dejavu.sk/2015/01/07/reactive-jersey-client-part-1-motivation/),
>>
>> into their JAX-RS implementation, I think Hystrix will come soon as well.
>>
>> Best Regards,
>>      Andriy Redko
>>
>> ---------- Forwarded message ----------
>> From: *David Karlsen* <davidkarlsen@gmail.com
>> <ma...@gmail.com>>
>> Date: Mon, Feb 23, 2015 at 4:03 AM
>> Subject: Hystrix feature?
>> To: dev@cxf.apache.org <ma...@cxf.apache.org>
>>
>>
>> Hi.
>>
>> I'm wondering about creating an Interceptor for outgoing requests
>> (isRequestor()==true) to wrap these (synchronously) in a Hystrix [1]
>> executable [2].
>>
>> Instead of having this as an inhouse custom component, I wonder about
>> creating a branch of cxf and adding a features/hystrix component (like
>> for
>> the clustering support). Is this a component you would accept and be
>> willing to merge into master? I'm asking upfront so I don't end in a
>> dead-end with it and have to port it back to an inhouse-component.
>> I thought I'd use the serviceQname as commandGroup (namespace) and key
>> (localname). I also thought I'd add a protected method resolveTenant
>> (returning null for default) so that multitenant solutions are well
>> supported (e.g. the same service may be ok for one tenant and failing for
>> another, so be able to differenciate config).
>>
>> [1] https://github.com/Netflix/Hystrix
>> [2]
>> https://netflix.github.io/Hystrix/javadoc/com/netflix/hystrix/HystrixCommand.html
>>
>>
>>
>> WDYT?
>>
>> --
>> --
>> David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
>>
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

Re: Fwd: Hystrix feature?

Posted by Andrey Redko <dr...@gmail.com>.
Hi Sergey,

+1, Java 8 trunk is the priority, definitely agree (please count in me to
help with addressing any issues we may have).
Thanks!

PS: From runtime prospective, CXF 2.7.x / 3.x runs very well on JVM 8, it
is my second project where we run CXF in prod
on Java 8 for quite some time and it has no issues so far.

Best Regards,
    Andriy Redko

On Tue, Feb 24, 2015 at 8:34 AM, Sergey Beryozkin <sb...@gmail.com>
wrote:

> Hi Andriy
>
> I'd not really worry right now about it, it would only be a Jersey
> specific integration and we just have to wait get a Java 8 trunk first
> anyway - I do expect that JAX-RS 2.1 Reactive extensions will have no any
> direct relationship to Netflix, perhaps you'd choose to use ot internally,
> I'm not sure right now
>
> Cheers, Sergey
> On 24/02/15 13:31, Andrey Redko wrote:
>
>> Hi Sergey,
>>
>> Thanks, absolutely, he is not proposing the reactive client. It is my
>> own comment with respect to Netflix projects making its way into
>> Jersey/JAX-RS implementation(s).
>> It is more about do we want spend time / efforts on that? Hystrix
>> integration could be interesting feature however at this point I do no
>> see clearly how it fits into CXF, only some rough sketches.
>> Thanks!
>>
>> On Tue, Feb 24, 2015 at 8:00 AM, Sergey Beryozkin <sberyozkin@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>>     Hi Andriy,
>>
>>     David Karlsen is def not proposing to start supporting reactive
>>     client API, it is more about about some advanced fault-tolerance
>>     support - we should actually reply to him I guess.
>>
>>     Thanks for sharing a link though. We will have to implement it as
>>     part of JAX-RS 2.1 work, and we'd need to have a Java 8 trunk opened
>>     for it.
>>
>>     It does appear Jersey is already full steam into a Java 8 based 2.1
>>     development (note: no spec api proposals have been made - but I
>>     expect them coming soon enough once they have finished
>>     experimenting). Dan,
>>
>>     IMHO it would be right to have a Java 8 trunk opened in the last
>>     quarter of the year to give CXF a better chance of catching up
>>     sooner than later with Jersey. I'm not trying to extend the dev
>>     discussion here though - more or less what I said there :-)
>>
>>     Cheers, Sergey
>>
>>
>>     On 24/02/15 12:30, Andrey Redko wrote:
>>
>>         Hi Sergey,
>>
>>         What do you think about looking into this feature? I do have some
>>         knowledge about Hystrix and it
>>         has gained some traction in the community. I am not sure though
>> what
>>         exactly this guy has
>>         in mind BUT if you don't mind, I can work with him to outline
>>         his design
>>         / intentions and make sure
>>         it would make sense for the CXF project (I can reply to him and
>> work
>>         with him directly).
>>
>>         What do you think?
>>
>>         PS: FYI, Jersey has started to integrate Netflix projects
>>         (http://blog.dejavu.sk/2015/__01/07/reactive-jersey-client-_
>> _part-1-motivation/
>>         <http://blog.dejavu.sk/2015/01/07/reactive-jersey-client-
>> part-1-motivation/>),
>>         into their JAX-RS implementation, I think Hystrix will come soon
>>         as well.
>>
>>         Best Regards,
>>               Andriy Redko
>>
>>         ---------- Forwarded message ----------
>>         From: *David Karlsen* <davidkarlsen@gmail.com
>>         <ma...@gmail.com>
>>         <mailto:davidkarlsen@gmail.com <mailto:davidkarlsen@gmail.com
>> >__>>
>>         Date: Mon, Feb 23, 2015 at 4:03 AM
>>         Subject: Hystrix feature?
>>         To: dev@cxf.apache.org <ma...@cxf.apache.org>
>>         <mailto:dev@cxf.apache.org <ma...@cxf.apache.org>>
>>
>>
>>         Hi.
>>
>>         I'm wondering about creating an Interceptor for outgoing requests
>>         (isRequestor()==true) to wrap these (synchronously) in a Hystrix
>> [1]
>>         executable [2].
>>
>>         Instead of having this as an inhouse custom component, I wonder
>>         about
>>         creating a branch of cxf and adding a features/hystrix component
>>         (like for
>>         the clustering support). Is this a component you would accept and
>> be
>>         willing to merge into master? I'm asking upfront so I don't end
>> in a
>>         dead-end with it and have to port it back to an inhouse-component.
>>         I thought I'd use the serviceQname as commandGroup (namespace)
>>         and key
>>         (localname). I also thought I'd add a protected method
>> resolveTenant
>>         (returning null for default) so that multitenant solutions are
>> well
>>         supported (e.g. the same service may be ok for one tenant and
>>         failing for
>>         another, so be able to differenciate config).
>>
>>         [1] https://github.com/Netflix/__Hystrix
>>         <https://github.com/Netflix/Hystrix>
>>         [2]
>>         https://netflix.github.io/__Hystrix/javadoc/com/netflix/__
>> hystrix/HystrixCommand.html
>>         <https://netflix.github.io/Hystrix/javadoc/com/netflix/
>> hystrix/HystrixCommand.html>
>>
>>
>>         WDYT?
>>
>>         --
>>         --
>>         David J. M. Karlsen - http://www.linkedin.com/in/__davidkarlsen
>>         <http://www.linkedin.com/in/davidkarlsen>
>>
>>
>>
>>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com
>

Re: Fwd: Hystrix feature?

Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Andriy

I'd not really worry right now about it, it would only be a Jersey 
specific integration and we just have to wait get a Java 8 trunk first 
anyway - I do expect that JAX-RS 2.1 Reactive extensions will have no 
any direct relationship to Netflix, perhaps you'd choose to use ot 
internally, I'm not sure right now

Cheers, Sergey
On 24/02/15 13:31, Andrey Redko wrote:
> Hi Sergey,
>
> Thanks, absolutely, he is not proposing the reactive client. It is my
> own comment with respect to Netflix projects making its way into
> Jersey/JAX-RS implementation(s).
> It is more about do we want spend time / efforts on that? Hystrix
> integration could be interesting feature however at this point I do no
> see clearly how it fits into CXF, only some rough sketches.
> Thanks!
>
> On Tue, Feb 24, 2015 at 8:00 AM, Sergey Beryozkin <sberyozkin@gmail.com
> <ma...@gmail.com>> wrote:
>
>     Hi Andriy,
>
>     David Karlsen is def not proposing to start supporting reactive
>     client API, it is more about about some advanced fault-tolerance
>     support - we should actually reply to him I guess.
>
>     Thanks for sharing a link though. We will have to implement it as
>     part of JAX-RS 2.1 work, and we'd need to have a Java 8 trunk opened
>     for it.
>
>     It does appear Jersey is already full steam into a Java 8 based 2.1
>     development (note: no spec api proposals have been made - but I
>     expect them coming soon enough once they have finished
>     experimenting). Dan,
>
>     IMHO it would be right to have a Java 8 trunk opened in the last
>     quarter of the year to give CXF a better chance of catching up
>     sooner than later with Jersey. I'm not trying to extend the dev
>     discussion here though - more or less what I said there :-)
>
>     Cheers, Sergey
>
>
>     On 24/02/15 12:30, Andrey Redko wrote:
>
>         Hi Sergey,
>
>         What do you think about looking into this feature? I do have some
>         knowledge about Hystrix and it
>         has gained some traction in the community. I am not sure though what
>         exactly this guy has
>         in mind BUT if you don't mind, I can work with him to outline
>         his design
>         / intentions and make sure
>         it would make sense for the CXF project (I can reply to him and work
>         with him directly).
>
>         What do you think?
>
>         PS: FYI, Jersey has started to integrate Netflix projects
>         (http://blog.dejavu.sk/2015/__01/07/reactive-jersey-client-__part-1-motivation/
>         <http://blog.dejavu.sk/2015/01/07/reactive-jersey-client-part-1-motivation/>),
>         into their JAX-RS implementation, I think Hystrix will come soon
>         as well.
>
>         Best Regards,
>               Andriy Redko
>
>         ---------- Forwarded message ----------
>         From: *David Karlsen* <davidkarlsen@gmail.com
>         <ma...@gmail.com>
>         <mailto:davidkarlsen@gmail.com <ma...@gmail.com>__>>
>         Date: Mon, Feb 23, 2015 at 4:03 AM
>         Subject: Hystrix feature?
>         To: dev@cxf.apache.org <ma...@cxf.apache.org>
>         <mailto:dev@cxf.apache.org <ma...@cxf.apache.org>>
>
>
>         Hi.
>
>         I'm wondering about creating an Interceptor for outgoing requests
>         (isRequestor()==true) to wrap these (synchronously) in a Hystrix [1]
>         executable [2].
>
>         Instead of having this as an inhouse custom component, I wonder
>         about
>         creating a branch of cxf and adding a features/hystrix component
>         (like for
>         the clustering support). Is this a component you would accept and be
>         willing to merge into master? I'm asking upfront so I don't end in a
>         dead-end with it and have to port it back to an inhouse-component.
>         I thought I'd use the serviceQname as commandGroup (namespace)
>         and key
>         (localname). I also thought I'd add a protected method resolveTenant
>         (returning null for default) so that multitenant solutions are well
>         supported (e.g. the same service may be ok for one tenant and
>         failing for
>         another, so be able to differenciate config).
>
>         [1] https://github.com/Netflix/__Hystrix
>         <https://github.com/Netflix/Hystrix>
>         [2]
>         https://netflix.github.io/__Hystrix/javadoc/com/netflix/__hystrix/HystrixCommand.html
>         <https://netflix.github.io/Hystrix/javadoc/com/netflix/hystrix/HystrixCommand.html>
>
>
>         WDYT?
>
>         --
>         --
>         David J. M. Karlsen - http://www.linkedin.com/in/__davidkarlsen
>         <http://www.linkedin.com/in/davidkarlsen>
>
>
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

Re: Fwd: Hystrix feature?

Posted by Andrey Redko <dr...@gmail.com>.
Hi Sergey,

Thanks, absolutely, he is not proposing the reactive client. It is my own
comment with respect to Netflix projects making its way into Jersey/JAX-RS
implementation(s).
It is more about do we want spend time / efforts on that? Hystrix
integration could be interesting feature however at this point I do no see
clearly how it fits into CXF, only some rough sketches.
Thanks!

On Tue, Feb 24, 2015 at 8:00 AM, Sergey Beryozkin <sb...@gmail.com>
wrote:

> Hi Andriy,
>
> David Karlsen is def not proposing to start supporting reactive client
> API, it is more about about some advanced fault-tolerance support - we
> should actually reply to him I guess.
>
> Thanks for sharing a link though. We will have to implement it as part of
> JAX-RS 2.1 work, and we'd need to have a Java 8 trunk opened for it.
>
> It does appear Jersey is already full steam into a Java 8 based 2.1
> development (note: no spec api proposals have been made - but I expect them
> coming soon enough once they have finished experimenting). Dan,
>
> IMHO it would be right to have a Java 8 trunk opened in the last quarter
> of the year to give CXF a better chance of catching up sooner than later
> with Jersey. I'm not trying to extend the dev discussion here though - more
> or less what I said there :-)
>
> Cheers, Sergey
>
>
> On 24/02/15 12:30, Andrey Redko wrote:
>
>> Hi Sergey,
>>
>> What do you think about looking into this feature? I do have some
>> knowledge about Hystrix and it
>> has gained some traction in the community. I am not sure though what
>> exactly this guy has
>> in mind BUT if you don't mind, I can work with him to outline his design
>> / intentions and make sure
>> it would make sense for the CXF project (I can reply to him and work
>> with him directly).
>>
>> What do you think?
>>
>> PS: FYI, Jersey has started to integrate Netflix projects
>> (http://blog.dejavu.sk/2015/01/07/reactive-jersey-client-
>> part-1-motivation/),
>> into their JAX-RS implementation, I think Hystrix will come soon as well.
>>
>> Best Regards,
>>      Andriy Redko
>>
>> ---------- Forwarded message ----------
>> From: *David Karlsen* <davidkarlsen@gmail.com
>> <ma...@gmail.com>>
>> Date: Mon, Feb 23, 2015 at 4:03 AM
>> Subject: Hystrix feature?
>> To: dev@cxf.apache.org <ma...@cxf.apache.org>
>>
>>
>> Hi.
>>
>> I'm wondering about creating an Interceptor for outgoing requests
>> (isRequestor()==true) to wrap these (synchronously) in a Hystrix [1]
>> executable [2].
>>
>> Instead of having this as an inhouse custom component, I wonder about
>> creating a branch of cxf and adding a features/hystrix component (like for
>> the clustering support). Is this a component you would accept and be
>> willing to merge into master? I'm asking upfront so I don't end in a
>> dead-end with it and have to port it back to an inhouse-component.
>> I thought I'd use the serviceQname as commandGroup (namespace) and key
>> (localname). I also thought I'd add a protected method resolveTenant
>> (returning null for default) so that multitenant solutions are well
>> supported (e.g. the same service may be ok for one tenant and failing for
>> another, so be able to differenciate config).
>>
>> [1] https://github.com/Netflix/Hystrix
>> [2]
>> https://netflix.github.io/Hystrix/javadoc/com/netflix/
>> hystrix/HystrixCommand.html
>>
>>
>> WDYT?
>>
>> --
>> --
>> David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
>>
>>
>

Re: Fwd: Hystrix feature?

Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Andriy,

David Karlsen is def not proposing to start supporting reactive client 
API, it is more about about some advanced fault-tolerance support - we 
should actually reply to him I guess.

Thanks for sharing a link though. We will have to implement it as part 
of JAX-RS 2.1 work, and we'd need to have a Java 8 trunk opened for it.

It does appear Jersey is already full steam into a Java 8 based 2.1 
development (note: no spec api proposals have been made - but I expect 
them coming soon enough once they have finished experimenting). Dan,

IMHO it would be right to have a Java 8 trunk opened in the last quarter 
of the year to give CXF a better chance of catching up sooner than later 
with Jersey. I'm not trying to extend the dev discussion here though - 
more or less what I said there :-)

Cheers, Sergey


On 24/02/15 12:30, Andrey Redko wrote:
> Hi Sergey,
>
> What do you think about looking into this feature? I do have some
> knowledge about Hystrix and it
> has gained some traction in the community. I am not sure though what
> exactly this guy has
> in mind BUT if you don't mind, I can work with him to outline his design
> / intentions and make sure
> it would make sense for the CXF project (I can reply to him and work
> with him directly).
>
> What do you think?
>
> PS: FYI, Jersey has started to integrate Netflix projects
> (http://blog.dejavu.sk/2015/01/07/reactive-jersey-client-part-1-motivation/),
> into their JAX-RS implementation, I think Hystrix will come soon as well.
>
> Best Regards,
>      Andriy Redko
>
> ---------- Forwarded message ----------
> From: *David Karlsen* <davidkarlsen@gmail.com
> <ma...@gmail.com>>
> Date: Mon, Feb 23, 2015 at 4:03 AM
> Subject: Hystrix feature?
> To: dev@cxf.apache.org <ma...@cxf.apache.org>
>
>
> Hi.
>
> I'm wondering about creating an Interceptor for outgoing requests
> (isRequestor()==true) to wrap these (synchronously) in a Hystrix [1]
> executable [2].
>
> Instead of having this as an inhouse custom component, I wonder about
> creating a branch of cxf and adding a features/hystrix component (like for
> the clustering support). Is this a component you would accept and be
> willing to merge into master? I'm asking upfront so I don't end in a
> dead-end with it and have to port it back to an inhouse-component.
> I thought I'd use the serviceQname as commandGroup (namespace) and key
> (localname). I also thought I'd add a protected method resolveTenant
> (returning null for default) so that multitenant solutions are well
> supported (e.g. the same service may be ok for one tenant and failing for
> another, so be able to differenciate config).
>
> [1] https://github.com/Netflix/Hystrix
> [2]
> https://netflix.github.io/Hystrix/javadoc/com/netflix/hystrix/HystrixCommand.html
>
>
> WDYT?
>
> --
> --
> David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
>


Fwd: Hystrix feature?

Posted by Andrey Redko <dr...@gmail.com>.
Hi Sergey,

What do you think about looking into this feature? I do have some knowledge
about Hystrix and it
has gained some traction in the community. I am not sure though what
exactly this guy has
in mind BUT if you don't mind, I can work with him to outline his design /
intentions and make sure
it would make sense for the CXF project (I can reply to him and work with
him directly).

What do you think?

PS: FYI, Jersey has started to integrate Netflix projects (
http://blog.dejavu.sk/2015/01/07/reactive-jersey-client-part-1-motivation/),
into their JAX-RS implementation, I think Hystrix will come soon as well.

Best Regards,
    Andriy Redko

---------- Forwarded message ----------
From: David Karlsen <da...@gmail.com>
Date: Mon, Feb 23, 2015 at 4:03 AM
Subject: Hystrix feature?
To: dev@cxf.apache.org


Hi.

I'm wondering about creating an Interceptor for outgoing requests
(isRequestor()==true) to wrap these (synchronously) in a Hystrix [1]
executable [2].

Instead of having this as an inhouse custom component, I wonder about
creating a branch of cxf and adding a features/hystrix component (like for
the clustering support). Is this a component you would accept and be
willing to merge into master? I'm asking upfront so I don't end in a
dead-end with it and have to port it back to an inhouse-component.
I thought I'd use the serviceQname as commandGroup (namespace) and key
(localname). I also thought I'd add a protected method resolveTenant
(returning null for default) so that multitenant solutions are well
supported (e.g. the same service may be ok for one tenant and failing for
another, so be able to differenciate config).

[1] https://github.com/Netflix/Hystrix
[2]
https://netflix.github.io/Hystrix/javadoc/com/netflix/hystrix/HystrixCommand.html


WDYT?

--
--
David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen

Re: Hystrix feature?

Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi David

I'd like to ask you, are you still interested to see some CXF-level
integration done with Hystrix ?
Perhaps CXF Failover feature can be adjusted so that a Hystrix feature is
easily implemented on top of it,
Thanks, Sergey




--
View this message in context: http://cxf.547215.n5.nabble.com/Hystrix-feature-tp5754528p5756674.html
Sent from the cxf-dev mailing list archive at Nabble.com.

Re: Hystrix feature?

Posted by Andriy Redko <dr...@gmail.com>.
Hi David,

Thank you very much for bringing up this interesting feature. At this very
moment it is a bit early to say that the component is going to be accepted
and will make it way into Apache CXF codebase. However, it may indeed become 
very useful. What do you think if we start with discussion on what problem(s)
and use case(s) you are going to solve with CXF/Hystrix, how integration is going 
to be designed (you already put some rought design notes), how it is going to
be used in existing/new applications build on top of Apache CXF.

Please let us know if it would make sense to you. 
Thank you.

Best Regards,
    Andriy Redko

DK> Hi.

DK> I'm wondering about creating an Interceptor for outgoing requests
DK> (isRequestor()==true) to wrap these (synchronously) in a Hystrix [1]
DK> executable [2].

DK> Instead of having this as an inhouse custom component, I wonder about
DK> creating a branch of cxf and adding a features/hystrix component (like for
DK> the clustering support). Is this a component you would accept and be
DK> willing to merge into master? I'm asking upfront so I don't end in a
DK> dead-end with it and have to port it back to an inhouse-component.
DK> I thought I'd use the serviceQname as commandGroup (namespace) and key
DK> (localname). I also thought I'd add a protected method resolveTenant
DK> (returning null for default) so that multitenant solutions are well
DK> supported (e.g. the same service may be ok for one tenant and failing for
DK> another, so be able to differenciate config).

DK> [1] https://github.com/Netflix/Hystrix
DK> [2]
DK> https://netflix.github.io/Hystrix/javadoc/com/netflix/hystrix/HystrixCommand.html


DK> WDYT?