[jboss-jira] [JBoss JIRA] (WFLY-7418) Batch deployments with a large number of executed jobs can lock up or slow down the web console

[Timon Zilles (Jira)]

    [ https://issues.jboss.org/browse/WFLY-7418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13759919#comment-13759919 ] 

Timon Zilles commented on WFLY-7418:
------------------------------------

Is there any progress regarding this issue?
In our case we have the problem, that the database selects lead to a timeout during the load of MBeans in JConsole or Hawtio. When we try to connect to JMX the database process has a CPU usage of about 100%, the application therefore slows down and the connection at the end fails because of the timeout, respectively the blocked threads.
With about ~3400 job executions and ~3400 job instances we have approximately 28.000 database selection. On our test environment we have ~160.000 job executions, which leads to the fact that we cannot access the MBeans.
We also tried to remove the MBeans from WildFly, but this is forbidden.
Is there any possibility to prevent the load of the data? We do not need them in the MBean - but in the application, so we cannot simply delete them.

> 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.12.1#712002)