-
Notifications
You must be signed in to change notification settings - Fork 13.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
KAFKA-4307 Inconsistent parameters between console producer and consumer #2161
Conversation
Thanks for the PR. A few comments:
|
Thanks for the review, I will start to work on the suggested modifications. I will update this pull request soon. |
f2b2775
to
0283187
Compare
@ijuma I updated the pull request, with the suggested modifications. I forgot to update the documentation but I will do that maybe this weekend or in the beginning of the next one. Also there are couple of files where I don't know how to proceed. |
0283187
to
c961062
Compare
Updated the pull request with the documentation, and I also fixed the stylecheck errors. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR. Left a couple of comments. Also, it would be good to rebase the branch.
.withRequiredArg | ||
.describedAs("broker-list") | ||
.ofType(classOf[String]) | ||
val bootstrapServerListOpt = parser.accepts("bootstrap-server", "REQUIRED (unless old producer is used): The bootstrap server list string in the form HOST1:PORT1,HOST2:PORT2.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand this. bootstrap-server
and broker-list
should be equivalent. The user should provide exactly one of the two. And it can be used with both old and new producers. bootstrap-server
is recommended going forward for consistency with the console consumer. I think you did it right for the VerifiableConsumer
, for example.
Also, we can call the val simply bootstrapServerOpt
.
.action(store()) | ||
.type(String.class) | ||
.metavar("HOST1:PORT1[,HOST2:PORT2[...]]") | ||
.dest("bootstrapServerList") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd call this just bootstrapServer
. Similarly elsewhere.
c961062
to
cf9da39
Compare
@ijuma Updated the PR with the suggested changes. |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
|
||
val useOldProducer = options.has(useOldProducerOpt) | ||
val topic = options.valueOf(topicOpt) | ||
val bootstrapServer = options.valueOf(bootstrapServerOpt) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The general pattern over all files should be that bootstrapServer
has the value of bootstrapServerOpt
or brokerListOpt
. Since we validate that only one of them can be set, this is OK. If we do it that way, we don't have to check two fields everywhere (or worse forget to check one of them like it seems to be happening here in getNewProducerProps
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohh sorry, yeah you are right. I have one question, why can the user use the old-producer with the bootstrap-server? The broker-list and the bootstrap-server uses different properties "metadata.broker.list" vs "bootstrap.servers".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's to make it easier for users. They don't have to switch the CLI param to switch between new/old producer. After all broker-list
is not the same as metadata.broker.list
either.
cf9da39
to
ffdfa9d
Compare
@ijuma thanks for the review. Updated the pull request as you suggested. |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the update, left one comment.
|
||
val useOldProducer = options.has(useOldProducerOpt) | ||
val bootstrapServer = List(bootstrapServerOpt, brokerListOpt).flatMap(x => Option(options.valueOf(x))).head |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be done after we validate arguments. Otherwise, we can get a NoSuchElementException if neither bootstrap-server
or broker-list
is passed by the user. Same for other classes. Worth adding a test for this.
@ijuma thanks for the review, updated the files. |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
@ewencp, do you think it's OK to include this in 0.10.2? It technically adds a command-line parameters to some tools, but that parameter already exists in a number of tools, it's just making them consistent. |
@ijuma I think it's fine as long as we're confident we didn't break compatibility anywhere. |
c22c73f
to
63310b9
Compare
Resolved the conflicts, made some modifications on testBrokerListAndBootstrapServerOptionMissing |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
@gwenshap if you have time can you please take a look? Thanks. |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Sorry for the delay. Can you please resolve the conflicts so that I can hopefully take a final look and we can finally merge this. |
No worries:). I resolved the conflicts and extended the stream docs. |
Refer to this link for build results (access rights to CI server needed): |
Resolved the conflicts. @ijuma if you have time can you please review? |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Yes, I started looking into this. I think there may be scope for some sharing of code. I'll share a sketch tomorrow. |
0ed3d82
to
9022239
Compare
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
9022239
to
e2bbd04
Compare
I believe this has been addressed by KIP-499, so closing this PR. |
@gwenshap please review