[wildfly-dev] Batch Integration

Sat Sep 14 07:55:52 EDT 2013

Excellent. I'll make the change in JBeret and give it a go. Thanks!
--
James R. Perkins
JBoss by Red Hat

Stuart Douglas <stuart.w.douglas at gmail.com> wrote:

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.

Stuart

On Sat, Sep 14, 2013 at 3:08 AM, James R. Perkins <jperkins at redhat.com>wrote:

>
>  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 at 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/9d94d842a01e03059bf4b62058e062de8ce54b24and the branch is
> https://github.com/jamezp/wildfly/compare/WFLY-508-WFLY-1680-c.
>
> --
> James R. Perkins
> Red Hat JBoss Middleware
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>