2:48 p.m.
----- Original Message -----
From: "Sanne Grinovero" <sanne(a)infinispan.org>
To: "infinispan -Dev List" <infinispan-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev