Environment variable for "service.registry" map name

[GioF71]

Describe the feature

DefaultServiceDiscoveryBackend uses the map named "service.registry". Such constants is hard-coded. This is generally not a limitation, but say you want to use Ignite as backend, and also want share (especially for testing environments and maybe due to some operational or organizational constraints) the same Ignite instance across multiple environments, it might be helpful to be able to select a different map name through the use of an environment variable (proposed name: VERTX-SERVICE-DISCOVERY-MAP-NAME). The mentioned variable should of course not be mandatory and the code should maintain "service.registry" as a default value.

Use cases

I would like to share the same instance of Ignite as the backend for service discovery, so I need that each instance uses a different map (a different cache for Ignite).

Contribution

I am volunteering to implement this feature. I will present a pull request as soon as possible.

[tsegismont]

Can you elaborate on the use case?

I don't understand how you can have the same Ignite instance for different Vert.x clusters.

[GioF71]

Hello @tsegismont, it's a specific issue I am currently facing at my company. Due to licensing and resource constraints, for the development and staging environments we currently need to share the same instance of GridGain. With this change to the vertx-service-discovery code base, I could effectively use two distinct caches for service discovery, named e.g. dev.service.registry and staging.service.registry and thus be able to share the same GridGain instance.

Thank you for your attention.

[tsegismont]

Sorry but I still don't understand how you can use the same instance of GridGain to build separate Vert.x clusters. From the Ignite cluster manager POV, the dev and staging nodes would be part of the same Vert.x cluster.

[GioF71]

Your considerations make me doubtful about some choices that have been made about the definition of our testing environments.

So if I understand correctly your comment, you are telling me that I should avoid to share the same gridgain instance across different Vert.x clusters.

If (hypothetically) you merged this PR, I would be able to be using two distinct "service.registry" caches, one for each environment, but it would still be a bad idea to use the same GridGain instance.

Am I intrepreting correctly?

Thank you.

[tsegismont]

So if I understand correctly your comment, you are telling me that I should avoid to share the same gridgain instance across different Vert.x clusters.

To my knowledge, the Ignite cluster manager (like other cluster managers) cannot use the same grid instance for different clusters. @zyclonite can you confirm?

If (hypothetically) you merged this PR, I would be able to be using two distinct "service.registry" caches, one for each environment, but it would still be a bad idea to use the same GridGain instance.

If the PR was merged, nodes of of testing and staging environments would use a distinct cache as discovery backend, but they would still be part of the same Vert.x cluster.

[zyclonite]

To my knowledge, the Ignite cluster manager (like other cluster managers) cannot use the same grid instance for different clusters. @zyclonite can you confirm?

this is correct, to my knowledge, this is not supported by ignite. you will face the same issues for all __vertx.* share maps (ignite caches) as well...

[GioF71]

Thank you @tsegismont and @zyclonite for your feedbacks, you have been very helpful. We can probably decline the PR and close the issue.