assigned @tsegismont and @cescoffier so you have a look at the issue and suggest a better resolution than the simplest one I could find: vert-x3/vertx-health-check@c3a1101

please discuss here.

@vietj note the same issue applies with vertx-infinispan

How about moving the Infinispan and Hazelcast health checks to the vertx-health-check repo?

that would make sense to me, WDYT @cescoffier ?

Yes, we can do this and make the health check project a multi-module project:

health-checks
infinispan-health-check
hazelcast-health-check

WDYT?

makes sense to me.

I can give a try this week before the first CR.

actually now I think about it, I am not inclined to do that because it means that

• one cannot make a cluster manager release independently of health-check
• health check has a dependency on 2 cluster managers and a bug in one of these cluster manager might prevent a release of the health check module

I think instead we should try to break the link from service-discovery to hazelcast (I don't know the nature of it for now), I believe that most integration should be done in cluster managers when it happens because those are terminal nodes of the stack build graph.

Hazlecast is used for testing service discovery when running in clustered mode.

yep I understand that, could we test like we do with vertx-web ?

vertx-web clustered session integration tests have been moved to cluster managers

That would be very weird to test the default backend of service discovery in the cluster managers:

1. it would duplicate the test, while it does not stress any particular hard topic
2. if we go this way, all tests testing in clustered mode will end up into the cluster managers - so the cluster managers will potentially depend on everything.

I think you should look at how it is done in vertx-web and the cluster managers.

Conversely it's weird to have this tested for Hazelcast and not Infinispan, Ignite and Zookeeper.

I picked the one that was considered as the default one.

I don't think putting tests in the cluster-managers is a good idea, especially for this case where we just want to check it works for this specific use case.

I think that for checking this feature functionnally, using the fake cluster manager is correct to be used

using the fake cluster manager is correct to be used

Agreed. Such tests participate in building a "tck" for cluster manager implementations.

Is the fake cluster manager using codecs?

Can we artificially increase the latency?

for which operations ?