I have a blocking-bounded-queue-thread-pool and using the jboss-cli.bat I'm unable to set the attribute 'undefined'. I've tried various things, such as: /subsystem=threads/blocking-bounded-queue-thread-pool=poo/:write-attribute(name=core-threads) /subsystem=threads/blocking-bounded-queue-thread-pool=poo/:undefine-attribute(name=core-threads) but both return: { "outcome" => "failed", "failure-description" => "JBAS014749: Operation handler failed: null", "rolled-back" => true } Given the description I see, "core-threads : The core thread pool size which is smaller than the maximum pool size. If undefined, the core thread pool size is the same as the maximum thread pool size.", it seems I should be able to get to the undefined value in order to get the default behavior. Using EAP 6.3, but I think earlier versions may be the same. I would expect to be able to undefine/set to null, regardless of its current setting.
I get this: [standalone@localhost:9999 /] /subsystem=threads/blocking-bounded-queue-thread-pool=pool:undefine-attribute(name=core-threads) { "outcome" => "failed", "failure-description" => "JBAS014749: Operation handler failed: java.lang.IllegalArgumentException", "rolled-back" => true } I don't know why you got a different failure. I thought perhaps it was the incorrect / before the : but even with that I get the failure above. That's a tangent though. The problem is server side, not in the CLI. The attribute doesn't have a default value but the handler for writes doesn't deal with undefined properly. I'm setting the component for this to Domain Management even though it's in a subsystem. But this little-used subsystem has no component in BZ.
The fix is to have the write-attribute handler work the same as the add handler, and configure the runtime make core-threads match max-threads if the attribute is undefined.
Brian, is it OK that core-threads value can exceed the max-threads value?
Verified on EAP 6.4.0.DR6.