[ https://issues.redhat.com/browse/WFLY-14372?page=com.atlassian.jira.plugi... ] Jason Lee commented on WFLY-14372: ---------------------------------- I talked to Jeff about this this morning. He's pretty confident we're not collecting the same metrics twice. With the caveat that I'm still learning this part of the system, I think I agree. The root resources are different, so, if I understand the code correctly, there's no overlap. He and I do agree that the call to hasChildren() is likely superfluous. Looking at that implementation, we see this:   {code:java} @Override public boolean hasChildren(final String childType) { if (BatchJobExecutionResourceDefinition.EXECUTION.equals(childType)) { return !getChildrenNames(BatchJobExecutionResourceDefinition.EXECUTION).isEmpty(); } return delegate.hasChildren(childType); } {code} Chasing that down the code path, the system does iterate over the list of jobs: {code:java} final List<JobExecution> executions = new ArrayList<>(); // Casting to (Supplier<List<JobInstance>>) is done here on purpose as a workaround for a bug in 1.8.0_45 final List<JobInstance> instances = jobOperator.allowMissingJob((Supplier<List<JobInstance>>)() -> jobOperator.getJobInstances(jobName, 0, Integer.MAX_VALUE) , Collections.emptyList()); for (JobInstance instance : instances) { executions.addAll(jobOperator.getJobExecutions(instance)); } children.clear(); for (JobExecution execution : executions) { final String name = Long.toString(execution.getExecutionId()); children.add(name); } {code} For this particular use case, hasChildren() does seem extremely expensive. It seems to me that if we remove the call to hasChildren(), we can eliminate at least one iteration over the children. How much of an improvement that might represent for the user is hard to say without a reproducer, but it seems like it would certainly be noticeable. -- This message was sent by Atlassian Jira (v8.13.1#813001)