7 Replies Latest reply on Feb 2, 2011 1:21 PM by piotrekde

    Number of SLSB in pool in case of asynchronous calls

    piotrekde Newbie

      Hello,

       

      I occurred weird situation using JBoss 5 and EJB 3.0. Please take a look at the source code below - it is simplified example but I think that clearly reflecting this issue.

       

      ComputerBean dispatches work to pooled ProcessorBeans using AsyncUtils. I noticed that number of created SLSB never goes down (I see it printing shared COUNTER variable). So I decided to set maximum pool size explicitly and observe what will happen.

       

       

      ComputerRemote (remote interface of SFSB dispatching work)

      import javax.ejb.Remote;
      
      
      @Remote
      public interface ComputerRemote {
          void startComputations();
      }
      

       

       

      ProcessorLocal (local interface of SLSB doing computations (dispatched previously by ComputerRemote/ComputerBean))

      import javax.ejb.Local;
      
      
      @Local
      public interface ProcessorLocal {
          void compute(int i);
      }
      
      

       

      And implementations:

       

      ComputerBean (dispatching work using JBoss AsyncUtils - ComputerBean do not waits for ProcessorLocal until it will finish computations)

      @Stateful
      public class ComputerBean implements ComputerRemote {
      
      
          @EJB
          private ProcessorLocal processor;
      
      
          public void startComputations() {
              Random r = new Random();
      
      
              while(true) {
                  AsyncUtils.mixinAsync(processor).compute(r.nextInt());
              }
          }
      }
      

       

       

      And ProcessorBean using fixed pool size:

       

      
      @Stateless
      @PoolClass (value=org.jboss.ejb3.StrictMaxPool.class, maxSize=5, timeout=10000)
      public class ProcessorBean implements ProcessorLocal {
      
          private static AtomicInteger COUNTER = new AtomicInteger(0);
      
          @PostConstruct
          public void init() {
              System.out.println("constructing nr: " + COUNTER);
              COUNTER.incrementAndGet();
          }
      
          @PreDestroy
          public void destroy() {
              System.out.println("destroying nr:" + COUNTER);
              COUNTER.decrementAndGet();
          }
      
          public void compute(int i) {
              System.out.println("----------------> " + COUNTER);
      
      
              // some dummy computations - it's here only in order to take some time
              double d = 0.3;
              for (int j=0; j<100; j++) {
                  d+= 0.2 % 4 + i;
              }
          }
      }
      

       

       

      I would expect that on console COUNTER will be printed with maximum value = 5.

       

      But reality is:

       

      20:25:10,979 INFO  [STDOUT] constructing nr: 0

      20:25:11,008 INFO  [STDOUT] constructing nr: 1

      20:25:11,067 INFO  [STDOUT] constructing nr: 2

      20:25:11,096 INFO  [STDOUT] constructing nr: 3

      20:25:11,118 INFO  [STDOUT] constructing nr: 4

      20:25:11,134 INFO  [STDOUT] constructing nr: 5

      20:25:11,158 INFO  [STDOUT] constructing nr: 6

      20:25:11,185 INFO  [STDOUT] constructing nr: 7

      20:25:11,211 INFO  [STDOUT] constructing nr: 8

      (...)

      20:25:11,467 INFO  [STDOUT] constructing nr: 15

      20:25:11,522 INFO  [STDOUT] ----------------> 16

      20:25:11,524 INFO  [STDOUT] ----------------> 16

      20:25:11,524 INFO  [STDOUT] ----------------> 16

      20:25:11,525 INFO  [STDOUT] ----------------> 16

      20:25:11,526 INFO  [STDOUT] ----------------> 16

      20:25:11,527 INFO  [STDOUT] ----------------> 16

      (...)

       

      up to even 26!

       

      My question is obvious: what is going on? I expect to have maximum 5 SLSB instances...

       

      I have to use EJB3.0 and JBoss5 - at this moment I cannot switch versions.

       

      Thank you in advance for all hints,

      Piotr