[Design of JBossCache] - Re: Gravitation and POJO Cache
by bstansberry@jboss.com
For FIELD repl I'd basically have to start and stop a PojoCacheSession on the way in and out for each request. Certainly doable.
I wonder though if the overhead of managing all this exceeds that created by just always setting the option internal before resolving the reference. (Of course don't set it if BR is disabled or autoDataGravitation=true.) Besides the work of setting the option, here's what's wasted if a call hits the DataGravitatorInterceptor for a node that doesn't need gravitation:
if (isGravitationEnabled(ctx) && MethodDeclarations.isGetMethod(m.getMethodId()))
| {
| // test that the Fqn being requested exists locally in the cache.
| Fqn fqn = extractFqn(m.getMethodId(), m.getArgs());
| if (log.isTraceEnabled()) log.trace("Checking local existence of fqn " + fqn);
| if (BuddyManager.isBackupFqn(fqn))
| {
| log.info("Is call for a backup Fqn, not performing any gravitation. Direct calls on internal backup nodes are *not* supported.");
| }
| else
| {
| if (cache.peek(fqn, false) == null)
One thing I notice here is my statement last night about gravitation occuring on a put seems incorrect (see first if statement). I don't know if something changed, or if my year old memory of the issues I was seeing with BR when used for session repl is faulty. There were definitely problems related to greatly excessive gravitation calls that were solved by setting autoDataGravitation=false and using the option. I'll have a look at the old forum posts; IIRC Manik and I sorted it out on the forums.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4056918#4056918
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4056918
18 years, 9 months
[Design the new POJO MicroContainer] - Annotation Deployer
by bill.burke@jboss.com
I want to create two deployers.
* An annotation deployer that creates a map of Javassist ClassFile objects for all classes in the Deployment Unit's classpath and attaches this map to the DeploymentUnit. Annotation driven deployers like EJB3, would use this cache to scan for annotations. This deployer exists solely for performance reasons. We don't want more than one deployer scanning and reparsing .class files to create Javassist objects just to figure out whether it should process the archive. Another feature of the deployer woudl be the ability to fine tune scanning.
- A META-INF/.noscan file. If this file exists in the archive, the annotation deployer will not create the javassist cache. (no scanning)
- A META-INF/.ignore-scan file that allows you to list archives you don't want scanned.
* The second deployer is just to clean up this cache.
I've had a few people complain about boottime performance both on forums and support cases. This would help to alleviate this problem.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4056908#4056908
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4056908
18 years, 9 months