July 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBossCache] - Region management issues

by bstansberry＠jboss.com

Some unit test fixing Vladimir did has uncovered a change between 1.x and 2.0 in terms of region management. In 1.x there's no need to register a classloader with a region before you can activate it. I.e. the activation/inactivation feature did not require classloader registration. So, you could use the feature even if you didn't need to unmarshall using a special classloader. Let's discuss whether we care about that use case or not on a separate thread. :-) I just bring it up as an intro to a discussion about how region management works in 2.0: The requirement to register a classloader was introduced due to this in RegionManager.getReqion(Fqn, Region.Type, boolean) : | Region r = regionsRegistry.get(fqnToUse); | | // this is a very poor way of telling whether a region is a marshalling one or an eviction one. :-( | // mandates that class loaders be registered for marshalling regions. | if (type == Region.Type.ANY | || (type == Region.Type.MARSHALLING && r.getClassLoader() != null) | || (type == Region.Type.EVICTION && r.getEvictionPolicyConfig() != null)) | { | return r; | } This testing is designed to make it easy discriminate between regions used for eviction and those used for marshalling. As an alternative, how about getting rid of Region.Type and instead implement nesting of regions? Pseudo-code: | public Region(Fqn fqn, Region parent) | { | this.fqn = fqn; | this.parent = parent; | } | | public Region getParent() | { | return this.parent; | } | | public ClassLoader getClassLoader() | { | ClassLoader result = this.classLoader; | if (result == null && this.parent != null) | result = parent.getClassLoader(); | return result; | } | | // Same thing for getEvictionRegionConfig, etc. | We could possibly get rid of Region.Type. One problem I see with this approach is CacheMarshaller200.extractRegionFqn() could end up finding a region below the one where the classloader is registered, with the result that the marshalling fqn included with the region is bigger than it needs to be. E.g. Region high = cache.getRegion(Fqn.fromString("/a"), true); high.registerContextClassLoader(someCL); ... Region deep = cache.getRegion(Fqn.fromString("/a/b/c/d/e/f"), true); deep.setEvictionPolicyConfig(someConfig); (I can see any easy solution to that though, if we keep Region.Type as a hint to the getRegion() method).) A benefit of nesting is the eviction code should be able to find the EvictionPolicy much faster when a node that's experienced an event is far below the eviction region. RegionManager.getReqion(Fqn, Region.Type, boolean) current looks for the fqn in the region map, and then checks if it's the correct type. If not, it moves up to the fqn parent and tries that. Multiple map lookups. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066421#4066421 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066421

18 years, 5 months

1
0
0 / 0

[Design of JBoss Portal] - Re: current logged users

by sviluppatorefico

as just said, JMS could be a good idea. At the moment I used directly concurrent utils of java.util.concurrent of jdk 1.5.0. (can we to leave compliant with 1.4 ?). I created a jira (http://jira.jboss.org/jira/browse/JBPORTAL-1606) with an operative first patch about users online. For now it lets to see number of actual users and who is actually online. Next step I will add a persistend counter of users View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066413#4066413 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066413

18 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: New Locking Strategy Proposal for JBoss Cache

by FredrikJ

Allthough I'm not familiar enough with the code to understand every implication of the proposed implementation, I think that the idea is sound. I encountered blocking reads in our application which need to be addressed. In the end I constructed a local cache in front of the distributed cache. The local cache is updated by the distributed in a fashion where we never block readers. (Optimistically locking was not a perfect fit here, I might revise that in the future if I get the time). The blocking encountered was not only due to write locked nodes but also synchronization blocks. However, the local cache solved the issues and I now get very performant concurrent reading from the cache layers. If I haven't gotten this all backwards this is a bit similar to what you propose. And the implications by this is that you would infact be solving a real problem that at least we had to deal with. I think that given the application areas for a cache, fast, non-blocking read access is definitely crucial. And I would love to see it implemented in the core cache instead of a tacked on solution like mine. =) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066397#4066397 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066397

18 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MAVEN woven aop-mc-int tests no longer working

by Kevin.Conner＠jboss.com

Sorry Kabir, that would be my fault. I ran everything from the top level before checking in but not from there. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066393#4066393 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066393

18 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: static field replication in PojoCache

by jason.greene＠jboss.com

That interceptor was left over from an incomplete experimental implementation. Static field replication is currently planned for 2.1.0: [url]http://jira.jboss.com/jira/browse/JBCACHE-726[/ul] -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066355#4066355 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066355

18 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: static field replication in PojoCache

by korimilli

Is static field replication feature there in JBOSS Cache Release 2.0.0 CR3. I do see a staticFieldInterceptor class in the PojoCache.jar file. How do I use it? If not, when will this feature (time frame) be avaialble. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066335#4066335 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066335

18 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: JBPM_LOG issue

by thilker

Exactly the same happends to me. Is there a solution? Regards, Thorsten View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066304#4066304 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066304

18 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JIRA picture of MC work for JBossAS5 beta3

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | I don't see why the javassist stuff is appearing in the RC1 release? | That is low priority work that probably shouldn't even be assigned to a release. I've unscheduled this work. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066300#4066300 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066300

18 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JIRA picture of MC work for JBossAS5 beta3

by adrian＠jboss.org

I've created a JBossMC 2.0 beta4 release and assigned all the critical work other stuff that needs doing to it. Currently the outstanding work is: http://jira.jboss.com/jira/secure/IssueNavigator.jspa?reset=true&mode=hid... The other stuff is in the RC1 http://jira.jboss.com/jira/secure/IssueNavigator.jspa?reset=true&mode=hid... but if stuff gets finished before beta4 is released then just reassign the fix version. I don't see why the javassist stuff is appearing in the RC1 release? That is low priority work that probably shouldn't even be assigned to a release. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066297#4066297 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066297

18 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: JIRA picture of MC work for JBossAS5 beta3

by adrian＠jboss.org

On a related issue, there are a number of closed items in JIRA that don't have a "fixed version" http://jira.jboss.com/jira/secure/IssueNavigator.jspa?reset=true&pid=1231... These need correcting so they appear in the change log against the correct version. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066292#4066292 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066292

18 years, 5 months

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 July 2007