March 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBossCache] - Re: Requirement for _default_ eviction region

by bstansberry＠jboss.com

And, change the if test order so "type == EVICTION" comes first. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136055#4136055 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136055

18 years

1
0
0 / 0

[Design of JBossCache] - Re: Requirement for _default_ eviction region

by bstansberry＠jboss.com

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

18 years

1
0
0 / 0

[Design of JBossCache] - Requirement for _default_ eviction region

by bstansberry＠jboss.com

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

18 years

1
0
0 / 0

[Design of JBossCache] - Re: Eager state push on failure with Buddy Replication

by bstansberry＠jboss.com

Yes, "structural node" != "resident". I mean "structural node flag" and should be disciplined and use the exact terminology. :-) You're right, substituting one concept for the other isn't correct. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136039#4136039 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136039

18 years

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Inconsistent information in AspectManager

by Danamin

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

18 years

1
0
0 / 0

[Design of JBossCache] - Re: Eager state push on failure with Buddy Replication

by manik.surtani＠jboss.com

the problem with the resident flag is that it could be used for anything - arbitrarily marking a node such that it doesn't get evicted, etc. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136028#4136028 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136028

18 years

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Bugs in org.jboss.aop.advice.PerVmAdvice

by Danamin

Hi, I've been studying the JBoss AOP code an noticed a few migth-be-bugs PerVmAdvice:191 if there is only one advice it is assumed to be an Invocation, but if it is a subclass, the application can crash rather ungracefully PerVmAdvice:181 This condition can not occur (see line 107) Wouter View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136027#4136027 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136027

18 years

1
0
0 / 0

[Design of JBossCache] - Re: Eager state push on failure with Buddy Replication

by bstansberry＠jboss.com

OK, so you're talking about a case where Node B is Node A's buddy, but whatever application created region /JSESSION/localhost/webapp1 on A hasn't deployed on B. Yeah, that's a problem. If the "resident" flag were replicated that would be a better solution. That would be a good thing anyway, although it adds cost to replication/invalidation messages. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136026#4136026 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136026

18 years

1
0
0 / 0

[Design of JBossCache] - Re: New state transfer in JBoss Cache

by manik.surtani＠jboss.com

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

18 years

1
0
0 / 0

[Design of JBossCache] - Re: New state transfer in JBoss Cache

by jason.greene＠jboss.com

"bstansberry(a)jboss.com" wrote : So, I think we need to get a reasonable solution for the P/L and O/L cases ASAP. | We talked about P/L in Orlando, and basically, we just can't do efficient/concurrent state transfer with P/L so what we decided was to leave the old transfer mechanism in place for P/L, and use the modern solution for O/L and MVCC. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4136016#4136016 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4136016

18 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums March 2008