-
Bug
-
Resolution: Done
-
Major
-
3.2.8.Final
-
None
If you use properties in your configuration XML-s (standalone.xml, domain.xml, ...) than several functions become unusable in HAL.
In the source code of HAL, when it creates an operation for example like this
Operation operation = new Operation.Builder(address, READ_RESOURCE_OPERATION)
I couldn't find a case when it contains the line
.param(RESOLVE_EXPRESSIONS, true)
This will cause unresolved expressions to be returned and later numeric errors to be thrown while trying to read them. I attached two examples of this kind of error, which appeared on my console. Bellow I give full details of the case which is related to display runtime batch infos. If you check the following:
@Override
public void update(SubsystemMetadata item) {
ResourceAddress address = BATCH_SUBSYSTEM_TEMPLATE.resolve(statementContext);
Operation operation = new Operation.Builder(address, READ_RESOURCE_OPERATION)
.param(INCLUDE_RUNTIME, true)
.param(RECURSIVE, true)
.build();
dispatcher.execute(operation, result -> {
attributes.refresh(result);
if (result.hasDefined(DEFAULT_THREAD_POOL)) {
String name = result.get(DEFAULT_THREAD_POOL).asString();
ModelNode threadPool = failSafeGet(result, THREAD_POOL + "/" + name);
if (threadPool.isDefined()) {
Elements.setVisible(details, true);
int max = threadPool.get(MAX_THREADS).asInt();
int current = threadPool.get(CURRENT_THREAD_COUNT).asInt();
int largest = threadPool.get(LARGEST_THREAD_COUNT).asInt();
currentThreadCount.update(current, max);
largestThreadCount.update(largest, max);
}
}
});
}
You can see the line:
int max = threadPool.get(MAX_THREADS).asInt();
which causes the numeric error in the HAL browser app. If you add some logging this way:
logger.debug("Batch CLI command: {} ", operation.asCli());
you can check the CLI equivalent of the operation:
/subsystem=batch-jberet:read-resource(include-runtime=true,recursive=true)
The right command should be:
/subsystem=batch-jberet:read-resource(include-runtime=true,recursive=true,resolve-expressions=true)
With the resolved expressions the asInt() method would not throw a numeric exception. To achieve this we should add:
.param(RESOLVE_EXPRESSIONS, true)
Unfortunately another error in the wildfly core must be corrected also, to fix this problem. In the wildfly core the read-resource operation does not resolve expressions recursively. An example for this:
[standalone@localhost:9992 /] /subsystem=batch-jberet:read-resource(include-runtime=true,recursive=true,resolve-expressions=true) { "outcome" => "success", "result" => { "restart-jobs-on-resume" => true, "security-domain" => undefined, "default-job-repository" => "in-memory", "default-thread-pool" => "batch", "in-memory-job-repository" => {"in-memory" => {}}, "jdbc-job-repository" => undefined, "thread-factory" => undefined, "thread-pool" => {"batch" => { "active-count" => 0, "completed-task-count" => 0L, "current-thread-count" => 0, "keepalive-time" => { "time" => 30L, "unit" => "SECONDS" }, "largest-thread-count" => 0, "max-threads" => expression "${batch-max-threads}", "name" => "batch", "queue-size" => 0, "rejected-count" => 0, "task-count" => 0L, "thread-factory" => undefined }} } }
If you change location in the CLI, it will resolve the expression on the current level:
[standalone@localhost:9992 thread-pool=batch] :read-resource(include-runtime=true,resolve-expressions=true) { "outcome" => "success", "result" => { "active-count" => 0, "completed-task-count" => 0L, "current-thread-count" => 0, "keepalive-time" => { "time" => 30L, "unit" => "SECONDS" }, "largest-thread-count" => 0, "max-threads" => "111", "name" => "batch", "queue-size" => 0, "rejected-count" => 0, "task-count" => 0L, "thread-factory" => undefined } }
- is incorporated by
-
JBEAP-20285 [GSS](7.3.z) Upgrade HAL from 3.2.10.Final-redhat-00001 to 3.2.11.Final
-
- Closed
-
-
-
- Closed
-
- is related to
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Closed
-
