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
Config validation is broken #3257
Comments
The Config.isCompatible is not called apart from in a unit test. So currently there is no validation. |
Apparently it is broken since Hazelcast 3.0. In 2.x the whole config was send to the remote machine. In 3.x the ConfigCheck is used and the Config.isCompatible isn't used at all. The ConfigCheck doesn't cover enough fields to make it useful. |
There is another bug. If the cluster configuration doesn't match, instead of letting the joining member crash, it will create its own cluster. This is a violation of the fail fast principle. So we need to get this fixed as well. |
Fixed the issue that not a lot of config validation is done. It also fixes the issue that in some cases instart of shutting down the node, due to the config conflict, a seperate cluster is created. This patch doesn't contains logic for structural checking of conflicts for map/queue etc. But it does contain all the infrastructure. It also contains the feature where a user can provide a 'token' to that needs to be the same on all members. E.g. filepath or other configuration settings. This can be done through the hazelcast.application.validation.token system property.
There is no good working validation of configuration when members join. See the following example:
The following logging:
But this exception is internal catched and logged; so the application keeps running.
The text was updated successfully, but these errors were encountered: