Spring Boot automatically creates a Hazelcast instance when either Config bean exist or when it finds a configuration file.
This makes Hazelcast Jet hard to use in the Spring Boot container: Spring will try to create a new IMDG instance when it detects hazelcast.xml (or any other config file), but you probably want to start Jet instance.
It's actually even worst when you explicitly create a new Jet instance then it will try to create join with the IMDG instance created by Spring and this will fail with:
com.hazelcast.core.HazelcastException: Service with name 'hz:impl:jetService' not found!
at com.hazelcast.spi.impl.NodeEngineImpl.getService(NodeEngineImpl.java:367) ~[hazelcast-jet-3.2.1.jar:3.2.1]
at com.hazelcast.spi.Operation.getService(Operation.java:395) ~[hazelcast-jet-3.2.1.jar:3.2.1]
at com.hazelcast.jet.impl.operation.GetClusterMetadataOperation.run(GetClusterMetadataOperation.java:41) ~[hazelcast-jet-3.2.1.jar:3.2.1]
at com.hazelcast.spi.Operation.call(Operation.java:170) ~[hazelcast-jet-3.2.1.jar:3.2.1]
at com.hazelcast.spi.impl.operationservice.impl.OperationRunnerImpl.call(OperationRunnerImpl.java:210) [hazelcast-jet-3.2.1.jar:3.2.1]
at com.hazelcast.spi.impl.operationservice.impl.OperationRunnerImpl.run(OperationRunnerImpl.java:199) [hazelcast-jet-3.2.1.jar:3.2.1]
at com.hazelcast.spi.impl.operationservice.impl.OperationRunnerImpl.run(OperationRunnerImpl.java:416) [hazelcast-jet-3.2.1.jar:3.2.1]
at com.hazelcast.spi.impl.operationexecutor.impl.OperationThread.process(OperationThread.java:153) [hazelcast-jet-3.2.1.jar:3.2.1]
at com.hazelcast.spi.impl.operationexecutor.impl.OperationThread.process(OperationThread.java:123) [hazelcast-jet-3.2.1.jar:3.2.1]
at com.hazelcast.spi.impl.operationexecutor.impl.OperationThread.run(OperationThread.java:110) [hazelcast-jet-3.2.1.jar:3.2.1]
Caused by: com.hazelcast.spi.exception.ServiceNotFoundException: Service with name 'hz:impl:jetService' not found!
... 10 common frames omitted
Related issue in the Hazelcast Jet repo: https://github.com/hazelcast/hazelcast-jet/issues/1835
Comment From: pivotal-issuemaster
@jerrinot Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.
Comment From: pivotal-issuemaster
@jerrinot Thank you for signing the Contributor License Agreement!
Comment From: snicoll
@jerrinot thank you very much for the PR but I am not keen to proceed with this approach for the time being. Spring Boot doesn't know anything about Jet and having such back-off feels like the wrong approach to me. Let's continue the discussion on hazelcast/hazelcast-jet#1835 to see if we couldn't come up with an approach that doesn't require that change.
Comment From: nfrankel
@jerrinot, instead of checking for the existence of the class, could we check for the existence of a hazelcast-jet.xml instead? (talked about it with @snicoll)
Comment From: snicoll
@jerrinot some feedback on the idea please? A file check looks less invasive to me and we can discuss where we can apply it. If you agree this is worth pursuing you can push an upgrade on your existing branch and let us know and we'll reopen this PR. Or we can have a look, please create a separate issue then.
Comment From: jerrinot
hi @snicoll, the problem is that It's perfectly legitimate to have hazelcast.xml, but no hazelcast-jet.xml on a classpath when using Hazelcast Jet. hazelcast.xml is still used to configure e.g. networking - you almost always need to configure it. While most of the time you are ok with defaults in hazelcast.jet.xml.
Comment From: snicoll
I think there is a misunderstanding. The idea is to check for the presence of a jet specific file (ie jet is on the classpath) rather than checking for a class using a FQN.
Comment From: jerrinot
I see! there is hazelcast-jet-default.xml inside hazelcast-jet.jar. Would it be OK to test presence of this file on a classpath?
Comment From: snicoll
If you feel that it is specific enough then yes.