Running Batch During Undeploy
by James R. Perkins
While doing some testing with batch we discovered somewhat of a corner
case in where you have submitted a batch job then decided to explicitly
undeploy the application or something triggers an undeploy. The batch
thread will continue to run which causes issues if the start on the
batch is called again. My theory is the old batch environment is being
used as it's still alive in the thread.
This begs the question though what should happen if a batch job is
running and an undeploy is invoked? Should we fail the undeploy? Should
we kill all batch jobs (probably not ideal)? Luckily for us the spec
says... ...nothing.
--
James R. Perkins
Red Hat JBoss Middleware
13 years
Rework of Widlfly ThreadLocals
by Eduardo Martins
During the recent work wrt JSR 236 aka EE Concurrency I become aware that there is room for enhancing management of thread locals, which support setup and retrieval of invocation context within Wildfly, so I volunteer to do such task. Besides removing duplicated data (and the effort to manage it), this would make it much easier for the different models we currently support, for instance interceptors and web setup actions, to do their jobs.
My idea is to centralise all in a single thread local for the whole Wildfly server, which then would contain entries for each subsystem and perhaps the MSC service container (removing the need for the static CurrentServiceContainer), or at most one thread local per subsystem. From this then I would start modelling each subsystem context from existing thread locals.
Thoughts?
--E
13 years
discussion about JSR352 Batch and JPA
by Scott Marlow
What are the requirements for supporting Batch section 11.6 [1]? From
looking at JSR352, I get that each "chunk" has its own JTA transaction.
I previously had heard that we only supported starting the transaction
from the application processing code (via UserTransaction) but I think
the Batch container/runtime should start a JTA transaction for each
"chunk" that is processed. What are we really doing for managing the
JTA transactions for batch?
REGULAR CHUNK PROCESSING & JPA
For the JPA support for regular chunk processing [1], the following will
give a new underlying persistence context per chunk (jta tx):
@PersistenceContext(unitName = "chunkNonpartitionedAZTT4443334")
EntityManager em;
PARTITIONED CHUNK PROCESSING & JPA
For the JPA support for partitioned chunk processing [2], the following
will give a new underlying persistence context per chunk (jta tx):
@PersistenceContext(unitName = "chunkpartitionedAZTT4443334")
EntityManager em;
One concern that I have about partitioning is the performance impact of
deadlocking and waiting for the JTA transaction to time out. Depending
on whether the work is configured to retry or not, hitting several dead
locks in a batch process could defeat some of the performance gains of
partitioning. Avoiding deadlocks by always reading/writing/locking the
underlying database resources in the same exact order, would help avoid
deadlocks.
Beyond the basic JPA capability of ensuring that each "chunk", has its
own persistence context, how else can we help the batch processing
experts writing JSR-352 applications on WildFly/Hibernate?
Anything else to discuss about JPA & Batch?
[1] Batch spec section section 11.6 Regular Chunk Processing
https://gist.github.com/scottmarlow/6603746
[2] Batch spec section Batch 11.7 Partitioned Chunk Processing
https://gist.github.com/scottmarlow/6607667
[3] persistence.xml https://gist.github.com/scottmarlow/6608533
13 years
Add Log Category, Name cannot be specified
by Frank Langelage
Using latest WF8 build from sources.
On Web-Console when trying to add a new log category, the dialog window
opens, but the Name field is locked. Indicated by a small padlock right
to the field.
Only "Log Level" and "Use Parent Handlers" are changeable.
Since I update WF regularly and also use this dialog regularly the
problem cannot be there for a long time.
It all time worked for me in the past.
Regards, Frank
13 years
Re: [wildfly-dev] [jboss-as7-dev] Enhancements do EAP 6.1 console
by Heiko Braun
Thanks Claudio, I think most of your proposed enhancements are reasonable ones...
On Sep 16, 2013, at 3:29 PM, Claudio Miranda <claudio(a)claudius.com.br> wrote:
> * in runtime -> manage deployments -> the filter textfield, case
> insensitive and filter by any string, not only in the beginning.
+1
> * in the same deployments view, sort by case insensitive
+1
> * in Hosts -> server configuration or server groups -> java
> properties, edit java properties, currently only add/remove is
> supported
-1
> * in runtime -> server status -> environment the filter textfield,
> case insensitive and filter by any string, not only in the beginning.
+1
> * show deployment meta information: date and time of deployment (in
> fact the date and time of the "content" file in data/content/ hashed
> directory), also shows the hashed string in
+1
> * in domain mode, when click at some deployment, all the text input
> below are editable, disable them.
upstream already
> * in runtime -> manage deployment -> shows the web context name, for
> .war deployments (open and inspect jboss-web.xml if exists)
upstream already
> * when assign a deployment, support to assign to multiple groups.
it's supported, try multiple select
> * see server.log and host-controller
i've been requesting this for along time. It depends on
https://issues.jboss.org/browse/WFLY-280
> * in runtime -> overview, displays the HC and servers address and port.
+1
> * in runtime -> manage deployments, shows a hint, the application is
> disabled for some group. If any application is disabled, it is not
> displayed, can lead user to think there are deployment error, but the
> fact is that the application is disabled.
+1 but might not be trivial
13 years
Re: [wildfly-dev] [jboss-as7-dev] Enhancements do EAP 6.1 console
by Kabir Khan
Hi,
I've forwarded to the wildfly list, the one you used is superceded by this. Heiko in CC is the console lead, and can provide details for how to submit patches to the console.
On 16 Sep 2013, at 14:29, Claudio Miranda wrote:
> Hi, I want to make some small enhancements, how is the review process ?
>
> I want to make sure I follow all guidelines before submit.
>
> Some enhancements
>
> * in runtime -> manage deployments -> the filter textfield, case
> insensitive and filter by any string, not only in the beginning.
> * in the same deployments view, sort by case insensitive
> * in Hosts -> server configuration or server groups -> java
> properties, edit java properties, currently only add/remove is
> supported
> * in runtime -> server status -> environment the filter textfield,
> case insensitive and filter by any string, not only in the beginning.
> * show deployment meta information: date and time of deployment (in
> fact the date and time of the "content" file in data/content/ hashed
> directory), also shows the hashed string in
> * in domain mode, when click at some deployment, all the text input
> below are editable, disable them.
> * in runtime -> manage deployment -> shows the web context name, for
> .war deployments (open and inspect jboss-web.xml if exists)
> * when assign a deployment, support to assign to multiple groups.
> * see server.log and host-controller
> * in runtime -> overview, displays the HC and servers address and port.
> * in runtime -> manage deployments, shows a hint, the application is
> disabled for some group. If any application is disabled, it is not
> displayed, can lead user to think there are deployment error, but the
> fact is that the application is disabled.
>
> I understand all issues must go to JIRA, but I would like to discuss
> those enhancements here, perhaps needs some discussion before going to
> jira, and I want to spend the effort in those enhancements that are
> easier to get through PR process.
>
> Thanks.
>
> --
> Claudio Miranda
>
> claudio(a)claudius.com.br
> http://www.claudius.com.br
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
13 years
Fwd: Re: [jboss-as7-dev] build failure using Oracle JDK, sun.tools.jconsole.Resources#getText() missing
by James R. Perkins
Didn't notice this wasn't sent to wildfly-dev.
-------- Original Message --------
Subject: Re: [jboss-as7-dev] build failure using Oracle JDK,
sun.tools.jconsole.Resources#getText() missing
Date: Sat, 14 Sep 2013 11:41:59 -0700
From: James R. Perkins <jperkins(a)redhat.com>
To: jboss-as7-dev(a)lists.jboss.org
I'm seeing the same thing. I switched to the Oracle JDK 1.7.0_40 and it
still doesn't work.
I had to downgrade to 1.7.0_25.
On 09/14/2013 03:11 AM, Frank Langelage wrote:
> Current Wildfly 8 master does not build for me any more.
> Caused by recent commit
> https://github.com/wildfly/wildfly/commit/b0683f6a4a01feab41f292c49de20f7...
> Thursday.
>
> I'm using Oracle JDK 1.70_40 on Solaris SPARC 10.
> The method sun.tools.jconsole.Resources#getText() used there does not
> exists in JDK.
> Seems to be only available in OpenJDK.
>
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building WildFly: Command line interface 8.0.0.Beta1-SNAPSHOT
> [INFO]
> ------------------------------------------------------------------------
> [INFO]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ wildfly-cli ---
> [INFO] Deleting /home/jboss/WildFly-8.0/wildfly/cli/target
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.3.1:enforce (ban-bad-dependencies) @
> wildfly-cli ---
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-java-version) @
> wildfly-cli ---
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-maven-version) @
> wildfly-cli ---
> [INFO]
> [INFO] --- buildnumber-maven-plugin:1.2:create-timestamp
> (get-build-timestamp) @ wildfly-cli ---
> [INFO]
> [INFO] --- buildnumber-maven-plugin:1.2:create (get-scm-revision) @
> wildfly-cli ---
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> wildfly-cli ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 41 resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @
> wildfly-cli ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 254 source files to
> /home/jboss/WildFly-8.0/wildfly/cli/target/classes
> [INFO] -------------------------------------------------------------
> [WARNING] COMPILATION WARNING :
> [INFO] -------------------------------------------------------------
> [WARNING]
> /home/jboss/WildFly-8.0/wildfly/cli/src/main/java/org/jboss/as/cli/gui/OperationDialog.java:
> Some input files use unchecked or unsafe operations.
> [WARNING]
> /home/jboss/WildFly-8.0/wildfly/cli/src/main/java/org/jboss/as/cli/gui/OperationDialog.java:
> Recompile with -Xlint:unchecked for details.
> [INFO] 2 warnings
> [INFO] -------------------------------------------------------------
> [INFO] -------------------------------------------------------------
> [ERROR] COMPILATION ERROR :
> [INFO] -------------------------------------------------------------
> [ERROR]
> /home/jboss/WildFly-8.0/wildfly/cli/src/main/java/org/jboss/as/cli/gui/ConnectDialog.java:[161,53]
> cannot find symbol
> symbol: method getText(java.lang.String)
> location: class sun.tools.jconsole.Resources
> [ERROR]
> /home/jboss/WildFly-8.0/wildfly/cli/src/main/java/org/jboss/as/cli/gui/ConnectDialog.java:[219,52]
> cannot find symbol
> symbol: method getText(java.lang.String)
> location: class sun.tools.jconsole.Resources
> [ERROR]
> /home/jboss/WildFly-8.0/wildfly/cli/src/main/java/org/jboss/as/cli/gui/ConnectDialog.java:[276,44]
> cannot find symbol
> symbol: method getText(java.lang.String)
> location: class sun.tools.jconsole.Resources
> [ERROR]
> /home/jboss/WildFly-8.0/wildfly/cli/src/main/java/org/jboss/as/cli/gui/ConnectDialog.java:[286,44]
> cannot find symbol
> symbol: method getText(java.lang.String)
> location: class sun.tools.jconsole.Resources
> [INFO] 4 errors
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
James R. Perkins
Red Hat JBoss Middleware
13 years
Batch Integration
by James R. Perkins
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
13 years
Batch Subsystem Model
by James R. Perkins
I'm struggling a bit come up with the right model for the batch
subsystem. The XML currently looks like the following, but doesn't have
to remain like this if someone has a better idea.
<subsystem xmlns="urn:jboss:domain:batch:1.0">
<job-repository value="default"/>
<job-repository-type name="default">
<in-memory thread-pool-name="default"/>
</job-repository>
<job-repository-type name="jdbc">
<jdbc thread-pool-name="default">
<datasource jndi-name="java:jboss/datasources/ExampleDS"/>
</jdbc>
</job-repository>
<unbounded-queue-thread-pool name="default">
<max-threads count="10"/>
<keepalive-time time="100" unit="milliseconds"/>
</unbounded-queue-thread-pool>
</subsystem>
This would make the model for the in-memory type something like;
"subsystem" => {
"batch" => {
"job-repository" => "default",
"job-repository-type" => {"default" => {
"type" => "in-memory",
"thread-pool-name" => "default"
}}
}
}
The problem is I'm not sure what to do with JDBC which would also need a
datasource/jndi-name attribute, but I don't want that attribute on the
in-memory type.
Another thought I had was to have it look more like;
"subsystem" => {
"batch" => {
"job-repository" => "default",
"in-memory" => {"default" => {
"thread-pool-name" => "default"
}},
"jdbc" => {"jdbc" => {
"thread-pool-name" => "default",
"jndi-name" => "java:jboss/datasources/ExampleDS"
}}
}
}
The problem here is really the jdbc resource could also be called
default. I'm not sure if there is a way to query a parent resource to
check each name, but if there is then maybe that's the way to go.
Anyway, if anyone has suggestions let me know.
--
James R. Perkins
Red Hat JBoss Middleware
13 years
Configurable implicit module imports
by Bill Burke
The whole JSON-JAXRS support is a *bleepin* mess....
* You have old users that want to use Jettison to generate JSON from JAXB.
* You have new users that want to use Jackson to generate JSON from JAXB.
* Jackson 1.x is a completely different Java package than Jackson 2.x.
With that you have old users that want to use 1.x new users that want to
use 2.x.
Given that, it would be nice to have one place where they can set up the
default implicit imports that come with Resteasy/JAX-RS subsystem.
Someplace where they could configure this without it being hardcoded so
we can support older apps that are migrating to Wildfly . Quite
honestly I scratch my head trying to figure out why you guys decided it
was a good idea to hardcode implicit module imports.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
13 years
