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

[Design of JBoss Serialization] - Re: Cleanup of project, move to maven, svn?

by anil.saldhana＠jboss.com

"scott.stark(a)jboss.org" wrote : I had a dyslexia attack as I was thinking of svn when you said maven. I see the maven pom.xml in the current cvs jboss-serialization project. | Skiing is the long-tested remedy for dyslexia. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999755#3999755 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999755

19 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: PojoCache uses a special node factory

by ben.wang＠jboss.com

"manik.surtani(a)jboss.com" wrote : you actually create: | | /_JBossInternal_/Bucket0-9/Node1 | /_JBossInternal_/Bucket0-9/Node2 | /_JBossInternal_/Bucket10-19/Node10 | /_JBossInternal_/Bucket10-19/Node11 | | which will reduce the contention on _JBossInternal_ as a direct parent. This will certainly help. Like you mentioned, this is problem more to the Cache usage itself. But it still will create contention though, and worse still can cause some lock timeout, say, when "/_JBossInternal_/Bucket0-9/Node1" tries to create another sub-node at "/_JBossInternal_/Bucket10-19/Node10", and meanwhile "/_JBossInternal_/Bucket10-19/Node11" tries to create a sub-node at "/_JBossInternal_/Bucket0-9/Node2" within the same transaction. I am thinking another solution (in addition to the above option) is to allow user-specified bucket. For example, if you are using the core Cache, and you want to reduce lock contention and have the freedom to organize your fqn, then, the following will have high concurrency, | // pre-create the node "/a", and "/b" first. | | // From thread 1 | loop(i=1:100) | { | cache.put("/a/1", k1, o1); | } | | | // From thread 2 | loop(i=1:100) | { | cache.put("/b/1", k1, o1); | } | Granted not all use case can have this leeway to specify fqn like this. But when you can, this solution can perform well. So in similar token, I am thinking to allow an option for PojoCache user to pre-create the sub-tree in "__JBossInternal__". Let's take an example, | pojoCache.attach("hr/joe", joe); | pojoCache.attach("eng/ben", ben); | | //from thread 1 | loop(i=0:100) | { | pojoCache.attach("hr/joe", joe); | } | | //from thread 2 | loop(i=0:100) | { | pojoCache.attach("eng/ben", ben); | } | Now, when we map them into "__JBossInternal__", we will map as: | cache.put("/__JBossInternal__/hr/joe, xxx) | and | cache.put("/__JBossInternal__/eng/ben, xxx) | respectively. That is we will add the prefix such as "hr/joe" and "eng/ben" under the internal fqn. In this case, except during the pre-creation stage, there won't be write lock contention. Of course, we pay the penalty of creating extra fqn hierarchy. Thought? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999735#3999735 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999735

19 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: Last chance for any changes to the 2.0.0 API

by manik.surtani＠jboss.com

"manik.surtani(a)jboss.com" wrote : | "genman" wrote : | | 4. Some of the NodeSPI data methods appear to be just convenience methods and aren't strictly necessary given that getDataDirect() returns an externally modifiable map. For instance, clearDataDirect() really just is the same as NodeSPI.getDataDirect().clear(). So, it would be nice to understand the reason for these extra methods. | | This is a good point. Will revisit thise. Their Node interface counterparts that went up the interceptor stack made sense, but the 'direct' versions do not. Actually, there is a good reason to still maintain these methods. At some point I plan to do away with synchronizing these methods, and have my own lock checks to ensure the caller has appropriate locks. And to do this, I need to make sure the Map returned to getDataDirect() is an unmodifiableMap. In fact, all read calls would return unmodifiableMap/Sets, and the only way to write in to them would be to use the write methods. Read and Write methods would then impose a check on the caller to see if appropriate locks are available, e.g., | pubic Map<Object, Object> getDataDirect() | { | if (!getLock().getReaderOwners().contains(Thread.currentThread())) | throw new LockingException(); | | // defensive copy + unmodifiable | return Collections.unmodifiableMap(new HashMap(data)); | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999722#3999722 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999722

19 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Aspect integration to bootstrap classes

by kabir.khan＠jboss.com

