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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

From: "Sanne Grinovero" <sanne(a)infinispan.org&gt; To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org&gt; 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,

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev