Number of Invocations shown via jboss-cli.bat is zero, even when SLSB was executed
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);
