Hystrix: @HystrixCommand support dynamic command key?

[namjug-kim]

Is there any way to use dynamic command key using @HystrixCommand annotation?

@HysrixCommand(groupKey = "testGroup", commandKey = "commandPrefix")
public String test(String userName) {
   // blah blah
   return userName;
}

in upper case is there any way use userName to postfix of HystrixCommand command key?

test("user-1"); // groupKey 'testGroup' , commandKey 'commandPrefix-user-1'
test("user-2"); // groupKey 'testGroup' , commandKey 'commandPrefix-user-2'

[mattrjacobs]

What's the use case for this? Having a separate command key per user implies a huge number of Hystrix commands, none of which share state. This would make a system much harder to manage and operate.

[namjug-kim]

@mattrjacobs
google api has Api quota about user. if user A occur too many request 'user B' work fine but 'user A' occur error. separate state is required for each user.
in this case open circuit 'user A' and close circuit 'user B'

[mattrjacobs]

OK, I see what you're getting at. AFAIK, there's nothing in the hystrix-javanica layer which allows for this. If you use vanilla Hystrix, then you can use a traditional Java constructor and set the command key based on some input to the command instance constructor.

Though I still must caution you that partitioning the user-space has a cost to understanding the system. If you've got 1000 getFoo command keys (1 per-user), then it will be hard to determine, in aggregate, if the FooService is behaving well in aggregate.

[namjug-kim]

@mattrjacobs thanks for your answer. yes maybe i need to make custom dashboard to determine FooService is behaving well. In my case partitioning the user-space has any system resource problem that can't use?

or Is there other good way to solve my case?

[mattrjacobs]

This old proposed issue is relevant: #26. This would apply to your case by treating each user as a "shard". Then FooService failures would be across all shards, so would make each shard's circuit more likely to open. Failures only affecting a shard would be limited to that circuit.

We haven't spent any time on this, because this adds a great deal of complexity, and we haven't needed it on any of our own systems.

[mattrjacobs]

Closing due to inactivity. Please re-open if there's more to discuss.

[SingleShot]

I see this is closed but I would like this functionality as well. I think the example case makes sense and is similar to the case I want it for. I understand the objections and words of caution regarding partitioning like this, but should the library actually prevent it? I will have to go to the "raw" Hystrix API even though I really like this annotation-based approach.

[anjia0532]

@SingleShot my gist https://gist.github.com/anjia0532/e30bba219a169927160ba336d1b7aec0