<div dir="ltr">Just make sure your batch task sets the correct TCCL first thing, and you should not have this issue. You cannot rely on any particular TCCL being set when using a thread pool.<div><br></div><div>Stuart</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Sep 14, 2013 at 3:08 AM, James R. Perkins <span dir="ltr"><<a href="mailto:jperkins@redhat.com" target="_blank">jperkins@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<br>
<div> 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;<br>
<br>
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.<br>
at
org.jberet.runtime.context.JobContextImpl.createArtifact(JobContextImpl.java:196)
[jberet-core-1.0.0.Alpha3.jar:1.0.0.Alpha3]<br>
at
org.jberet.runtime.runner.StepExecutionRunner.initPartitionConfig(StepExecutionRunner.java:355)
[jberet-core-1.0.0.Alpha3.jar:1.0.0.Alpha3]<br>
at
org.jberet.runtime.runner.StepExecutionRunner.<init>(StepExecutionRunner.java:85)
[jberet-core-1.0.0.Alpha3.jar:1.0.0.Alpha3]<br>
at
org.jberet.runtime.runner.CompositeExecutionRunner.runStep(CompositeExecutionRunner.java:155)
[jberet-core-1.0.0.Alpha3.jar:1.0.0.Alpha3]<br>
at
org.jberet.runtime.runner.CompositeExecutionRunner.runFromHeadOrRestartPoint(CompositeExecutionRunner.java:87)
[jberet-core-1.0.0.Alpha3.jar:1.0.0.Alpha3]<br>
at
org.jberet.runtime.runner.JobExecutionRunner.run(JobExecutionRunner.java:55)
[jberet-core-1.0.0.Alpha3.jar:1.0.0.Alpha3]<br>
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
[rt.jar:1.7.0_60]<br>
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
[rt.jar:1.7.0_60]<br>
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[rt.jar:1.7.0_60]<br>
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[rt.jar:1.7.0_60]<br>
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_60]<br>
at org.jboss.threads.JBossThread.run(JBossThread.java:122)<br>
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.<br>
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]<br>
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]<br>
at org.jboss.weld.Container.instance(Container.java:65)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]<br>
at
org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:769)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]<br>
at
org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]<br>
at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]<br>
at
org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]<br>
at
org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]<br>
at
org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]<br>
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]<br>
at
org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]<br>
at
org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]<br>
at
org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:89)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]<br>
at
org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:149)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]<br>
at
org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:69)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]<br>
at
org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:730)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]<br>
at
org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:750)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]<br>
at
org.jboss.weld.util.ForwardingBeanManager.getReference(ForwardingBeanManager.java:61)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]<br>
at
org.jboss.weld.bean.builtin.BeanManagerProxy.getReference(BeanManagerProxy.java:73)
[weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]<br>
at
org.wildfly.jberet.WildFlyArtifactFactory.create(WildFlyArtifactFactory.java:54)
[wildfly-jberet-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]<br>
at
org.jberet.creation.ArtifactFactoryWrapper.create(ArtifactFactoryWrapper.java:39)
[jberet-core-1.0.0.Alpha3.jar:1.0.0.Alpha3]<br>
at
org.jberet.runtime.context.JobContextImpl.createArtifact(JobContextImpl.java:194)
[jberet-core-1.0.0.Alpha3.jar:1.0.0.Alpha3]<br>
... 11 more<br>
<br>
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.<br>
<br>
If I use the ee.ConcurrentService for the default managed executor
service everything seems to work fine.<br>
<br>
I'm attaching the full server.log so you can see it if you'd like.
This is the specific commit for the changes
<a href="https://github.com/jamezp/wildfly/commit/9d94d842a01e03059bf4b62058e062de8ce54b24" target="_blank">https://github.com/jamezp/wildfly/commit/9d94d842a01e03059bf4b62058e062de8ce54b24</a>
and the branch is
<a href="https://github.com/jamezp/wildfly/compare/WFLY-508-WFLY-1680-c" target="_blank">https://github.com/jamezp/wildfly/compare/WFLY-508-WFLY-1680-c</a>.<span class="HOEnZb"><font color="#888888"><br>
<pre cols="72">--
James R. Perkins
Red Hat JBoss Middleware</pre>
<br>
</font></span></div>
<br>
</div>
<br>_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
<br></blockquote></div><br></div>