[infinispan-dev] Handling dynamic interdependencies of Hot Rod servers and filter/converters - Re: ISPN-3950

[Galder Zamarreño]

Hi guys,

Re: https://issues.jboss.org/browse/ISPN-3950

The aim here is to enable deployment of custom Hot Rod filter/converter instances to Hot Rod servers running on top of WF, following a similar model to that used for JDBC drivers.

I came up with an initial solution in [1] but it’s incomplete because it can only handle a single Hot Rod server definition [2]. Digging through this issue has uncoverered a little can of worms:

- It’s possible not only to have N Hot Rod connectors (read: servers) defined in the configuration and they can be added at runtime too via CLI/RHQ.

- Deployments of filter/converters can happen anytime, so we’ve enabled Hot Rod servers to be plugged with these at runtime. For the time being, we’ve agreed that if a filter/converter gets deployed, it’ll be applied to all Hot Rod servers.

I had an earlier chat with Emmanuel and he suggested having some kind of deployment processor that deals with the filter/converter deployments and registers them in some service.

The fun begins now, from my POV, it seems to me that Hot Rod connectors need to depend on the filter/converter deployment tracking service so that if a new Hot Rod connector is added at runtime, it can take all the filter/converter deployments to self. However, the opposite is also plausible, that the filter/converter tracking service depends on all Hot Rod connector services, and that when a filter/converter is deployed, it can be applied to all running Hot Rod servers. This seems like a chicken and egg problem :|

What would be the best approach to handle these type of scenarios?

Cheers,

[1] https://github.com/galderz/infinispan/commit/0a3b37fdab05603654ee81d9ff38784e3283a708
[2] https://github.com/infinispan/infinispan/pull/2742#discussion_r15750154
--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz