Skip to content

KAFKA-2512: Add version check to broker and clients.#200

Closed
becketqin wants to merge 4 commits into
apache:trunkfrom
becketqin:KAFKA-2512
Closed

KAFKA-2512: Add version check to broker and clients.#200
becketqin wants to merge 4 commits into
apache:trunkfrom
becketqin:KAFKA-2512

Conversation

@becketqin
Copy link
Copy Markdown
Contributor

No description provided.

@asfbot
Copy link
Copy Markdown

asfbot commented Sep 9, 2015

kafka-trunk-git-pr #380 FAILURE
Looks like there's a problem with this pull request

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think this can instead be:

@Test(expected = classOf[UnsupportedVersionException])
def testInvalidMagicByte() {
  // Create a message
  val message = new Message("value".getBytes, "key".getBytes, NoCompressionCodec)
  message.buffer.put(Message.MagicOffset, (Message.CurrentMagicValue + 1).toByte)
  message.buffer.putInt(Message.CrcOffset, (message.computeChecksum() & 0xffffffffL).toInt)
  message.ensureValid()
}

@asfbot
Copy link
Copy Markdown

asfbot commented Sep 9, 2015

kafka-trunk-git-pr #384 FAILURE
Looks like there's a problem with this pull request

@becketqin
Copy link
Copy Markdown
Contributor Author

The test failure seems not related. Ran the test again locally and it passed.

@ewencp
Copy link
Copy Markdown
Contributor

ewencp commented Sep 11, 2015

This mostly looks good to me, but I think we're only testing the magic byte errors in this patch? What about a test for at least one or a couple of the KafkaApis checks for version errors?

@becketqin
Copy link
Copy Markdown
Contributor Author

@ewencp Fair point about the unit test. I didn't write unit test before because it might be a bit hacky and I think the right way to do it is to add test after we have protocol version control on clients. I added unit test and did find an issue with new java class protocol. The test itself is a bit hacky but should be good for now. We need to write better test after we have client protocol version control. I'll create a ticket to track this.

@asfbot
Copy link
Copy Markdown

asfbot commented Sep 14, 2015

kafka-trunk-git-pr #422 SUCCESS
This pull request looks good

Comment thread checkstyle/import-control.xml Outdated
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.

Indenting?

@guozhangwang
Copy link
Copy Markdown
Contributor

@becketqin Is this already incorporated in your timestamp patch?

@ijuma
Copy link
Copy Markdown
Member

ijuma commented Jan 29, 2016

If it's not, it needs to be rebased.

@ijuma
Copy link
Copy Markdown
Member

ijuma commented Feb 24, 2016

It would be nice to rebase this.

//TODO: this method should only use request.header after all the requests are migrated to use client java request class.
// For the requests using old scala class, we need to pass in the API version explicitly because the Request.header will
// be null. For requests using new java class. the API version will be None.
def validateRequestVersion(request: RequestChannel.Request, apiVersion: Option[Short]) {
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.

Can this all be handled in RequestChannel or before the big match statement in KafkaApis so we are guaranteed to have all messages checked?

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 agree that it would be better if we can do it that way.

@becketqin
Copy link
Copy Markdown
Contributor Author

@granthenke @ijuma @guozhangwang Sorry for the belated response, I just saw your comments. I will rebase the patch. The version check on this patch makes sense, but the returned unsupported version might will only work for the responses that have an error code field. With KIP-35 a well behaved client should not send unsupported API version to the broker. But from the broker's point of view, we probably still need to handle this in case there are some problematic clients.

I will rebase this and update the PR. Thanks.

@granthenke
Copy link
Copy Markdown
Member

@becketqin Will you have a chance to rebase this soon?

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.

10 participants