Wildfly 10.1.0.Final + JMS + CDI +

[sverker.sverker.abrahamsson.com]

I have an application where a dispatcher sends out jobs to a number of workers which are REST microservices. I have a Singleton bean which instantiate a controller bean for each worker, right now the workers are set statically by startup properties but it is intended that it should be possible to start and stop workers dynamically. Each controller bean is instantiated with CDI.current().select(WorkerTask.class).get() and then started by ManagedExecutorService. In the bean there is an injected JMSContext and JMSQueue which is used to create a JMSConsumer in the thread.

The controller bean then first checks that the worker it is controlling is healthy and then fetches one job from the JMS queue, monitors the states of this job as the worker processes it and when done it will fetch the next job (or block until a job is available) .

This has worked fine up to Wildfly 10.0.0.Final, but with 10.1.0.Final I get the following Exception when creating the consumer:

17:51:06,718 ERROR [com.limetransit.fileencoder.dispatcher.WorkerTask] (WorkerTask http://localhost:9090/) WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped: org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped

        at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:689)

        at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:90)

        at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:165)

        at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)

        at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:83)

        at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:99)

        at org.wildfly.extension.messaging.activemq.deployment.injection.RequestedJMSContext$Proxy$_$$_WeldClientProxy.getContext(Unknown Source)

        at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.getDelegate(InjectedJMSContext.java:91)

        at org.wildfly.extension.messaging.activemq.deployment.injection.JMSContextWrapper.createConsumer(JMSContextWrapper.java:187)

        at com.limetransit.fileencoder.dispatcher.WorkerTask.run(WorkerTask.java:99)

        at org.jboss.as.ee.concurrent.ControlPointUtils$ControlledRunnable.run(ControlPointUtils.java:105)

        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)

        at java.util.concurrent.FutureTask.run(FutureTask.java:266)

        at org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.run(ManagedFutureTask.java:141)

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

        at java.lang.Thread.run(Thread.java:745)

        at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250)

The Singleton bean which instantiates the controller bean is @ApplicationScoped, the controller bean is @Dependant (I've tried also with @ApplicationScoped but that didn't change anything). What to do to solve this issue, or work around it?

Simplified the worker bean looks like this:

@Dependent
public class WorkerTask implements Runnable {
    @Inject
    private JMSContext jmsContext;

    @Resource(lookup="java:/jms/queue/JobQueue")
    private Queue jobQueue;

    public void run() {
      running = true;
      JMSConsumer consumer = jmsContext.createConsumer(jobQueue);  // Exception is thrown here
      while(running) {
             <Poll worker for health status>
             Message message = consumer.receive();
             Job job = message.getBody(Job.class);
             <Submit job to worker, monitor state until done>
      }
   }
}

And it is instantiated from the @Singleton like this:

@Singleton 
@Startup 
@ApplicationScoped 
public class WorkerController {
     @Resource
     private ManagedExecutorService managedExecutorService;

     @PostConstruct
     private void startup() {
         for(String workerUrl: workerUrls) {
             WorkerTask workerTask = CDI.current().select(WorkerTask.class).get();
             managedExecutorService.submit(workerTask);
         }
     }
}

[tremes]

Hi Sverker,

Does this manifest during deployment (since you have @Startup and @PostConstruct)? I can't reproduce it on WildFly 10.1.0.Final. Could you please provide complete reproducer containing all necessary classes? Thanks a lot.

[mkouba]

Hi Sverker,

this worked on WildFly 10.0.0.Final because it was not JMS spec-compliant, see also [WFLY-3471] Scope of JMSContextProducer should be either @Request or @Tx not default and the injected JMSContext was @Dependent. In WildFly 10.1.0.Final it's either @TransactionScoped or @RequestScoped (if no JTA transaction is in progress). The problem is the request context is not active during task execution (it is not required by Concurrency Utilities for Java EE, nor by CDI). You would have to activate the request context manually - e.g. using Weld Context Management API (Chapter 22. Context Management). I've created WFLY-7152.

[sverker.sverker.abrahamsson.com]

Thank you Tomas and Martin for your responses. As I understand it currently should not work.

I was able to get my usecase to work with

    @Resource(name="jms/QueueConnectionFactory")

    private ConnectionFactory connectionFactory;

    @Resource(lookup="java:/jms/queue/JobQueue")

    private Queue jobQueue;

and then create a JMSContext and JMSConsumer from it:

JMSContext jmsContext = connectionFactory.createContext(); JMSConsumer consumer = jmsContext.createConsumer(jobQueue);

[luc.feys6]

For me this also worked. I think this should also be the accepted answer, given that the feature request mentioned in the currently accepted answer still has not been implemented (3 years later).

So for anyone looking for a solution to this problem in 2019 (JEE7, Wildfly 15), the approach proposed by Sverker works.