-
Bug
-
Resolution: Duplicate
-
Minor
-
None
-
7.0.0.DR8
There is a non-intuitive behavior of setting the process-id-* attributes via jboss cli.
When I want to set process-id-socket-binding I need to use composite batch operation
batch
/subsystem=transactions:undefine-attribute(name=process-id-uuid)
/subsystem=transactions:write-attribute(name=process-id-socket-binding, value="txn-status-manager")
run-batch
If not using batch operation I get errors
/subsystem=transactions:undefine-attribute(name=process-id-uuid)
{
"outcome" => "failed",
"failure-description" => "WFLYTX0025: Either process-id-uuid must be 'true' or process-id-socket-binding must be defined.",
"rolled-back" => true
}
[standalone@localhost:9990 /] /subsystem=transactions:write-attribute(name=process-id-socket-binding, value="txn-status-manager")
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0105: process-id-uuid is invalid in combination with process-id-socket-binding",
"rolled-back" => true
}
First inconsistency is that I can't use :write-attribute(name=process-id-uuid, value=false) but I have to run :undefine-attribute.
Then the other strange thing is setting the attribute process-id-uuid back to live. I can't use composite operation as it fails.
/subsystem=transactions:write-attribute(name=process-id- process-id-socket-binding process-id-socket-max-ports process-id-uuid /subsystem=transactions:write-attribute(name=process-id-uuid, value=true) run-batch The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0155: process-id-socket-binding may not be null"}}
If I want to set the attribute back I have to use simply
/subsystem=transactions:write-attribute(name=process-id-uuid, value=true)
which undefine the process-id-socket-binding automatically.
I think that composite operation could not be demanded and /subsystem=transactions:write-attribute(name=process-id-socket-binding, value="txn-status-manager") could undefine process-id-uuid automatically as this behaves from other direction.
Or description of failures should be changed to inform how to proceed the change (batch is needed etc.)
On the other hand composite operation of setting process-id-uuid back should not fail I think.
- is cloned by
-
-
- Closed
-
