[Design of JBossCache] - Defining eviction regions as regular expressions
by galder.zamarreno＠jboss.com
This post is related to Brian's post re: "Optimistic locking doesn't scale well with large 'flat' cache": http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112462
As Brian mentioned, the customer has some eviction issues with those structural/bucket style nodes created.
These buckets allow to spread the nodes through different levels, making the child maps smaller. However, this buckets/structural nodes make the evictions run earlier than they would expect.
This is what I had in mind to get around it:
1.- We could enable specification of non static eviction regions, for example via regular expressions.
2.- Each region allows us to define a specific policy for it, so we could create one that processes any region that matches this regular expression. Regions are created on startup, but could be created them on the fly, as we find Fqns that match the regular expression.
3.- Creating a regular expression for a region like x/y/z where x,y, and z are numbers should be easy (customer were using hascodes for the bucket fqn names). Java variable/class/package names cannot be just numbers so you would avoid misleading a bucket region from a non bucket region. This would be handy in the 2nd level cache spectrum. Customer built caches could define their own buckets.
4.- The Eviction algorithm in the process(Region) call, could take the regular expression, find any regions that match them and then call this.processQueues(region) for each of these regions, and finally empty the queues and prune.
5.- Finding an quick way to match Regions based on a regular expression would require further thought (meaning, I need to look into it :) ).
This might give us a lot of flexibility in the long term on how evictions regions are defined.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060911#4060911
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060911
18 years, 9 months
[Design of AOP on JBoss (Aspects/JBoss)] - AOP ClassLoader/Scoping for the VFSClassLoader
by adrian＠jboss.org
Now that I've done my "brain dump" on where I really want to get to
for the AOP scoping, here' s another one on some more immediate changes I need
to make for the VFSClassLoader integration.
The problem with the AOPScopedClassLoaderHelper and the
ScopedClass[Pool/Factory/Repository]
is that is assuming a simple hierarchical model.
That works for typical J2SE usage (with hierarchical classloaders)
or the JBoss UnifiedClassLoader (with hierarchical loader repositories)
but it doesn't work with the new classloader that has OSGi classloading rules.
With the OSGI style classloading rules a class can be deployed multiple times
(at different versions or as a private class to a deployment that is not shared).
The classloaders are also peers of each other and delegate to each other
(in a consistent way). This is similar to the JBoss UnifiedClassLoader
but it is not a delegate to everybody, there's no equivalent of a global repository
that defines the classloading space.
NOTE: In fact, the VFSClassLoader can emulate the old UnifiedClassLoader
rules with export/importAll policies but that is beside the point here.
So, as far as I can tell there needs to be the following changes in
the AOPSharedClassLoaderHelper abstraction.
1) All policy decisions need to be done inside the abstraction.
Currently the abstraction is too low level with some decisions being made
inside the AOP classes themselves.
2) The ScopedClassPool needs replacing with something that
doesn't assume that all classes are visible from the caller classloader.
I'm thinking that this can probably be done with the already existing
javassist ClassPath api, if we make an implement of this that hooks into
the ClassLoaderPolicy abstraction of the new classloader (the apis
are pretty similar at least in the concept of resource location).
3) I'm not sure the idea of "repository", at least at is it used by AOP, is rich enough.
I do have a notion of "ClassLoadingSpace"
(which is all classloaders that interact with each other consistently)
so maybe that is what could be used?
But it still doesn't really encapsulate the idea that classes can be deployed twice
inside a "space" if they are only used privately.
e.g. think two deployments that interact but they each have their own
version (possibly different version) of commons logging that isn't part of
their interaction api.
I'm going to try to implement it this way and see what problems I find.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060893#4060893
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060893
18 years, 9 months