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

[Paul Ferraro]

----- Original Message -----
> From: "Sanne Grinovero" <sanne at infinispan.org>
> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
> Sent: Thursday, February 19, 2015 11:46:11 AM
> Subject: [infinispan-dev] Is it time to reduce the complexity of the	CacheManager?
> 
> 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,

+1
This was something that was originally needed in AS6, but was made obsolete by the use of ModularClassResolver in AS7 and later.

> remove the CacheView concept, 

-1
So long as there is no such thing as a FORK view, I don't think we can get rid of Cache views - all you would succeed in doing is replacing it with a "cache manager" view (which would be equivalent to the FORK view).  However, I think the argument can be made that a cache manager vieww

> 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.

This makes sense - WildFly has its own mechanism for handling the lifecycle of dependent 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 have to ask, if the proposal is to create a 1:1 relationship between cache and cache manager, and to also link their lifecycle - why are these separate objects/concepts at all?

> 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
>