February 2010 - jboss-dev-forums - Jboss List Archives

[EJB 3.0 Development] New message: "EJBTHREE-2024 Default timeout on EJB3 remoting socket connector"

by jaikiran pai

JBoss development, A new message was posted in the thread "EJBTHREE-2024 Default timeout on EJB3 remoting socket connector": http://community.jboss.org/message/527342#527342 Author : jaikiran pai Profile : http://community.jboss.org/people/jaikiran Message: -------------------------------------------------------------- https://jira.jboss.org/jira/browse/EJBTHREE-2024 As seen in recent Hudson build environment, the default client socket timeout (30 minutes) on EJB3 remoting connectors is a bit too high. IMO, a timeout of 10 minutes should probably be more than enough. I did not use any formula to arrive at that 10 minute value. Any thoughts on what the timeout should be? Or are we OK with 10 min timeout? -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/527342#527342

14 years, 11 months

1
0
0 / 0

[JBoss AOP Development] New message: "Field annotation using JBoss AOP"

by MK Song

JBoss development, A new message was posted in the thread "Field annotation using JBoss AOP": http://community.jboss.org/message/527339#527339 Author : MK Song Profile : http://community.jboss.org/people/mksong Message: -------------------------------------------------------------- Hello, I wanted to test 'field annotation' using JBoss AOP. However, the POJO, *BankAccount was not be able to be enhanced.* Is there the way to enhance it? * Very simple program has been attached. C:\..\JBossAOPTest4>ant Buildfile: build.xml prepare: compile: [delete] Deleting directory C:\tmp\aoptest\JBossAOPTest4\classes [mkdir] Created dir: C:\tmp\aoptest\JBossAOPTest4\classes [javac] Compiling 4 source files to C:\tmp\aoptest\JBossAOPTest4\classes aopc: [aopc] log4j:WARN No appenders could be found for logger (org.jboss.aop.instrument.InstrumentorFactory). [aopc] log4j:WARN Please initialize the log4j system properly. [aopc] [no comp needed] C:\tmp\aoptest\JBossAOPTest4\classes\bank\SecurityFieldAnnotation.class [aopc] [no comp needed] C:\tmp\aoptest\JBossAOPTest4\classes\bank\SecurityFieldAspect.class * [aopc] [no comp needed] C:\tmp\aoptest\JBossAOPTest4\classes\bank\BankAccount.class* [aopc] [no comp needed] C:\tmp\aoptest\JBossAOPTest4\classes\bank\Bank.class [aopc] Build Successful: 547 ms run-compile-time: [java] [DBG] credit: 777 BUILD SUCCESSFUL Total time: 3 seconds -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/527339#527339

14 years, 11 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: Profiling the dependency project"

by Kabir Khan

JBoss development, A new message was posted in the thread "Profiling the dependency project": http://community.jboss.org/message/527337#527337 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- I've reverted what I did and will take a proper look on Monday -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/527337#527337

14 years, 11 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: Profiling the dependency project"

by Kabir Khan

JBoss development, A new message was posted in the thread "Profiling the dependency project": http://community.jboss.org/message/527292#527292 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- > alesj wrote: > > > > Since installCallbacks and uninstallCallbacks are ConcurrentHashMaps, I think the read lock is unnecessary here in AbstractController: > Since I think callbacks are already used in some explicitly locked code (via Lock), > what about if we leave the locks and just change the callbacks to plain HashMap? > > Like discussed on the call, what is faster in a really-rare-concurrent env? > * lock + plain hash collection > * concurrent hash collection > > Jason, DML? I see we are adding them here (and similarly for removing them) protected <T> void addCallback(Object name, boolean isInstallPhase, CallbackItem<T> callback) { lockWrite(); try { Map<Object, Set<CallbackItem<?>>> map = (isInstallPhase ? installCallbacks : uninstallCallbacks); Set<CallbackItem<?>> callbacks = map.get(name); if (callbacks == null) { callbacks = new HashSet<CallbackItem<?>>(); map.put(name, callbacks); } callbacks.add(callback); } finally { unlockWrite(); } } So this needs some rethinking. Since callbacks is a plain HashSet and the user of getCallbacks() is iterating over them this code is broken. So we either make everything plain HashMap/Set, reintroduce the locks, and replace getContexts() with this method where we do the iteration (via addAll()) with the lock taken: /** * Get the matching callbacks. * * @param result the set to put any callbacks into * @param name demand name * @param isInstallPhase install or uninstall phase * @return The passed in result parameter. If it was null and callbacks were found a new set is created */ protected Set<CallbackItem<?>> addCallbacks(Set<CallbackItem<?>> result, Object name, boolean isInstallPhase) { lockRead(); try { Map<Object, Set<CallbackItem<?>>> map = (isInstallPhase ? installCallbacks : uninstallCallbacks); Set<CallbackItem<?>> callbacks = map.get(name); if (callbacks != null) { if (result == null) result = new HashSet<CallbackItem<?>>(); result.addAll(callbacks); } } finally { unlockRead(); } return result; } Or we make everything involved concurrent map set that would work too. I need to understand a bit better how this code is used. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/527292#527292

