I seem to have hit a stumbling block with defining the thread-pool. When
I use the an UnboundedQueueThreadPool from the threads subsystem I get
errors when executing a second deployment. The error is;
17:12:39,809 ERROR [org.jberet.util] (batch-batch - 3) jberet000018:
Failed to run job chunkPartition, , org.jberet.job.model.Job@e3527afd:
java.lang.IllegalStateException: jberet000001: Failed to create artifact
with ref name chunkPartitionAnalyzer. Ensure CDI beans.xml is present
and batch.xml, if any, is configured properly.
at
org.jberet.runtime.context.JobContextImpl.createArtifact(JobContextImpl.java:196)
[jberet-core-1.0.0.Alpha3.jar:1.0.0.Alpha3]
at
org.jberet.runtime.runner.StepExecutionRunner.initPartitionConfig(StepExecutionRunner.java:355)
[jberet-core-1.0.0.Alpha3.jar:1.0.0.Alpha3]
at
org.jberet.runtime.runner.StepExecutionRunner.<init>(StepExecutionRunner.java:85)
[jberet-core-1.0.0.Alpha3.jar:1.0.0.Alpha3]
at
org.jberet.runtime.runner.CompositeExecutionRunner.runStep(CompositeExecutionRunner.java:155)
[jberet-core-1.0.0.Alpha3.jar:1.0.0.Alpha3]
at
org.jberet.runtime.runner.CompositeExecutionRunner.runFromHeadOrRestartPoint(CompositeExecutionRunner.java:87)
[jberet-core-1.0.0.Alpha3.jar:1.0.0.Alpha3]
at
org.jberet.runtime.runner.JobExecutionRunner.run(JobExecutionRunner.java:55)
[jberet-core-1.0.0.Alpha3.jar:1.0.0.Alpha3]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
[rt.jar:1.7.0_60]
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
[rt.jar:1.7.0_60]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[rt.jar:1.7.0_60]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[rt.jar:1.7.0_60]
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_60]
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not
set for ModuleClassLoader for Module "deployment.batch-flow.war:main"
from Service Module Loader. This means that you are trying to access a
weld deployment with a Thread Context ClassLoader that is not associated
with the deployment.
at
org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75)
[wildfly-weld-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at
org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128)
[wildfly-weld-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at org.jboss.weld.Container.instance(Container.java:65)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
at
org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:769)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
at
org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
at
org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
at
org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
at
org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
at
org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
at
org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
at
org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
at
org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:89)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:149)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
at
org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:69)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
at
org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:730)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
at
org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:750)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
at
org.jboss.weld.util.ForwardingBeanManager.getReference(ForwardingBeanManager.java:61)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
at
org.jboss.weld.bean.builtin.BeanManagerProxy.getReference(BeanManagerProxy.java:73)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
at
org.wildfly.jberet.WildFlyArtifactFactory.create(WildFlyArtifactFactory.java:54)
[wildfly-jberet-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at
org.jberet.creation.ArtifactFactoryWrapper.create(ArtifactFactoryWrapper.java:39)
[jberet-core-1.0.0.Alpha3.jar:1.0.0.Alpha3]
at
org.jberet.runtime.context.JobContextImpl.createArtifact(JobContextImpl.java:194)
[jberet-core-1.0.0.Alpha3.jar:1.0.0.Alpha3]
... 11 more
Note that it's using the wrong ModuleClassLoader for some reason. I'm
not sure if the thread is being created with the TCCL from the first
deployment and being cached or what. I'll dig in more, but maybe you
know off the top of your head.
If I use the ee.ConcurrentService for the default managed executor
service everything seems to work fine.
I'm attaching the full server.log so you can see it if you'd like. This
is the specific commit for the changes
https://github.com/jamezp/wildfly/commit/9d94d842a01e03059bf4b62058e062de...
and the branch is
https://github.com/jamezp/wildfly/compare/WFLY-508-WFLY-1680-c.
--
James R. Perkins
Red Hat JBoss Middleware