Skip to content

KAFKA-5674: max.connections.per.ip minimum should be 0#3610

Merged
hachikuji merged 2 commits into
apache:trunkfrom
viktorsomogyi:KAFKA-5674
Apr 2, 2018
Merged

KAFKA-5674: max.connections.per.ip minimum should be 0#3610
hachikuji merged 2 commits into
apache:trunkfrom
viktorsomogyi:KAFKA-5674

Conversation

@viktorsomogyi

Copy link
Copy Markdown
Contributor

No description provided.

@asfgit

asfgit commented Aug 2, 2017

Copy link
Copy Markdown

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk7-scala2.11/6499/
Test PASSed (JDK 7 and Scala 2.11).

@asfgit

asfgit commented Aug 2, 2017

Copy link
Copy Markdown

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/6484/
Test PASSed (JDK 8 and Scala 2.12).

@viktorsomogyi

Copy link
Copy Markdown
Contributor Author

@granthenke @andrasbeni @peter-toth could you please have a look?

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Hi @viktorsomogyi,

  • You need at least 2 network interface (including the loopback) to get this part tested.
  • I would use NetworkInterface.getNetworkInterfaces() to find an IP that is different to one assigned to "localhost". (InetAddress.getLocalHost may return with the IP of "localhost" on some weird configurations.)

@viktorsomogyi viktorsomogyi Aug 9, 2017

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

On a second thought, leaving it as it is. Using NetworkInterface makes it overly complicated as for instance on my laptop for instance there are many interfaces which makes it hard and cumbersome to choose the right one (and I don't expect this to be different on build servers either).
I think InetAddress.getLocalHost is good as supposing a correct machine configuration, it will return the right address.

@asfgit

asfgit commented Aug 14, 2017

Copy link
Copy Markdown

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk7-scala2.11/6742/
Test PASSed (JDK 7 and Scala 2.11).

@asfgit

asfgit commented Aug 14, 2017

Copy link
Copy Markdown

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/6727/
Test PASSed (JDK 8 and Scala 2.12).

@granthenke granthenke left a comment

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.

Overall looks good. Just one small comment. Thanks for the contribution.

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.

Do we need to add localPort? If we can use ephemeral ports thats preferred.

@asfgit

asfgit commented Aug 18, 2017

Copy link
Copy Markdown

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk7-scala2.11/6866/
Test PASSed (JDK 7 and Scala 2.11).

@asfgit

asfgit commented Aug 18, 2017

Copy link
Copy Markdown

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/6852/
Test PASSed (JDK 8 and Scala 2.12).

@viktorsomogyi
viktorsomogyi force-pushed the KAFKA-5674 branch 2 times, most recently from 3da41cb to 34af60d Compare August 30, 2017 00:14
@viktorsomogyi

Copy link
Copy Markdown
Contributor Author

@ijuma @ewencp could you please have a look at this? :)

@viktorsomogyi

Copy link
Copy Markdown
Contributor Author

retest this please

1 similar comment
@viktorsomogyi

Copy link
Copy Markdown
Contributor Author

retest this please

@viktorsomogyi

Copy link
Copy Markdown
Contributor Author

retest this please

@viktorsomogyi

Copy link
Copy Markdown
Contributor Author

@hachikuji would you mind reviewing this? It has been submitted a while ago and I rebased it yesterday on trunk. I'd like to get some feedback whether this feature makes sense and is eligible to be merged or anything else should be done.

@hachikuji hachikuji left a comment

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.

Thanks, I think this makes sense. Do you think it's worth mentioning the change in the upgrade notes?

Change-Id: Id9ba5d9205afc5e296c231e4e165a0089d846cc7
@viktorsomogyi

Copy link
Copy Markdown
Contributor Author

@hachikuji thanks for your quick response. I've added the upgrade notes under the 1.2 notes (hopefully this is the right place). Please let me know in case I should have added it elsewhere or if there are any grammatical mistakes in it.

.define(SocketReceiveBufferBytesProp, INT, Defaults.SocketReceiveBufferBytes, HIGH, SocketReceiveBufferBytesDoc)
.define(SocketRequestMaxBytesProp, INT, Defaults.SocketRequestMaxBytes, atLeast(1), HIGH, SocketRequestMaxBytesDoc)
.define(MaxConnectionsPerIpProp, INT, Defaults.MaxConnectionsPerIp, atLeast(1), MEDIUM, MaxConnectionsPerIpDoc)
.define(MaxConnectionsPerIpProp, INT, Defaults.MaxConnectionsPerIp, atLeast(0), MEDIUM, MaxConnectionsPerIpDoc)

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.

Not related to this PR. Can we also update the doc string of MaxConnectionsPerIpOverridesDoc.
Currently it is not clear about the format of the config string.

some thing like this:
A comma separated list of per-ip or hostname overrides to the default maximum number of connections. Example value is : hostName:100,127.0.0.1:200.

@hachikuji hachikuji left a comment

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.

LGTM. Thanks for the patch!

@hachikuji
hachikuji merged commit 1dc3027 into apache:trunk Apr 2, 2018
@viktorsomogyi
viktorsomogyi deleted the KAFKA-5674 branch August 23, 2018 13:10
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.

6 participants