I have completed the first part of this, so that we get a proxy created for the MainDeployer. The AspectManager and AspectDeployer are now created in bootstrap-beans.xml, and I have moved these to the jboss/lib directory: -jboss-aop-jdk50.jar -jboss-aop-mc-int.jar -trove.jar -javassist.jar (was there already) -jboss-aop-deployer-jdk50.jar (The parts of the jboss-aspect-library.jar relating to deployment, i.e. org.jboss.aop.deployers and org.jboss.aop.deployment) The bootstrap-beans.xml initialises the AspectManager with the necessary aop.xml so that this is available when the MainDeployer is instantiated, so that we get a proxy created for that. I have kept the jboss-aop-jboss5.deployer, it now contains a bean called "AspectLibrary" whose job is to deploy the base-aspects.xml (containing the @SecurityDomain, @Tx etc. interceptors) and the old aspect library (minus the stuff that now lives in jboss-aop-deployer-jdk50.jar). Services that previously depended on the AspectDeployer, and which need the aspect library aspects, should now depend on the "AspectLibrary", I have updated EJB 3 to do this. I have created some stupid implementations of org.jboss.profileservice.aop.MainDeployerAspect and org.jboss.profileservice.aop.PersistAspect in the system module to verify that things work. MainDeployerAspect is functional, and I will look at the PersistAspect/ManagedProperty part tomorrow. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999719#3999719 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999719

19 years, 3 months

1
0
0 / 0

[Design of JBoss Serialization] - Re: Cleanup of project, move to maven, svn?

by scott.stark＠jboss.org

I had a dyslexia attack as I was thinking of svn when you said maven. I see the maven pom.xml in the current cvs jboss-serialization project. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999716#3999716 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999716

19 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: Last chance for any changes to the 2.0.0 API

by manik.surtani＠jboss.com

Good comments. "genman" wrote : | 1. putIfNull -> putIfAbsent, See http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ConcurrentMa... . People might get confused with "null" versus absent. | Agreed. "genman" wrote : | 2. Remove the print* methods in NodeSPI. Or at least document them. Consider creating a separate util class to print a node. | My issue with a separate util class is that it will mean maintaining yet another public interface/class. +1 to documenting them better. "genman" wrote : | 3. removeChildDirect(Fqn) and removeChildDirect(Object) is a little confusing, since Fqn is a subtype of Object. I would probably suggest just having one or the other. | It does look confusing, but for the sake of convenience - and a lot of unnecessary Fqn creation - it makes sense having the 'Object' version. Helps avoid a lot of unnecessary stuff like node.getChildDirect(new Fqn(childName)) which in turn simply does if (fqn.size() == 1) return children.get(fqn.getLastElement()); Justifying the Fqn version, it cleans up unnecessary and repeated looping in interceptors and CacheImpl searching for a child node several nodes deep. "genman" wrote : | 4. Some of the NodeSPI data methods appear to be just convenience methods and aren't strictly necessary given that getDataDirect() returns an externally modifiable map. For instance, clearDataDirect() really just is the same as NodeSPI.getDataDirect().clear(). So, it would be nice to understand the reason for these extra methods. This is a good point. Will revisit thise. Their Node interface counterparts that went up the interceptor stack made sense, but the 'direct' versions do not. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999715#3999715 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999715

19 years, 3 months

1
0
0 / 0

[Design of JBossCache] - Re: PojoCache uses a special node factory

by manik.surtani＠jboss.com

anonymous wrote : | NodeFactory should probably come from the RegionManager. | This only makes sense post-3.0, when we regionalise the entire cache. At the moment it won't make much sense. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999713#3999713 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999713

19 years, 3 months

1
0
0 / 0

[Design of JBoss Serialization] - Re: Cleanup of project, move to maven, svn?

by clebert.suconic＠jboss.com

"Scott" wrote : I don't see it under https://svn.jboss.org/repos/ so what is the repo for this? still on old CVS View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999709#3999709 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999709

19 years, 3 months

1
0
0 / 0

[Design of JBoss Serialization] - Re: Cleanup of project, move to maven, svn?

by scott.stark＠jboss.org

"clebert.suconic(a)jboss.com" wrote : I don't have any objections... I just didn't have time to do it before. | | Ruel had created a Maven build for jboss-serialization when he was working on maven scripts. It should be in good shape but I haven't tested it recently. | I don't see it under https://svn.jboss.org/repos/ so what is the repo for this? "clebert.suconic(a)jboss.com" wrote : | .. talking about this new xml output stream... you are considering using jboss-serialization to serialize objects into XML format? Did I understand that correctly? Yes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999695#3999695 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999695

19 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Full JMX functionality

by genman

What are the types for the List objects? If JBM requires JDK 1.5 it would be good to include them in the interface file. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999682#3999682 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999682

19 years, 3 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 January 2007