RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins AbstractInstancePool.java MessageDrivenInstanceInterceptor.java StatefulSessionInstanceInterceptor.java StatelessSessionInstanceInterceptor.java
I am currently working on this. I have a problem with entity pool. It is in the case of reclaim is true. There is one case when the EntityInstancePool will not send back the instance to the pool : when EntityInstancePool.free() is called inside a transaction, here the instance will be thrown away. So if I change the counting algorithm to take into account how many instance are currently in use, I may come to a point where I will never come back to the MaximumSize because some instances will be lost. After looking further, this problem will also arise with stateless session bean in case of errors (StatelessSessionInterceptor.invoke()). Could we just NOT verify the maximumsize when pushing back to the pool and eventually have more instances in the pool that MaximumSize. The StrictMaximumSize would solve the problem when people really need it ? Vincent. There is another issue with how the feeder interacts with the pool. The getCurrentSize is really the pool free instance count. Only on startup is this also the pool count. After the pool has been filled once, (MaximumSize - getCurrentSize) is no longer how many instances need to be added to the pool. Say MaximumSize is 10 and the pool is filled by the feeder. Next 10 clients invoke methods concurrently and take the pool free count to 0 and getCurrentSize is also 0. The feeder then wakes up and puts 10 more instances into the pool. The client invocations next complete and all 10 instances are discarded as the pool is seen to be full. The AbstractInstancePool is not counting instances correctly when another thread is adding instances. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins AbstractInstancePool.java MessageDrivenInstanceInterceptor.java StatefulSessionInstanceInterceptor.java StatelessSessionInstanceInterceptor.java
OK, Just to say I will work on these things as soon as I can. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Scott M Stark Sent: dimanche 30 décembre 2001 20:43 To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins AbstractInstancePool.java MessageDrivenInstanceInterceptor.java StatefulSessionInstanceInterceptor.java StatelessSessionInstanceInterceptor.java The testcase would set a class flag in the bean class if an exception occurred in the setSessionContext method. When the unit tests run and invoke a method on a bean, the bean would check this flag in its only business method and throw an exception. The simplest intermediate fix is to delay the start of the feeder timer by 10 seconds or so. More exacting startup criteria can be dealt with as needed. There is another issue with how the feeder interacts with the pool. The getCurrentSize is really the pool free instance count. Only on startup is this also the pool count. After the pool has been filled once, (MaximumSize - getCurrentSize) is no longer how many instances need to be added to the pool. Say MaximumSize is 10 and the pool is filled by the feeder. Next 10 clients invoke methods concurrently and take the pool free count to 0 and getCurrentSize is also 0. The feeder then wakes up and puts 10 more instances into the pool. The client invocations next complete and all 10 instances are discarded as the pool is seen to be full. The AbstractInstancePool is not counting instances correctly when another thread is adding instances. - Original Message - From: Vincent Harcq [EMAIL PROTECTED] To: 'Scott M Stark' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, December 30, 2001 3:17 AM Subject: RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins AbstractInstancePool.java MessageDrivenInstanceInterceptor.java StatefulSessionInstanceInterceptor.java StatelessSessionInstanceInterceptor.java ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins AbstractInstancePool.java MessageDrivenInstanceInterceptor.java StatefulSessionInstanceInterceptor.java StatelessSessionInstanceInterceptor.java
There is no test case I could write to show this problem. When an exception occurs in set...Context(), the instance is not push in the pool which is correct. When everything is ready to avoid these exceptions, the pool will begin to grow. If a direct get() is made an exception will be thrown as before so I guess it is also OK. BTW, the postinit is not the best idea. An independant Mbean could take care of starting the pool feeder after the deployment. It could then also be paused during redeployment. I am ok to leave this problem, ... Or fix it myself the way you want. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Scott M Stark Sent: dimanche 30 décembre 2001 7:27 To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins AbstractInstancePool.java MessageDrivenInstanceInterceptor.java StatefulSessionInstanceInterceptor.java StatelessSessionInstanceInterceptor.java Oh, well, that is what comments and test cases are for. Add a test case that demonstrates the problem and I'll fix this in the next release. Hi, There is a reason why I did not start the pool from the ContainerFactory (well another that the classloader issue that you fixed ;) ) The setSessionContext have, in most cases, Home lookup (to cache them) and if all beans are not deployed you can have JNDI lookup failure (when using flat ejb-jar's for example). It is a problem that can happen in other cases as well I must agree and that the developer should take care of, but it appears as a Jboss bug when you first see it. I can only see one solution : have a postinit() method in container that is called when all containers have started. Vincent. - Original Message - From: Vincent Harcq [EMAIL PROTECTED] To: 'Scott M Stark' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, December 29, 2001 6:15 PM Subject: RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins AbstractInstancePool.java MessageDrivenInstanceInterceptor.java StatefulSessionInstanceInterceptor.java StatelessSessionInstanceInterceptor.java ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins AbstractInstancePool.java MessageDrivenInstanceInterceptor.java StatefulSessionInstanceInterceptor.java StatelessSessionInstanceInterceptor.java
The testcase would set a class flag in the bean class if an exception occurred in the setSessionContext method. When the unit tests run and invoke a method on a bean, the bean would check this flag in its only business method and throw an exception. The simplest intermediate fix is to delay the start of the feeder timer by 10 seconds or so. More exacting startup criteria can be dealt with as needed. There is another issue with how the feeder interacts with the pool. The getCurrentSize is really the pool free instance count. Only on startup is this also the pool count. After the pool has been filled once, (MaximumSize - getCurrentSize) is no longer how many instances need to be added to the pool. Say MaximumSize is 10 and the pool is filled by the feeder. Next 10 clients invoke methods concurrently and take the pool free count to 0 and getCurrentSize is also 0. The feeder then wakes up and puts 10 more instances into the pool. The client invocations next complete and all 10 instances are discarded as the pool is seen to be full. The AbstractInstancePool is not counting instances correctly when another thread is adding instances. - Original Message - From: Vincent Harcq [EMAIL PROTECTED] To: 'Scott M Stark' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, December 30, 2001 3:17 AM Subject: RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins AbstractInstancePool.java MessageDrivenInstanceInterceptor.java StatefulSessionInstanceInterceptor.java StatelessSessionInstanceInterceptor.java ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins AbstractInstancePool.java MessageDrivenInstanceInterceptor.java StatefulSessionInstanceInterceptor.java StatelessSessionInstanceInterceptor.java
Hi, There is a reason why I did not start the pool from the ContainerFactory (well another that the classloader issue that you fixed ;) ) The setSessionContext have, in most cases, Home lookup (to cache them) and if all beans are not deployed you can have JNDI lookup failure (when using flat ejb-jar's for example). It is a problem that can happen in other cases as well I must agree and that the developer should take care of, but it appears as a Jboss bug when you first see it. I can only see one solution : have a postinit() method in container that is called when all containers have started. Vincent. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Scott M Stark Sent: vendredi 28 décembre 2001 23:35 To: [EMAIL PROTECTED] Subject: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins AbstractInstancePool.java MessageDrivenInstanceInterceptor.java StatefulSessionInstanceInterceptor.java StatelessSessionInstanceInterceptor.java User: starksm Date: 01/12/28 14:35:14 Modified:src/main/org/jboss/ejb/plugins Tag: Branch_2_4 AbstractInstancePool.java MessageDrivenInstanceInterceptor.java StatefulSessionInstanceInterceptor.java StatelessSessionInstanceInterceptor.java Log: Add a strict pooling behavior that limits the number of instances to that specified by the container-pool-conf/MaximumSize Revision ChangesPath No revision No revision 1.9.6.6 +138 -65 jboss/src/main/org/jboss/ejb/plugins/AbstractInstancePool.java Index: AbstractInstancePool.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/AbstractIn stancePool.java,v retrieving revision 1.9.6.5 retrieving revision 1.9.6.6 diff -u -r1.9.6.5 -r1.9.6.6 --- AbstractInstancePool.java 2001/12/27 19:41:16 1.9.6.5 +++ AbstractInstancePool.java 2001/12/28 22:35:13 1.9.6.6 @@ -17,24 +17,26 @@ import org.jboss.ejb.EnterpriseContext; import org.w3c.dom.Element; + +import EDU.oswego.cs.dl.util.concurrent.FIFOSemaphore; + import org.jboss.deployment.DeploymentException; import org.jboss.metadata.MetaData; import org.jboss.metadata.XmlLoadable; import org.jboss.logging.Logger; /** - * review * Abstract Instance Pool class containing the basic logic to create * an EJB Instance Pool. - * /review * * @see related * @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a * @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a - * @author a href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a - * @author a href=mailto:[EMAIL PROTECTED];Sacha Labourey/a + * @author a href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a + * @author a href=mailto:[EMAIL PROTECTED];Sacha Labourey/a + * @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a * - * @version $Revision: 1.9.6.5 $ + * @version $Revision: 1.9.6.6 $ * * pbRevisions:/b * pb20010704 marcf:/b @@ -56,19 +58,26 @@ // Constants - // Attributes + /** A semaphore that is set when the strict max size behavior is in effect. +When set, only maxSize instance may be active and any attempt to get an +instance will block until an instance is freed. +*/ + private FIFOSemaphore strictMaxSize; + /** The time in milliseconds to wait for the strictMaxSize semaphore. +*/ + private long strictTimeout = Long.MAX_VALUE; + /** The logging interface */ protected Logger log = Logger.getLogger(this.getClass()); - + /** The Container the instance pool is associated with */ protected Container container; - /** The instance pool stack */ protected Stack pool = new Stack(); /** The maximum number of instances allowed in the pool */ protected int maxSize = 30; /** determine if we reuse EnterpriseContext objects i.e. if we actually do pooling */ protected boolean reclaim = false; - + /** The pool seed task set from the feeder-policy config element */ protected InstancePoolFeeder poolFeeder; - protected boolean useFeeder = false; // Static @@ -103,14 +112,14 @@ public void start() throws Exception { + if( poolFeeder != null poolFeeder.isStarted() == false ) + poolFeeder.start(); } public void stop() { - if (useFeeder poolFeeder.isStarted()) - { + if( poolFeeder
Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins AbstractInstancePool.java MessageDrivenInstanceInterceptor.java StatefulSessionInstanceInterceptor.java StatelessSessionInstanceInterceptor.java
Oh, well, that is what comments and test cases are for. Add a test case that demonstrates the problem and I'll fix this in the next release. Hi, There is a reason why I did not start the pool from the ContainerFactory (well another that the classloader issue that you fixed ;) ) The setSessionContext have, in most cases, Home lookup (to cache them) and if all beans are not deployed you can have JNDI lookup failure (when using flat ejb-jar's for example). It is a problem that can happen in other cases as well I must agree and that the developer should take care of, but it appears as a Jboss bug when you first see it. I can only see one solution : have a postinit() method in container that is called when all containers have started. Vincent. - Original Message - From: Vincent Harcq [EMAIL PROTECTED] To: 'Scott M Stark' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, December 29, 2001 6:15 PM Subject: RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins AbstractInstancePool.java MessageDrivenInstanceInterceptor.java StatefulSessionInstanceInterceptor.java StatelessSessionInstanceInterceptor.java ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins AbstractInstancePool.java MessageDrivenInstanceInterceptor.java StatefulSessionInstanceInterceptor.java StatelessSessionInstanceInterceptor.java
User: starksm Date: 01/12/28 14:35:14 Modified:src/main/org/jboss/ejb/plugins Tag: Branch_2_4 AbstractInstancePool.java MessageDrivenInstanceInterceptor.java StatefulSessionInstanceInterceptor.java StatelessSessionInstanceInterceptor.java Log: Add a strict pooling behavior that limits the number of instances to that specified by the container-pool-conf/MaximumSize Revision ChangesPath No revision No revision 1.9.6.6 +138 -65 jboss/src/main/org/jboss/ejb/plugins/AbstractInstancePool.java Index: AbstractInstancePool.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/AbstractInstancePool.java,v retrieving revision 1.9.6.5 retrieving revision 1.9.6.6 diff -u -r1.9.6.5 -r1.9.6.6 --- AbstractInstancePool.java 2001/12/27 19:41:16 1.9.6.5 +++ AbstractInstancePool.java 2001/12/28 22:35:13 1.9.6.6 @@ -17,24 +17,26 @@ import org.jboss.ejb.EnterpriseContext; import org.w3c.dom.Element; + +import EDU.oswego.cs.dl.util.concurrent.FIFOSemaphore; + import org.jboss.deployment.DeploymentException; import org.jboss.metadata.MetaData; import org.jboss.metadata.XmlLoadable; import org.jboss.logging.Logger; /** - * review * Abstract Instance Pool class containing the basic logic to create * an EJB Instance Pool. - * /review * * @see related * @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a * @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a - * @author a href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a - * @author a href=mailto:[EMAIL PROTECTED];Sacha Labourey/a + * @author a href=mailto:[EMAIL PROTECTED];Andreas Schaefer/a + * @author a href=mailto:[EMAIL PROTECTED];Sacha Labourey/a + * @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a * - * @version $Revision: 1.9.6.5 $ + * @version $Revision: 1.9.6.6 $ * * pbRevisions:/b * pb20010704 marcf:/b @@ -56,19 +58,26 @@ // Constants - // Attributes + /** A semaphore that is set when the strict max size behavior is in effect. +When set, only maxSize instance may be active and any attempt to get an +instance will block until an instance is freed. +*/ + private FIFOSemaphore strictMaxSize; + /** The time in milliseconds to wait for the strictMaxSize semaphore. +*/ + private long strictTimeout = Long.MAX_VALUE; + /** The logging interface */ protected Logger log = Logger.getLogger(this.getClass()); - + /** The Container the instance pool is associated with */ protected Container container; - /** The instance pool stack */ protected Stack pool = new Stack(); /** The maximum number of instances allowed in the pool */ protected int maxSize = 30; /** determine if we reuse EnterpriseContext objects i.e. if we actually do pooling */ protected boolean reclaim = false; - + /** The pool seed task set from the feeder-policy config element */ protected InstancePoolFeeder poolFeeder; - protected boolean useFeeder = false; // Static @@ -103,14 +112,14 @@ public void start() throws Exception { + if( poolFeeder != null poolFeeder.isStarted() == false ) + poolFeeder.start(); } public void stop() { - if (useFeeder poolFeeder.isStarted()) - { + if( poolFeeder != null ) poolFeeder.stop(); - } } public void destroy() @@ -131,59 +140,81 @@ this.reclaim = reclaim; } - /** -* Add a instance in the pool + /** Add a instance in the pool by invoking create() with a new +bean instance. +@exception Exception, thrown on ctx creation failure */ public void add() throws Exception { - EnterpriseContext ctx = create(container.createBeanClassInstance()); + EnterpriseContext ctx = null; + try + { + ctx = create(container.createBeanClassInstance()); + } + catch (InstantiationException e) + { + throw new ServerException(Could not instantiate bean, e); + } + catch (IllegalAccessException e) + { + throw new ServerException(Could not instantiate bean, e); + } if( log.isTraceEnabled() ) log.trace(Add instance +this+#+ctx); this.pool.push(ctx); } - /** -* Get an instance without identity. -* Can be used by finders,create-methods, and activation -