2 Replies Latest reply on Jan 21, 2014 7:51 PM by jmsjr

    Number of Invocations shown via jboss-cli.bat is zero, even when SLSB was executed

    jmsjr Newbie

      JBoss EAP 6.2

      Java7 x64

       

      We are in the process of evaluating JBossEAP 6.2 for migration purposes from JBoss5 .1-GA community edition.

      In our POC, I have changed what used to use JMS for multi-threaded execution to using @Asynchronous EJB 3.1.

      So far so good, and I can see in a stack-trace that the @Remote EJB was indeed executed "remotely" and asynchronously ( .. although just using once instance of JBoss in full-ha-domain mode ).

       

      What my question now is related to jboss-cli.bat. Although the SLSB was executed a few times, the CLI interface shows the following:

       

      [standalone@localhost:9999 /] ls deployment=aaspirej2ee.ear/subdeployment=CoreApp.jar/subsystem=ejb3/stateless-session-bean=AtuBatchJobExecutor

      component-class-name=AtuBatchJobExecutor  methods={}                                pool-current-size=1                       run-as-role=undefined

      declared-roles=[]                         peak-concurrent-invocations=0             pool-max-size=20                          security-domain=other

      execution-time=0                          pool-available-count=20                   pool-name=slsb-strict-max-pool            timers=[]

      invocations=0                             pool-create-count=1                       pool-remove-count=0                       wait-time=0

      [standalone@localhost:9999 /] ls deployment=aaspirej2ee.ear/subdeployment=CoreApp.jar/subsystem=ejb3/stateless-session-bean=AtuBatchJobExecutor

      component-class-name=AtuBatchJobExecutor  methods={}                                pool-current-size=1                       run-as-role=undefined

      declared-roles=[]                         peak-concurrent-invocations=0             pool-max-size=20                          security-domain=other

      execution-time=0                          pool-available-count=20                   pool-name=slsb-strict-max-pool            timers=[]

      invocations=0                             pool-create-count=1                       pool-remove-count=0                       wait-time=0

      [standalone@localhost:9999 /] ls deployment=aaspirej2ee.ear/subdeployment=CoreApp.jar/subsystem=ejb3/stateless-session-bean=AtuBatchJobExecutor

      component-class-name=AtuBatchJobExecutor  methods={}                                pool-current-size=1                       run-as-role=undefined

      declared-roles=[]                         peak-concurrent-invocations=0             pool-max-size=20                          security-domain=other

      execution-time=0                          pool-available-count=20                   pool-name=slsb-strict-max-pool            timers=[]

      invocations=0                             pool-create-count=1                       pool-remove-count=0                       wait-time=0

      [standalone@localhost:9999 /] ls deployment=aaspirej2ee.ear/subdeployment=CoreApp.jar/subsystem=ejb3/stateless-session-bean=AtuBatchJobExecutor

      component-class-name=AtuBatchJobExecutor  methods={}                                pool-current-size=1                       run-as-role=undefined

      declared-roles=[]                         peak-concurrent-invocations=0             pool-max-size=20                          security-domain=other

      execution-time=0                          pool-available-count=20                   pool-name=slsb-strict-max-pool            timers=[]

      invocations=0                             pool-create-count=1                       pool-remove-count=0                       wait-time=0

       

      The above were taken at various points in time  ... before and after the SLSB was looked up and executed.

       

       

      If it matters at all, the SLSB was obtained via a programmatic lookup, and not via injection with the @EJB annotation, because the POJO calling the SLSB is instantiated by directly calling its constructor ( e.g. The POJO is not managed ).

       

      InitialContext context = new InitialContext();

      batchJobExecutor = (BatchJobExecutor) context.lookup(

        "java:global/aaspirej2ee/CoreApp/AtuBatchJobExecutor!com.atune.business.session.BatchJobExecutor");

       

       

      The interface is as follows:

       

      import java.util.concurrent.Future;

      import javax.ejb.Remote;

       

      @Remote

      public interface BatchJobExecutor {

       

        public abstract Future<Void> executeJob(AtuBatchJobMessage jobMessage);

      }

       

      Note that the method on the interface is not annotated with @Asynchronous, but the SLSB method implementation is:

       

      @TransactionManagement(javax.ejb.TransactionManagementType.BEAN)

      @Stateless

      public class AtuBatchJobExecutor implements BatchJobExecutor {

       

        @Override

        @Asynchronous

        public Future<Void> executeJob(AtuBatchJobMessage jobMessage) { ... }

      }

       

       

      ... and the POJO, after obtaining looking up the SLSB programmatically, calls the method:

       

      Future<Void> result = batchJobExecutor.executeJob(jobMessage);