14 years, 11 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: Profiling the dependency project"

by David Lloyd

JBoss development, A new message was posted in the thread "Profiling the dependency project": http://community.jboss.org/message/527291#527291 Author : David Lloyd Profile : http://community.jboss.org/people/david.lloyd@jboss.com Message: -------------------------------------------------------------- > alesj wrote: > > > > Since installCallbacks and uninstallCallbacks are ConcurrentHashMaps, I think the read lock is unnecessary here in AbstractController: > Since I think callbacks are already used in some explicitly locked code (via Lock), > what about if we leave the locks and just change the callbacks to plain HashMap? > > Like discussed on the call, what is faster in a really-rare-concurrent env? > * lock + plain hash collection > * concurrent hash collection > > Jason, DML? Well, if you're already locking, concurrent hash maps will generally give you general throughput in the contended case; if there's only one contender then there's only one lock acquisition so it's a wash, on paper. In reality, a CHM is actually a bit more complex, and it's also a really big structure (even if it's empty), consisting of a ReentrantLock for each lock stripe, each of which includes a bunch of stuff, so you get another kind of savings by using a simple synchronized map. In fact I'm hesitant to ever use CHM just because of its excessive size, especially if you're creating a lot of them (if you ever do a memory profile of AS, you can see that CHM and its components tend to bubble to the top of the list). So for low contention situations I'd always recommend a plain synchronized map. The best solution would of course be to eliminate the lock - if you're already protected, you could use a plain hashmap. Otherwise consider if copy-on-write is suitable for you - Jason's FastCopyHashMap is good for that kind of thing. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/527291#527291

14 years, 11 months

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: Profiling the dependency project"

by Ales Justin

JBoss development, A new message was posted in the thread "Profiling the dependency project": http://community.jboss.org/message/527278#527278 Author : Ales Justin Profile : http://community.jboss.org/people/alesj Message: -------------------------------------------------------------- > Since installCallbacks and uninstallCallbacks are ConcurrentHashMaps, I think the read lock is unnecessary here in AbstractController: Since I think callbacks are already used in some explicitly locked code (via Lock), what about if we leave the locks and just change the callbacks to plain HashMap? Like discussed on the call, what is faster in a really-rare-concurrent env? * lock + plain hash collection * concurrent hash collection Jason, DML? -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/527278#527278

14 years, 11 months

1
0
0 / 0

[JBoss AOP Development] New message: "Re: ClassPool Refactoring"

by Ales Justin

JBoss development, A new message was posted in the thread "ClassPool Refactoring": http://community.jboss.org/message/527270#527270 Author : Ales Justin Profile : http://community.jboss.org/people/alesj Message: -------------------------------------------------------------- > Does anybody know the answer to this question? I can't commit it without knowing the answer. It depends how and were things are cached. Since, of course you should be able to re-deploy things, while Classpool still reflect proper/actual state. Undeploy should evict related things from cache as well. Re-deploy is the only scenario I see as valid, that would change the structure/state. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/527270#527270

14 years, 11 months

1
0
0 / 0

[JBoss AOP Development] New message: "Re: ClassPool Refactoring"

by Kabir Khan

JBoss development, A new message was posted in the thread "ClassPool Refactoring": http://community.jboss.org/message/527267#527267 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- > mailto:flavia.rainone@jboss.com wrote: > > While working with Kabir to fix the AOP tests for AS, he pointed out that there could be an issue related to my fix. It seemed obviously right to me to look in the classes cache (a cache declared in ScopedClassPool that contains all classes created by the current class pool) before doing anything else. To me, if we have a hit in the cache, it means that the current pool is the one that is supposed to load the class, and that there is no need to look further by calling super.get method. But Kabir raised the following possibility. What if the class pool scenario (a reflection of the class loader/domain scenario) changes after the current class pool loaded the class, in a way that this class pool is no longer the one responsible for loading that class? In that case, looking for the class in the classes cache would be a serious mistake. Is this scenario possible? > Does anybody know the answer to this question? I can't commit it without knowing the answer. Unless Adrian or Ales can give you an answer, you can see how this works in the classloaders themselves and make the pools behave the same -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/527267#527267

14 years, 11 months

1
0
0 / 0

[JBoss AOP Development] New message: "Re: ClassPool Refactoring"

by Flavia Rainone

JBoss development, A new message was posted in the thread "ClassPool Refactoring": http://community.jboss.org/message/527265#527265 Author : Flavia Rainone Profile : http://community.jboss.org/people/flavia.rainone@jboss.com Message: -------------------------------------------------------------- > mailto:flavia.rainone@jboss.com wrote: > > My fix has never been comitted and consists of adding a check on the classes cache to BaseClassPool.get: > > *public* *class* BaseClassPool *extends* AbstractClassPool > { > ... > @Override > *public* *final* CtClass get(String classname) *throws* NotFoundException > { > *boolean* trace = logger.isTraceEnabled(); > *if* (trace) logger.trace(*this* + " initiating get of " + classname); > > *if* (this.getClassLoader() == *null*) > { > *throw* *new* IllegalStateException("Illegal call. " + " A class cannot be retrieved from ClassPool " + > *this* + " because the corresponding ClassLoader is garbage collected"); > } > *try* > { > >>> *if* (this.classes.containsKey(classname)) > >>> { > >>> *return* (CtClass) classes.get(classname); > >>> } > CtClass clazz = super.get(classname); > *if* (trace) > logger.trace(*this* + " completed get of " + classname + " " + getClassPoolLogStringForClass(clazz)); > > *return* clazz; > } > *catch* (NotFoundException e) > { > *if* (trace) > logger.trace(classname + " could not be found from " + this, e); > *throw* e; > } > } > } > > > > [....] > > > > While working with Kabir to fix the AOP tests for AS, he pointed out that there could be an issue related to my fix. It seemed obviously right to me to look in the classes cache (a cache declared in ScopedClassPool that contains all classes created by the current class pool) before doing anything else. To me, if we have a hit in the cache, it means that the current pool is the one that is supposed to load the class, and that there is no need to look further by calling super.get method. But Kabir raised the following possibility. What if the class pool scenario (a reflection of the class loader/domain scenario) changes after the current class pool loaded the class, in a way that this class pool is no longer the one responsible for loading that class? In that case, looking for the class in the classes cache would be a serious mistake. Is this scenario possible? Does anybody know the answer to this question? I can't commit it without knowing the answer. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/527265#527265

14 years, 11 months

1
0
0 / 0

[Javassist Development] New message: "Re: ScopedClassPoolRepositoryImpl and default ClassPool"

by Flavia Rainone

JBoss development, A new message was posted in the thread "ScopedClassPoolRepositoryImpl and default ClassPool": http://community.jboss.org/message/527264#527264 Author : Flavia Rainone Profile : http://community.jboss.org/people/flavia.rainone@jboss.com Message: -------------------------------------------------------------- I created a Jira for this: https://jira.jboss.org/jira/browse/JBREFLECT-96 -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/527264#527264

14 years, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2010