Robert Geisler [http://community.jboss.org/people/robert.geisler] created the discussion "Re: EJB3 Session Bean Pool" To view the discussion, visit: http://community.jboss.org/message/597828#597828 -------------------------------------------------------------- thank you, carlo for response. of course you are right, one could extend StrictMaxPool and enlarge strictMaxSize semaphore. but what is the benefit of using the semaphore at all? isnt it an unnecessary overhead? we believe we do not need a maximum to limit creation of instances, but we need a maximum of pooled instances! so i thought about a pool implementation backed by a simple array with length maxSize: 1. get() looks into the array and returns and removes the last element -if available; 2. otherwise create a new one, no maximum for creating instances (aka tolerant)! 3. instances that are released go back into the array -if they fit into it (maxSize = array length); 4. otherwise they are removed immediately. this seems to be quite simple to implement...? would you expect any issues with such an implementation? -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/597828#597828] Start a new discussion in EJB3 at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Robert Geisler [http://community.jboss.org/people/robert.geisler] created the discussion "Re: EJB3 Session Bean Pool" To view the discussion, visit: http://community.jboss.org/message/598913#598913 -------------------------------------------------------------- hello carlo, i finally implemented a custom org.jboss.ejb3.Pool and i am going to test it during the next days. when all the bugs are gone, i'll post the code in JBoss forum; or on github as suggested. but today i have a few more questions: *I) remove instances that are in use??* i had a look at the code of org.jboss.ejb3.InfinitePool (written by you : )) and i noticed that InfinitePool holds a List<BeanContext> of >>active<< contexts. i guess, active means that these contexts are currently used (by a single thread)? whenever a context is created, the new instance is added to actives and then it stays there until it get released/ removed. when the pool is destroyed (e.g. the bean gets undeployed?), InfinitePool iterates through its actives and calls remove() for each of these instances/ contexts created before. but StrictMaxPool (written by Kabir Khan) for example does not maintain such a list and thus does not call remove for active instances. so instances that are in use (/ are not located in the pool) while the pool is destroyed will never be removed, right? is it critical? in which cases is Pool.destroy() called and is the pool required to remove such active instances?? what happens to these instances after the pool is destroyed? *II) how to synchronize pool?* a) InfinitePool and StrictMaxPool do not use synchronized methods, but synchronized statements for changes in the pool structure. i tried to adopt this for my pool. but i wonder if synchronized methods would also do the trick? or could it cause a bottleneck?? b) i checked sources of pool implementations in JBoss6. i noticed that org.jboss.ejb3.AbstractPool uses AtomicInteger to count create() and remove() while JBoss4 used a primitive instead. should a adopt this as well?? thanks in advance. robert -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/598913#598913] Start a new discussion in EJB3 at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Robert Geisler [http://community.jboss.org/people/robert.geisler] created the discussion "Re: EJB3 Session Bean Pool" To view the discussion, visit: http://community.jboss.org/message/599789#599789 -------------------------------------------------------------- hello carlo, i finished implementing my "LooseMinPool" : ) you may find the source on sourcepod: http://www.sourcepod.com/rptzcu29-4656 http://www.sourcepod.com/rptzcu29-4656 . core pool functionality: * uses an array to store released instances: if a instance is requested (get()), the last element of the array will be returned (and removed from the array). on release() the freed instance will be put back into the array again as the last element. * the pool is cleared frequently (configured by timeout parameter): on timeout all the pooled instances are checked for their last access and instances that were not used since last timeout, are removed. i tested the pool during the last days and it seems to work (meaning i did not recognized any fundamental errors or performance issues yet ; )). maybe you could take a look at the code and inform me in case i did something stupid? O: ) thank you for your attention! regards robert -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/599789#599789] Start a new discussion in EJB3 at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Robert Geisler [http://community.jboss.org/people/robert.geisler] created the discussion "Re: EJB3 Session Bean Pool" To view the discussion, visit: http://community.jboss.org/message/601123#601123 -------------------------------------------------------------- hi carlo, thank you very much for uploading and commenting the sources. i did not revise the code, yet, but i would like to discuss your statements... *i) exception handling as logic* * * you told me not to use exception handling as logic because instantiation of exceptions "take[s] a large hit". well, i guess, for a single execution an if/ else may be faster than throwing/ catching an exception. but please consider how often the exception is actually thrown: +only+ * if the pool is empty (arraySize == 0) and get() is called or * the pool is full (arraySize == array.length) and release() is called. in contrast an if/ else would add an extra operation +whenever+ get() or release() is executed. that is why i excepted the exception handling logic to be the way to go. what do you think? *ii) LinkedList vs. array * * * you proposed to use a LinkedList instead of cloning the array. i guess instantitation of arrays is more expensive than instantitation of a LinkedList.Entry, so again you may be right in case of a single execution. but please keep in mind that a LinkedList would be resized +whenever+ get() or release() is called. LinkedList.add() creates a new LinkedList.Entry and links it to the first or last element of the list; LinkedList.remove() unlinks a LinkedList.Entry that later will be destroyed by gc. for an array, resizing occurs +only+ if the pool is full (arraySize == array.length) and another element is released (and should be stored in the array). on get() no resizing (/ instantiation) is necessary. so i guess than an array should beat a LinkedList -in case of frequent calls? *iii) LRU* * * you said that the pool is always sorted by LRU (last recently used) and you are right, of course. that means, on timeout not +all+ elements in the pool have to be verified: i may remove the first timedout element and all elements beyond it. so i suggest the following timeout algorithm: on timeout the current arraySize will be remembered as "timeout index". on next timeout this index will be used to find the first timedout element (at "timedout index"). if the element at timeout index is not timedout, timedout index has to be greater (otherwise less) than timeout index. all elements at and beyond timedout index will later be removed. in this way iteration is reduced to the minimum, unnecessary operations are avoided. do you confirm? regards robert -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/601123#601123] Start a new discussion in EJB3 at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Robert Geisler [http://community.jboss.org/people/robert.geisler] created the discussion "Re: EJB3 Session Bean Pool" To view the discussion, visit: http://community.jboss.org/message/626608#626608 -------------------------------------------------------------- hello romeo, i modified deploy\ejb3-interceptors-aop.xml . search for the PoolClass annotation, maxSize is the value to limit amount of instances: <aop>    ...    <*domain name="Stateless Bean"*>       ...       <annotation expr=&quot;!class((a)org.jboss.annotation.ejb.PoolClass)&quot;&gt;          @org.jboss.annotation.ejb.PoolClass (value=*org.jboss.ejb3.StrictMaxPool*.class, *maxSize=15*, timeout=10000)       </annotation>    </domain>    ... </aop> greets robert -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/626608#626608] Start a new discussion in EJB3 at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]