Skip to content
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

Incorrect null log message in Delegating Address Picker #11783

Closed
smillidge opened this issue Nov 13, 2017 · 9 comments
Closed

Incorrect null log message in Delegating Address Picker #11783

smillidge opened this issue Nov 13, 2017 · 9 comments

Comments

@smillidge
Copy link

@smillidge smillidge commented Nov 13, 2017

The log message of Delegating Address Picker uses the wrong variable here
https://github.com/hazelcast/hazelcast/blob/master/hazelcast/src/main/java/com/hazelcast/instance/DelegatingAddressPicker.java#L63

The line should be

logger.info("Using bind address: " + bindAddress);
@jerrinot jerrinot added this to the 3.9.1 milestone Nov 13, 2017
@jerrinot
Copy link
Contributor

@jerrinot jerrinot commented Nov 13, 2017

@smillidge: many thanks for reporting this. I am glad to see there are already users of MemberAddressProvider!

@smillidge
Copy link
Author

@smillidge smillidge commented Nov 13, 2017

I'd rather not be a user ;-) but Hazelcast seems to reject many network connections based purely on the address chosen at boot. In my case the computer has two networks docker0 and eth0 and Hazelcast keeps choosing docker0 and rejecting connections from the LAN.

@jerrinot
Copy link
Contributor

@jerrinot jerrinot commented Nov 14, 2017

Thanks Steve, this is useful to know. I agree Hazelcast should work out-of-the-box in your case and you shouldn't be forced to implement you own address picking strategy. Let's see what we can do about it.

related to #11504

@smillidge
Copy link
Author

@smillidge smillidge commented Nov 15, 2017

What is the use case that Hazelcast is implementing when it refuses connections that do not have the same "name"? It also refuses connection attempts that use IPv6 over IPv4 just because the "name" doesn't match. This will come a bit of a nightmare in a multi-homed network and as we proliferate more and more virtual interfaces for docker et al.

mmedenjak added a commit to mmedenjak/hazelcast that referenced this issue Nov 21, 2017
mmedenjak added a commit to mmedenjak/hazelcast that referenced this issue Nov 21, 2017
@mmedenjak
Copy link
Contributor

@mmedenjak mmedenjak commented Nov 21, 2017

@smillidge some checks were added as security checks but I agree that some checks don't make sense and are making deployment harder. We're working on improving this and any input is welcome.

@smillidge
Copy link
Author

@smillidge smillidge commented Nov 21, 2017

I don't understand the security argument. I can lock down the network security simple enough via firewall rules. You also have cluster name, password and then all the security features in Hazelcast Enterprise. Simplest change would be a flag to switch the check off.

@mmedenjak
Copy link
Contributor

@mmedenjak mmedenjak commented Nov 21, 2017

Just to be clear, which check are you referring to?

@mmedenjak
Copy link
Contributor

@mmedenjak mmedenjak commented Nov 21, 2017

This issue was closed since the initial log message was fixed and will be released with 3.9.1. Please open a new issue (or elaborate here) with which check is rejecting the connections. We have numerous checks and it is possible the check was added because of a specific reason or the check is a defect and could be fixed or improved.

@smillidge
Copy link
Author

@smillidge smillidge commented Nov 21, 2017

There's already an issue open #9219 for the checks.

emre-aydin added a commit to emre-aydin/hazelcast that referenced this issue Nov 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

3 participants
You can’t perform that action at this time.