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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev