[jboss-user] [JBossCache] - Re: JBC 2 performance

"[EMAIL PROTECTED]" wrote : | I don't bother protecting/synchronizing the maps [...] as I assume that any locking happens on a higher level | Oh, I see. So it should work with the raw HashMap's then, since the locks take care of the synchronization. "[EMAIL PROTECTED]" wrote : | Perfor

[jboss-user] [JBossCache] - Re: JBC 2 performance

"aditsu" wrote : Hm.. I'm not sure how it's related, but it sounds very good. I don't bother protecting/synchronizing the maps in a node when accessed via the XXDirect() calls as I assume that any locking happens on a higher level (see javadocs on NodeSPI). So clearly this higher-level sync was

[jboss-user] [JBossCache] - Re: JBC 2 performance

Hm.. I'm not sure how it's related, but it sounds very good. I updated again from CVS; it seems to work now and doesn't do MapCopy anymore. The performance is still not really great, but it may not be JBC's fault. I'll keep profiling. Thanks for the good work! View the original post : http://

[jboss-user] [JBossCache] - Re: JBC 2 performance

Thanks for this - this stuff has actually led to finding a pretty critical bug in the PessimisticLockInterceptor which was previously hidden away due to excessive synchronization in the node. See JBCACHE-1157 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4

[jboss-user] [JBossCache] - Re: JBC 2 performance

Thanks, I updated from CVS and the first thing I found is a NPE: java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:846) at java.util.concurrent.ConcurrentHashMap.putAll(ConcurrentHashMap.java:888) at org.jboss.cache.Unve

[jboss-user] [JBossCache] - Re: JBC 2 performance

Sorry, yes, this is patched in CVS HEAD. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068541#4068541 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068541 ___ jboss-user mai

[jboss-user] [JBossCache] - Re: JBC 2 performance

So.. is this problem going to be solved? Just in case you were waiting, I confirm that I'm using READ_COMMITTED Adrian View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068442#4068442 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode

[jboss-user] [JBossCache] - Re: JBC 2 performance

"[EMAIL PROTECTED]" wrote : what isolation level are you using? I think it was READ_COMMITTED (I can't see the code right now) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066378#4066378 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posti

[jboss-user] [JBossCache] - Re: JBC 2 performance

what isolation level are you using? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066202#4066202 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066202 ___ jboss-user mailing

[jboss-user] [JBossCache] - Re: JBC 2 performance

Hm, Notifier.copy now thinks the data is unsafe (it's not a MapCopy instance anymore) so it makes a new copy. If I prevent that from happening, the ConcurrentModificationException goes away. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066132#4066132 Reply

[jboss-user] [JBossCache] - Re: JBC 2 performance

"aditsu" wrote : This is not really related to the original message Hm.. or is it? I've just noticed the MapCopy in the trace View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066123#4066123 Reply to the post : http://www.jboss.com/index.html?module=bb&op=postin

[jboss-user] [JBossCache] - Re: JBC 2 performance

"[EMAIL PROTECTED]" wrote : http://jira.jboss.com/jira/browse/JBCACHE-1148 | Awesome! I decided to get JBossCache from CVS and try it. I haven't checked the performance, but I still got the concurrency problems: java.util.ConcurrentModificationException at java.util.HashMap$HashIterat

[jboss-user] [JBossCache] - Re: JBC 2 performance

"aditsu" wrote : Hi, I've just found a similar problem in CacheImpl: various methods (such as _put) call getDataDirect() on a node, which again does a MapCopy, and slows down the code a lot. This is with 2.0.0.CR3. Can you please check? http://jira.jboss.com/jira/browse/JBCACHE-1148 View the

[jboss-user] [JBossCache] - Re: JBC 2 performance

Besides that, I also got a bunch of ConcurrentModificationException's while doing a multi-threaded benchmark just now: java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:841) at java.util.HashMap$EntryIterator.next(HashMap.java:883)

[jboss-user] [JBossCache] - Re: JBC 2 performance

Hi, I've just found a similar problem in CacheImpl: various methods (such as _put) call getDataDirect() on a node, which again does a MapCopy, and slows down the code a lot. This is with 2.0.0.CR3. Can you please check? Thanks Adrian View the original post : http://www.jboss.com/index.html?mod

[jboss-user] [JBossCache] - Re: JBC 2 performance

Thanks for this - getChildrenMapDirect() was really created as a temporary measure to map 1.4.x internal APIs. Ideally calling code should not use this deprecated method, as there are better ways of doing this. I've created a JIRA task for refactoring this - JBCACHE-1116 View the original p