The batch-jberet subsystem adds resources to a deployment for each job defined in a job XML file descriptor. If there are many descriptors or descriptors have a large quantity of job executions associated with them, reading the resource through a management operation may result in an OutOfMemoryError.
The issue is caused by the org.wildfly.extension.batch.jberet.deployment.BatchJobExecutionResource which is registers each job execution for a given job. This method is the issue:
/**
* Note the access to the {@link #children} is <strong>not</strong> guarded here and needs to be externally
* guarded.
*/
private void refreshChildren() {
if (System.currentTimeMillis() - lastRefreshedTime < refreshMinInterval) {
return;
}
final List<Long> executionIds = jobOperator.getJobExecutionsByJob(jobName);
final Set<String> asNames = executionIds.stream().map(Object::toString).collect(Collectors.toSet());
children.clear();
children.addAll(asNames);
lastRefreshedTime = System.currentTimeMillis();
}
There is an attempt made not to refresh too fast introduced in WFLY-14275. However, this can still cause issues with very large repositories.
A possible solution is to limit the number of jobs returned by the resource.
- clones
-
JBEAP-30508 [GSS](8.0.z) - WFLY-20773 Large batch repositories can create OutOfMemoryError's when reading the management model
-
- Closed
-
- is related to
-
WFLY-15525 JBeret: Make it possible to limit number of records retrieved via a JDBC store
-
- Closed
-
-
-
- Open
-
-
-
- Closed
-
- relates to
-
-
- Closed
-
