Skip to content

KAFKA-9026: Use automatic RPC generation in DescribeAcls#7560

Merged
ijuma merged 3 commits intoapache:trunkfrom
mimaison:KAFKA-9026
Jan 29, 2020
Merged

KAFKA-9026: Use automatic RPC generation in DescribeAcls#7560
ijuma merged 3 commits intoapache:trunkfrom
mimaison:KAFKA-9026

Conversation

@mimaison
Copy link
Copy Markdown
Member

Committer Checklist (excluded from commit message)

  • Verify design and implementation
  • Verify test coverage and CI build status
  • Verify documentation (including upgrade notes)

@ijuma
Copy link
Copy Markdown
Member

ijuma commented Nov 20, 2019

Thanks for the PR. Before I start the review, would you mind fixing the conflict please?

@mimaison
Copy link
Copy Markdown
Member Author

Thanks @ijuma, I've rebased on trunk

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we validating in the builder instead of the request?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's important to be able to create bogus Requests/Responses in order to validate error handling on the broker side. By validating in the Builder, we allow creating arbitrary objects via the constructor. I expect all callers to use the Builder.

This is what a few requests already do (CreateTopicsRequest, FindCoordinatorRequest, HeartbeatRequest) and I liked that pattern.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say it's important not to be able to create bogus requests. ;) We can introduce specific mechanisms for testing, but a public constructor for a request should do its own validation.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right! 👍

Copy link
Copy Markdown
Member

@ijuma ijuma left a 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, I left a few initial comments.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not necessary, right?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: no need for ()

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably remove this method. It makes it too easy to write highly inefficient code. See #7725 for an alternative approach.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Obsolutely! I've updated the logic to avoid that.

@mimaison
Copy link
Copy Markdown
Member Author

Thanks @ijuma for the review. I've pushed an update

Copy link
Copy Markdown
Member

@ijuma ijuma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the updates. A few more comments.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's pretty inefficient to create all these AclBinding instances, just to check for unknowns. Is it possible to avoid that?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should convert these tests not to rely on AclBinding unless they are testing prepareResponse specifically.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this is a serialization/deserialization test, I think it should not rely on prepareResponse.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is existing code, but is there a reason why we can't just do asJava instead of this?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this should be called fromBindings.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Many responses have a prepareResponse() method, so I thought it made sense to call it this way for consistency. If fromBinding() is clearer, I'm happy to update it

@ijuma
Copy link
Copy Markdown
Member

ijuma commented Nov 26, 2019

One additional suggestion: let's bump the protocol version and add support for flexible versions as per KIP-482.

private void validate(short version) {
if (version == 0) {
if (data.resourcePatternType() == PatternType.ANY.code()) {
data.setResourcePatternType(PatternType.LITERAL.code());
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried changing the JSON request definition but I couldn't get it to generate the right Data class so I've had to put this logic :(
As far as I can tell DeleteAclsRequest has the same requirement.

@mimaison
Copy link
Copy Markdown
Member Author

mimaison commented Dec 5, 2019

Thanks @ijuma for the feedback, I've pushed another update.

@ijuma
Copy link
Copy Markdown
Member

ijuma commented Jan 29, 2020

retest this please

@ijuma
Copy link
Copy Markdown
Member

ijuma commented Jan 29, 2020

One job passed and the other had a couple of unrelated flaky failures:

kafka.admin.ResetConsumerGroupOffsetTest.testResetOffsetsExportImportPlan
org.apache.kafka.connect.mirror.MirrorConnectorsIntegrationTest.testReplication

Copy link
Copy Markdown
Member

@ijuma ijuma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is in a good enough state to be merged. I'll then rebase my create/delete acls PR and we can make additional changes for consistency as part of that PR.

@ijuma ijuma merged commit 40b3517 into apache:trunk Jan 29, 2020
@mimaison
Copy link
Copy Markdown
Member Author

Thanks @ijuma

@mimaison mimaison deleted the KAFKA-9026 branch January 29, 2020 20:46
ijuma added a commit to confluentinc/kafka that referenced this pull request Feb 2, 2020
Conflicts and/or compiler errors due to the fact that we
temporarily reverted the commit that removes
Scala 2.11 support:

* SslAdminIntegrationTest: keep using JAdminClient,
take upstream changes otherwise.
* ReassignPartitionsClusterTest: keep using
JAdminClient, take upstream changes otherwise.
* KafkaApis: use `asScala.foreach` instead of
`forEach`.

# By Ismael Juma (3) and others
# Via GitHub
* apache-github/trunk: (22 commits)
  KAFKA-9437; Make the Kafka Protocol Friendlier with L7 Proxies [KIP-559] (apache#7994)
  KAFKA-9375: Add names to all Connect threads (apache#7901)
  MINOR: Introduce 2.5-IV0 IBP (apache#8010)
  KAFKA-8503; Add default api timeout to AdminClient (KIP-533) (apache#8011)
  Add retries to release.py script (apache#8021)
  KAFKA-8162: IBM JDK Class not found error when handling SASL (apache#6524)
  MINOR: Add explicit result type in public defs/vals (apache#7993)
  KAFKA-9408: Use StandardCharsets.UTF-8 instead of "UTF-8" (apache#7940)
  KAFKA-9474: Adds 'float64' to the RPC protocol types (apache#8012)
  KAFKA-9360: Allow disabling MM2 heartbeat and checkpoint emissions (apache#7887)
  KAFKA-7658: Add KStream#toTable to the Streams DSL (apache#7985)
  KAFKA-9445: Allow adding changes to allow serving from a specific partition (apache#7984)
  KAFKA-9422: Track the set of topics a connector is using (KIP-558) (apache#8017)
  KAFKA-9040; Add --all option to config command (apache#7607)
  KAFKA-4203: Align broker default for max.message.bytes with Java producer default (apache#4154)
  KAFKA-9426: Use switch instead of chained if/else in OffsetsForLeaderEpochClient (apache#7959)
  KAFKA-9405: Use Map.computeIfAbsent where applicable (apache#7937)
  KAFKA-9026: Use automatic RPC generation in DescribeAcls (apache#7560)
  MINOR: Remove unused fields in StreamsMetricsImpl (apache#7992)
  KAFKA-9460: Enable only TLSv1.2 by default and disable other TLS protocol versions (KIP-553) (apache#7998)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants