[infinispan-dev] Is it time to reduce the complexity of the CacheManager?

[Tristan Tarrant]

Yes, I agree with the rationale.
We should have some kind of entry point, a hypothetical "ClusterManager" 
which would handle common generic components (transport, thread pools, 
...) and be a factory for other subcomponents (CacheManagers and other 
clustered services). Dropping support for asymmetric clusters would mean 
reduced complexity and memory usage.

This gets a big +1 from me.

Tristan

On 19/02/2015 17:46, Sanne Grinovero wrote:
> All,
> at  the beginning of time, the expectation was that an application
> server (aka WildFly) would have a single CacheManager, and different
> applications would define their different Cache configuration on this
> app-server singleton.
>
> In that primitive world that sounded reasonable, as system
> administrators wouldn't want to manage firewalls and port assignments
> for a new Transport for each deployed application.
>
> Then the complexities came:
>   - deployments are asymmetric compared to the application server
>   - each deployment has its own ClassLoader
>   - deployments start/stop independently from each other
>
> At that point a considerable investment was made to get lazily
> starting Caches, per-Cache sets of Externalizer(s) to isolate
> classloaders, ClassLoader-aware Cache decorators, up to the recently
> introduced Cache-dependency rules for stopping dependant Caches last.
>
> Not to mention we have now a complex per-Cache View handling, which
> results in performance complexities such as ISPN-4842.
>
> There are some more complexities coming:
> Hibernate OGM wishes to control the context of deserialization - this
> is actually an important optimisation to keep garbage production under
> control, but also applications might want to register custom RPC
> commands; this has been a long standing problem for Search (among
> others).
> Infinispan Query does have custom RPC commands, and this just happens
> to work because the Infinispan core module has an explicit dependency
> to query.. but that's a twisted dependency scheme, as the module would
> need to list each possible extension point: it's not something you can
> do for all projects using it.
>
> Interestingly enough, there is a very simple solution which wipes out
> all of the above complexity, and also resolves some pain points:
> today the app server supports the FORK protocol from JGroups, so we
> can get rid of the idea of a single CacheManager per appserver, and
> create one per classloader and *within* the classloader.
>
> By doing so, we can delete all code about per-Cache classloaders,
> remove the CacheView concept, and also allow the deployment (the
> application) which is needing caching services to register whatever it
> wants.
> It could register custom interceptors, commands, externalizers,
> CacheStore(s), etc.. without pain.
>
> Finally, we could get rid of the concept that Caches start lazily. I'd
> change to a simplified lifecycle which expects the CacheManager to
> initialize, then allows Cache configurations to be defined, and then
> it all starts atomically.
> At that point, you'd not even be responsible anymore for complex
> dependency resolutions across caches.
>
> I'd hope this would allow OGM to get the features it needs, and also
> significantly simplify the definition of boot process for any user,
> not least it should simplify quite some code which is now being
> maintained.
>
> A nice follow-up task would be that WildFly would need to be able to
> "pick up" some configuration file from the deployment and inject a
> matching CacheManager, so this requires a bit of cooperation with the
> app server team, and an agreement on a conventional configuration
> name.
> This should be done by WildFly (and not the app), so that the user
> deployment can lookup the CacheManager by JNDI without needing to
> understand how to wire things up in the FORK channel.
>
> I also believe this is a winner from usability point of view, as many
> of the troubles I see in forums and customers are about "how do I
> start this up?". Remember our guides essentially teach you to either
> take the AS CacheManager, or to start your own. Neither of those are
> the optimal solution, and people get in trouble.
>
> WDYT?
>
> Sanne
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>


-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat