[JBoss JIRA] (WFLY-7418) Batch deployments with a large number of executed jobs can lock up or slow down the web console
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-7418?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-7418:
-------------------------------------
[~dinesh.mahadevan] Unfortunately at this point the best solution is to purge the job repository. To keep the data you could dump it into a different table, but I realize that is less than ideal.
One possible option, which would be a request for enhancement, would be allowing a setting to disable adding batch jobs to the runtime deployment resource. This would however not allow jobs to be seen, started or restarted from web console or via CLI.
> Batch deployments with a large number of executed jobs can lock up or slow down the web console
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-7418
> URL: https://issues.jboss.org/browse/WFLY-7418
> Project: WildFly
> Issue Type: Enhancement
> Components: Batch, Web Console
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Major
> Labels: move_to_halnext
>
> Batch deployments which contain a large number of executed jobs can be extremely slow to process as the {{/deployment=batch.war/subsystem=batch-jberet}} processes each job instance then each job execution of that job instance.
> One possibly helpful option for the web console would be to add a new description attribute to indicate the resource may be slow to process. The web console might be able to run a background task to populate data rather than locking up the UI. There would still be an issue with a large memory footprint here however.
> JBeret might want to consider having a way to archive jobs too rather than just purge them. Some users may want to keep all job execution data. Archiving this data could reduce the size of the current data being retrieved.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-7418) Batch deployments with a large number of executed jobs can lock up or slow down the web console
by Dinesh Mahadevan (Jira)
[ https://issues.jboss.org/browse/WFLY-7418?page=com.atlassian.jira.plugin.... ]
Dinesh Mahadevan commented on WFLY-7418:
----------------------------------------
Hi [~timonz]
+1 on the issue.
Using WildFly 16, we have an application that fails to start until we added -Djboss.as.management.blocking.timeout=6000" allowing the application to start after 2 hours.
Line 581 of class org.jberet.repository.JdbcRepository is the line that appears in almost all thread dumps. Judging from the context, it is executing the SQL from sqls.getProperty(SELECT_JOB_EXECUTIONS_BY_JOB_INSTANCE_ID)
The quickest solution we can find so far is to disable the MicroProfile setting on Wildfly, or purge the job_execution table manually.
{code:java}
<extension module="org.wildfly.extension.elytron"/>
<extension module="org.wildfly.extension.io"/>
<!--<extension module="org.wildfly.extension.microprofile.config-smallrye"/>
<extension module="org.wildfly.extension.microprofile.health-smallrye"/>
<extension module="org.wildfly.extension.microprofile.metrics-smallrye"/>
<extension module="org.wildfly.extension.microprofile.opentracing-smallrye"/>-->
<extension module="org.wildfly.extension.request-controller"/>
<extension module="org.wildfly.extension.security.manager"/>
<subsystem xmlns="urn:jboss:domain:mail:3.0">
<mail-session jndi-name="java:jboss/mail/Default" name="default">
<smtp-server outbound-socket-binding-ref="mail-smtp"/>
</mail-session>
</subsystem>
<!--<subsystem xmlns="urn:wildfly:microprofile-config-smallrye:1.0"/>
<subsystem xmlns="urn:wildfly:microprofile-health-smallrye:1.0" security-enabled="false"/>
<subsystem xmlns="urn:wildfly:microprofile-metrics-smallrye:2.0" exposed-subsystems="*" prefix="${wildfly.metrics.prefix:wildfly}" security-enabled="false"/>
<subsystem xmlns="urn:wildfly:microprofile-opentracing-smallrye:1.0"/>-->
<subsystem xmlns="urn:jboss:domain:naming:2.0">
<remote-naming/>
</subsystem>
{code}
> Batch deployments with a large number of executed jobs can lock up or slow down the web console
> -----------------------------------------------------------------------------------------------
>
> Key: WFLY-7418
> URL: https://issues.jboss.org/browse/WFLY-7418
> Project: WildFly
> Issue Type: Enhancement
> Components: Batch, Web Console
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Major
> Labels: move_to_halnext
>
> Batch deployments which contain a large number of executed jobs can be extremely slow to process as the {{/deployment=batch.war/subsystem=batch-jberet}} processes each job instance then each job execution of that job instance.
> One possibly helpful option for the web console would be to add a new description attribute to indicate the resource may be slow to process. The web console might be able to run a background task to populate data rather than locking up the UI. There would still be an issue with a large memory footprint here however.
> JBeret might want to consider having a way to archive jobs too rather than just purge them. Some users may want to keep all job execution data. Archiving this data could reduce the size of the current data being retrieved.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-3580) [DMN Designer] Decision Table: Add support for merged view
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3580?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton commented on DROOLS-3580:
-------------------------------------------
Thanks [~srambach] for outlining the UX work. +1 to getting visual design look at this as well. [~manstis] is there a target release for the UX updates, we'll need to get in this on [~bdellasc]'s queue for visual design work.
> [DMN Designer] Decision Table: Add support for merged view
> ----------------------------------------------------------
>
> Key: DROOLS-3580
> URL: https://issues.jboss.org/browse/DROOLS-3580
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Affects Versions: 7.17.0.Final
> Reporter: Edson Tirelli
> Assignee: Michael Anstis
> Priority: Minor
> Labels: drools-tools
>
> Add support for viewing the {{DecisionTableGrid}} in _merged_ mode.
> The underlying widget supports merging however I need to check about model synchronisation and where how we'd add a button to toggle merged/unmerged..
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-4507) Ability to externally execute project defined tests.
by Daniele Zonca (Jira)
[ https://issues.jboss.org/browse/DROOLS-4507?page=com.atlassian.jira.plugi... ]
Daniele Zonca commented on DROOLS-4507:
---------------------------------------
_Should the response be the same if kie server is not available or in case if some exception did appeared (container id was not found)_
The envelope object is the same {{ServiceResponse}} but the error message and HTTP code will be different:
- 404: container not found
- 400: malformed scesim file provided
- 200: test executed with OK or KO (a failed test is not a service failure)
- 500: any other unexpected exception
_What should response kie-server in case if container was corrupted_
If the container cannot be retrieved it will fail with 404, otherwise if the kieContainer is available but not valid for any reason it will probably fail with an internal server error
_Should job be restarted if the job at container was not successfully executed?_
Nope, each call is single and there is no internal recovery mechanism
_What roles should the tech user has to complete the execution_
As far as I know it is enough for a user to be part of {{kie-server}} group to be able to execute REST calls
_Is that API should be public in the meaning that we do want to provide it for anyone who has the link, or we could allow the execution for person who sends certain header information?_
There is no specific requirement for this new service so it will be used the same group based filtering of other services
_Shouldn't we save somewhere the userId who launched the scesim?_
There is no audit requirement for this new service
> Ability to externally execute project defined tests.
> ----------------------------------------------------
>
> Key: DROOLS-4507
> URL: https://issues.jboss.org/browse/DROOLS-4507
> Project: Drools
> Issue Type: Enhancement
> Components: Scenario Simulation and Testing
> Reporter: Paul Brown
> Assignee: Daniele Zonca
> Priority: Major
>
> Provide the ability to externally invoke project define tests scenario i.e via a rest api.
> This is required in order for project defined tests to be reused and executed as part of a delivery pipeline and not from within business central.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-12718) Clustering: replicated-cache sampling errors
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-12718?page=com.atlassian.jira.plugin... ]
Paul Ferraro commented on WFLY-12718:
-------------------------------------
As we discussed a number of times, there is something wrong with your MOD_JK configuration. Until this is fixed, it's not worth running, as it obfuscates the issue.
This log:
{noformat}
2019-11-04 11:24:52,121 ERROR o.j.e.c.j.ClusteringHTTPRequestSampler: Invalid serial: Expected 122, received 2 (previous: JSessionId{sessionId='bc844XEHEsfXWP4rcLnxVcIyr9TDcx4S-ULHzef9', jvmRoutes=[wildfly3]} current: JSessionId{sessionId='bc844XEHEsfXWP4rcLnxVcIyr9TDcx4S-ULHzef9', jvmRoutes=[wildfly1]})
samples sequence:
{noformat}
This suggests that the session state was lost in the previous request - are there log messages that indicate why?
> Clustering: replicated-cache sampling errors
> --------------------------------------------
>
> Key: WFLY-12718
> URL: https://issues.jboss.org/browse/WFLY-12718
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 18.0.0.Final
> Reporter: Tommasso Borgato
> Assignee: Paul Ferraro
> Priority: Blocker
>
> The issue is about replicated-cache in fail-over tests.
> WildFly is started in clustered mode using a replicated cache for replicating HTTP session data across cluster nodes; all 4 nodes in the cluster are initialized with the following cli script:
> {noformat}
> embed-server --server-config=standalone-ha.xml
> /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=tcp)
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl:add()
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=locking:write-attribute(name=isolation, value=REPEATABLE_READ)
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/component=transaction:write-attribute(name=mode, value=BATCH)
> /subsystem=infinispan/cache-container=web/replicated-cache=testRepl/store=file:add()
> /subsystem=infinispan/cache-container=web:write-attribute(name=default-cache, value=testRepl)
> {noformat}
> The test is run with wildfly-18.0.0.Final.zip;
> The same tests run with version wildfly-17.0.1.Final.zip do not have any problem;
> hence this looks like a regression;
> As usual, we test that the serial value stored in the replicated cache is incremented at every call: when this is not true, we say we have a sampling error;
> Here are the runs that exhibit this issue:
> - **22.82% Fail Rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#23|https://eap-qe-jenkins.r...]
> - **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#24|https://eap-qe-jenkins.r...]
> We also repeated the tests to make sure it can be reproduced:
> - **22.75% Fail rate with WildFly-18 ** [eap-7.x-clustering-http-session-shutdown-repl#26|https://eap-qe-jenkins.r...]
> - **0% Fail Rate with WildFly-17 ** [eap-7.x-clustering-http-session-shutdown-repl#25|https://eap-qe-jenkins.r...]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (JGRP-2393) JmxConfigurator creates an invalid object name when fixing duplicates
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2393?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2393.
----------------------------
Resolution: Done
> JmxConfigurator creates an invalid object name when fixing duplicates
> ---------------------------------------------------------------------
>
> Key: JGRP-2393
> URL: https://issues.jboss.org/browse/JGRP-2393
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.6
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.1.8
>
>
> {noformat}
> javax.management.MalformedObjectNameException: Unterminated key property part
> at javax.management.ObjectName.construct(ObjectName.java:559) ~[?:?]
> at javax.management.ObjectName.<init>(ObjectName.java:1406) ~[?:?]
> at org.jgroups.jmx.JmxConfigurator.getObjectName(JmxConfigurator.java:206) ~[jgroups-4.1.6.Final.jar:4.1.6.Final]
> at org.jgroups.jmx.JmxConfigurator.internalRegister(JmxConfigurator.java:173) ~[jgroups-4.1.6.Final.jar:4.1.6.Final]
> at org.jgroups.jmx.JmxConfigurator.register(JmxConfigurator.java:121) ~[jgroups-4.1.6.Final.jar:4.1.6.Final]
> at org.jgroups.jmx.JmxConfigurator.registerChannel(JmxConfigurator.java:62) ~[jgroups-4.1.6.Final.jar:4.1.6.Final]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:520) ~[classes/:?]
> {noformat}
> The generated object name is {{ClusteredCLITest:type=channel,cluster="org.infinispan.cli.interpreter.ClusteredCLITest"duplicate-52510}}, which is not valid because {{duplicate-52510}} is not part of any key=value pair.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-12689) WAR deployment fails due to NPE when both MBean and persistence-unit are packaged
by Romain Pelisse (Jira)
[ https://issues.jboss.org/browse/WFLY-12689?page=com.atlassian.jira.plugin... ]
Romain Pelisse updated WFLY-12689:
----------------------------------
Labels: downstream_dependency (was: )
> WAR deployment fails due to NPE when both MBean and persistence-unit are packaged
> ---------------------------------------------------------------------------------
>
> Key: WFLY-12689
> URL: https://issues.jboss.org/browse/WFLY-12689
> Project: WildFly
> Issue Type: Bug
> Components: JMX, JPA / Hibernate, Server
> Affects Versions: 18.0.0.Final
> Reporter: Masafumi Miura
> Assignee: Masafumi Miura
> Priority: Major
> Labels: downstream_dependency
> Fix For: 19.0.0.Beta1
>
>
> When a web application contains both MBean (jboss-service.xml) and persistence-unit (persistence.xml), the WAR deployment fails due to the following NullPointerException:
> {code}
> 11:51:03,041 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."helloworld-mbean-webapp.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."helloworld-mbean-webapp.war".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "helloworld-mbean-webapp.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:183)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException
> at org.jboss.as.service.MBeanServices.<init>(MBeanServices.java:107)
> at org.jboss.as.service.ParsedServiceDeploymentProcessor.addServices(ParsedServiceDeploymentProcessor.java:124)
> at org.jboss.as.service.ParsedServiceDeploymentProcessor.deploy(ParsedServiceDeploymentProcessor.java:109)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:176)
> ... 8 more
> ...(snip)...
> 11:51:03,687 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "helloworld-mbean-webapp.war")]) - failure description: {
> "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"helloworld-mbean-webapp.war\".INSTALL" => "WFLYSRV0153: Failed to process phase INSTALL of deployment \"helloworld-mbean-webapp.war\"
> Caused by: java.lang.NullPointerException"},
> "WFLYCTL0412: Required services that are not installed:" => [
> "jboss.deployment.unit.\"helloworld-mbean-webapp.war\".WeldStartService",
> "jboss.deployment.unit.\"helloworld-mbean-webapp.war\".beanmanager"
> ],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => [
> "jboss.deployment.unit.\"helloworld-mbean-webapp.war\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"helloworld-mbean-webapp.war\".WeldStartService, jboss.deployment.unit.\"helloworld-mbean-webapp.war\".beanmanager]",
> "jboss.deployment.unit.\"helloworld-mbean-webapp.war\".batch.artifact.factory is missing [jboss.deployment.unit.\"helloworld-mbean-webapp.war\".beanmanager]"
> ]
> }
> {code}
> This NPE happens because [WebNonTxEmCloserAction#dependencies()|https://github.com/wildfly/wildfly/...] returns null. It should return Collections.emptySet() instead of null.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month