RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins AbstractInstancePool.java MessageDrivenInstanceInterceptor.java StatefulSessionInstanceInterceptor.java StatelessSessionInstanceInterceptor.java

2002-01-26 Thread Vincent Harcq 

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

2002-01-01 Thread Vincent Harcq 

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

2001-12-30 Thread Vincent Harcq 

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

2001-12-30 Thread Scott M Stark 

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

2001-12-29 Thread Vincent Harcq 

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

2001-12-29 Thread Scott M Stark 

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