I put this on the roadmap
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3848146#3848146
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3848146
---
This SF.Net email i
I'd suggest to make use of the oswego concurrent library instead of using simple
synchronisation.
e.g. use EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap instead of
HashMap
this will both:
- enshure we use the 'best-of-breed' solution for concurrent access
- be as close as possib
We cannot let logging introduce errant behavior. If the info required for logging
cannot be obtained in a thread safe manner without undue performance impact, then we
do need to guard against failures due to the unsafe access and catch the exception.
View the original post :
http://www.jboss.o
Would you be happy if the printXXX() and toString() methods would catch(Throwable) and
not propagate it ?
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3847850#3847850
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&
my company (10 empl., several hundred instances of J2EE-application-servers) is
planning to use JBoss application-server in production starting 2005. I'll be
technically responsible for this.
>From an enterprise customers standpoint anything that is known to fail 'every now and
>then' is not
bela:
the price is that a business-transaction might fail just because loglevel is set to
'INFO'
I don't think this is a real good idea.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3847821#3847821
Reply to the post :
http://www.jboss.org/index.html?m
Yes. I'm willing to pay the price for occasional exceptions though in print() methods,
but would not want to synchronize them at all.
Norbert et al: Keep those bug reports coming !
Bela
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3847771#3847771
Reply to
I think this is a good point. I can see this exception probably doesn't happen that
often with REPEATABLE_READ and up. But with more relaxed isolation levels, it can be a
problem.
Bela and I will be meeting soon. We should visit issue. What do you think, Bela?
-Ben
View the original post :
ht
btw:
this is not just an issue of debugging - other methods like the various 'printInfo()'
(even in TreeCache()) eventually throwsConcurrentModificationException when being
called while the cache is in use.
If we want to keep the underlying Collections unsynchronized for performance-reasons,
w
e.g. in NodeMap it dosn't help that the method readerOwners() is synchronized, but the
Collection (readOwnerList_) being returned by it being unsynchronized.
It wouldn't even help to make the IdentityLock.toString()-method synchronized, since
the JVM's lock on the IdentityLock instance does not
I've notices these kind of exceptions in many areas of jboss-cache's 'toString()'
methods...
It's because all the Collections being used (e.g. ArrayList for readOwnerList in
LockMap.java, HashMap for data in Node.java ... ) are all unsynchronized and throw
ConcurrentModificationException whenev
11 matches
Mail list logo
