Looking at the usage of this method, only code that passes in Region.Type.EVICTION is EvictionInterceptor.canIgnoreEvent(). And that can handle a null return just fine. So, seems we could safely replace the above with:
|
| // test if the default region has been defined. If not, and if the request
| // is for an eviction region, return null
| if ((nextBestThing != null && nextBestThing.getFqn().isRoot() && !regionsRegistry.containsKey(Fqn.ROOT))
| && type == EVICTION)
| {
| log.trace("No default eviction region; returning null");
| nextBestThing = null;
| }
|
Haven't looked carefully to see if the method contract implies it won't return null.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136054#4136054
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136054
Follow-on to our discussion on http://jira.jboss.org/jira/browse/JBCACHE-1288
Looking at RegionManager for other reasons and noticed this bit in getRegion(Fqn, Region.Type, boolean):
| // test if the default region has been defined. If not, and if eviction regions
| // are in use, throw an exception since it is required.
| if ((nextBestThing == null || nextBestThing.getFqn().isRoot() && !regionsRegistry.containsKey(Fqn.ROOT))
| && type == EVICTION)
| {
| if (log.isTraceEnabled())
| log.trace("Next best region is " + nextBestThing + ". RegionsRegistry contains a default? " + regionsRegistry.containsKey(Fqn.ROOT) + " Region type requested = " + type);
| throw new RuntimeException("No default eviction region defined!");
| }
|
Looks like we *are* enforcing a requirement for a _default_ region.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136049#4136049
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136049
Hi,
I noted the following inconsistencies:
If I declare an aspect name A (using jboss-aop.xml)
then i bind an advice b of A to a pointcut
and I bind it again to another pointcut
Two AdviceFactory objects with the same name will be created and the second one will push the first one out of the interceptorFactories map when it is registered
If I then redeclare the aspect A
the second Aspect A will push the first A out of the aspectDefinitions map and undeploy it.
The bindings however will stay active.
I have no idea about how these hidden aspects and interceptors influence the system, but they make it very hard to reflect on the state of the aspect system as one advice has multiple instances, of which only one can be retrieved.
Wouter
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136032#4136032
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136032
You mean, (1) wait for completion OR (2) cause TXs to get rolled back. Yes, this does become a problem but at least all it does is delay the instance joining the cluster and won't impact the existing instances.
"bela(a)jboss.com" wrote :
| Regarding proxying: who redirects the caller from A to B ? What if A has state e.g. pertaining to a session that is available only on A and its buddy C (but not B) ?
|
I would assume the proxying is done by an interceptor on A, and this interceptor would need to know where to proxy to.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136018#4136018
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136018