[jboss-jira] [JBoss JIRA] (WFLY-2623) Unable to change process-id mechanism from process-id-uuid to process-id-socket-binding on transaction

[Ondřej Chaloupka (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099428#comment-13099428 ] 

Ondřej Chaloupka edited comment on WFLY-2623 at 8/18/15 9:36 AM:
-----------------------------------------------------------------

I have been looking at this during EAP DR8 testing and I put my "UX feelings" :) as description of WFLY-5126 (I've put it as duplication issue as this one in fact covers the trouble that I described in WFLY-5126)

As have been discussed here it's possible to set {{process-id-uuid}} or {{process-id-socket-binding}} in either way.
{code}
batch
/subsystem=transactions:undefine-attribute(name=process-id-uuid)
/subsystem=transactions:write-attribute(name=process-id-socket-binding, value="txn-status-manager")
run-batch
{code}
{code}
/subsystem=transactions:write-attribute(name=process-id-uuid, value=true)
{code}

This is a bit confusing how it's done. Could this be enhanced from user point of view?

My ideas is like
maybe 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 setting direction. Or maybe description of failures could be changed to inform user that batch operation is needed.
And on the other hand composite operation when setting {{process-id-uuid}} and unsetting {{process-id-socket-binding}} should not fail I think.
Last thing is that {{:write-attribute(name=process-id-uuid, value=false}} in composite operation should not fail.


was (Author: ochaloup):
I have been looking at this during EAP DR8 testing and I put my "UX feelings" :) as description of WFLY-5126 (I've put it as duplication issue as this one in fact covers the trouble that I described in WFLY-5126)

As have been discussed here it's possible to set {{process-id-uuid}} or {{process-id-socket-binding}} in either way. But it's a bit confusing how it's done. Could this be enhanced from user point of view?

My ideas is like
maybe 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 setting direction. Or maybe description of failures could be changed to inform user that batch operation is needed.
And on the other hand composite operation when setting {{process-id-uuid}} and unsetting {{process-id-socket-binding}} should not fail I think.
Last thing is that {{:write-attribute(name=process-id-uuid, value=false}} in composite operation should not fail.

> Unable to change process-id mechanism from process-id-uuid to process-id-socket-binding on transaction 
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2623
>                 URL: https://issues.jboss.org/browse/WFLY-2623
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 10.0.0.Beta1
>            Reporter: Amos Feng
>            Assignee: Hayk Hovsepyan
>            Priority: Critical
>              Labels: transaction
>             Fix For: 8.0.0.Final
>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1036739
> process-id mechanism can not be changed from process-id-uuid to process-id-socket-binding.
> The following ERROR occurred at JBoss start-up:
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 44) JBAS014613: Operation ("add") failed - address: ([("subsystem" => "transactions")]) - failure description: "JBAS014746: process-id-uuid may not be null"
> {noformat}
> The root reason is it does not check the PROCESS_ID_UUID if defined when booting the coreEnvironment service in TransactionSubsytemAdd.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)