SAMZA-2574: improve flexibility of SystemFactory interface#1408
SAMZA-2574: improve flexibility of SystemFactory interface#1408sborya merged 8 commits intoapache:masterfrom
Conversation
Merge from origin branch
samza-api/src/main/java/org/apache/samza/system/SystemFactory.java
Outdated
Show resolved
Hide resolved
samza-api/src/main/java/org/apache/samza/system/SystemFactory.java
Outdated
Show resolved
Hide resolved
samza-api/src/main/java/org/apache/samza/system/SystemFactory.java
Outdated
Show resolved
Hide resolved
|
@cameronlee314 can you take a look? |
|
@MabelYC Please also explain (in the description) why this change is required and how this will be used. |
Sure. |
sborya
left a comment
There was a problem hiding this comment.
Please change the name of the rb to describe the changes, not the generic intent. Something to the effect of "..allow specify prefix for consumer/producer/admin ids.."
| SystemProducer systemProducer = | ||
| systemFactory.getProducer(diagnosticsSystemStream.getSystem(), config, new MetricsRegistryMap()); | ||
| systemFactory.getProducer(diagnosticsSystemStream.getSystem(), config, new MetricsRegistryMap(), | ||
| MethodHandles.lookup().lookupClass().getSimpleName()); |
There was a problem hiding this comment.
i think it is ok to hardcode the prefix to "DiagnosticsUtil" too.
There was a problem hiding this comment.
Why not use Class.getSimpleName() here too?
There was a problem hiding this comment.
I think it is a static method. And we CAN use simpleName(), but we don't have too. As long as it is unique for the caller.
There was a problem hiding this comment.
Got it, thanks. We can probably use DiagnosticsUtil.class.getSimpleName() so that any refactoring updates it.
|
|
||
| SystemAdmin getAdmin(String systemName, Config config); | ||
|
|
||
| default SystemConsumer getConsumer(String systemName, Config config, MetricsRegistry registry, String consumerIdPrefix) { |
There was a problem hiding this comment.
Why assume that it's used as prefix in the API? Maybe just call this consumerName/consumerId and let the actual implementation figure out how to use it?
There was a problem hiding this comment.
I think we don't want caller to assume that this is the id and it must be used as is. The idea is that it should be a unique piece of info that can be used to construct an id. Please suggest your name.
There was a problem hiding this comment.
I'm assuming this is intended to be used as part of the Kafka clientId to figure out who owns the instance?
Maybe consumerLabel. We should add some documentation on what this should be set to by the caller (e.g., set this to indicate ownership of the client instance), how this will be used by system implementers (e.g., to identify consumers in logs, threads and client instances etc., along with other relevant information like systemName).
There was a problem hiding this comment.
by "add some documentation" you mean add javadoc or open source documentation?
There was a problem hiding this comment.
There was a problem hiding this comment.
@MabelYC I mean Javadocs. The page you linked is auto-generated from Javadocs.
|
|
||
| SystemAdmin getAdmin(String systemName, Config config); | ||
|
|
||
| default SystemConsumer getConsumer(String systemName, Config config, MetricsRegistry registry, String consumerIdPrefix) { |
There was a problem hiding this comment.
Please add method Javadocs clarifying what the parameters are, and how these methods are different than the ones above.
There was a problem hiding this comment.
Also, let's make this the second parameter after systemName to group naming related parameters together.
There was a problem hiding this comment.
good point. Thanks. Will do.
There was a problem hiding this comment.
Also, let's make this the second parameter after systemName to group naming related parameters together.
I think change order may not be a good option. We are adding functions to help make previous ones more flexible, so may be better to keep the order the same as previous one. And also, systemName is not intended to be a naming parameter. So i think it may be better to keep it in current order. what do you think?
There was a problem hiding this comment.
That's a good point, let's keep this order and add javadocs.
|
|
||
| SystemAdmin getAdmin(String systemName, Config config); | ||
|
|
||
| default SystemConsumer getConsumer(String systemName, Config config, MetricsRegistry registry, String consumerIdPrefix) { |
There was a problem hiding this comment.
Should we mark the other methods as @deprecated to encourage use of the new methods and identify other call sites that need to be updated?
There was a problem hiding this comment.
Not sure if it is better. With deprecated, user will still have to implement them later. Can it work as we expect?
There was a problem hiding this comment.
@MabelYC what do you mean? I'm suggesting that we add the annotation to mark them as deprecated (e.g. https://www.baeldung.com/java-deprecated). We will not remove the older methods. This will mean that when some code calls the older methods, the author will get build time warnings that the method they're calling is deprecated, so that they can start using the new (better) method instead.
There was a problem hiding this comment.
@prateekm make sense. Marked theme as @deprecated.
| /** | ||
| * This function provides an extra input parameter than {@link #getConsumer}, which can be used to provide extra | ||
| * information e.g. ownership of client instance, to helper better identify consumers in logs, | ||
| * threads and client instances etc., along with other relevant information like systemName |
| * @param systemName The name of the system to create consumer for. | ||
| * @param config The config to create consumer with. | ||
| * @param registry MetricsRegistry to which to publish consumer specific metrics. | ||
| * @param consumerLabel a string used to provide info the consumer instance. |
There was a problem hiding this comment.
" a string to provide extra info for the consumer instance."
| * @param systemName The name of the system to create producer for. | ||
| * @param config The config to create producer with. | ||
| * @param registry MetricsRegistry to which to publish producer specific metrics. | ||
| * @param producerLabel a string used to provide info the producer instance. |
| /** | ||
| * This function provides an extra input parameter than {@link #getAdmin}, which can be used to provide extra | ||
| * information e.g. ownership of client instance, to helper better identify admins in logs, | ||
| * threads and client instances etc., along with other relevant information like systemName |
|
|
||
| /** | ||
| * This function provides an extra input parameter to {@link #getConsumer}, which can be used to provide extra | ||
| * information for the consumer instance, e.g. ownership of client instance, to helper better identify consumers in logs, |
|
|
||
| /** | ||
| * This function provides an extra input parameter to {@link #getProducer}, which can be used to provide extra | ||
| * information for the producer instance, e.g. ownership of client instance, to helper better identify producers in logs, |
|
|
||
| /** | ||
| * This function provides an extra input parameter to {@link #getAdmin}, which can be used to provide extra | ||
| * information for the admin instance, e.g. ownership of client instance, to helper better identify admins in logs, |
improve SystemFactory interface by providing user-defined clientId prefix so that we can access more information of the clients created: with changes, user can add specific clientId prefix for clients to help monitor clients.
API Changes: Added three default functions in SystemFactory. Since they are default functions, they won't make any impact to current users.
Upgrade Instructions: N/A
Usage Instructions: To use the new default functions, user will need to redefine them in their implementation class. And then user can set specific clientId.