[JBoss JIRA] (WFLY-12121) Transaction JDBC object store CLI operation fails when set to false with information JDBC connection is needed
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-12121?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka updated WFLY-12121:
------------------------------------
Description:
If the JDBC store is for to be disabled it's needed to be used CLI command
{code}
/subsystem=transactions:write-attribute(name=use-jdbc-store, value=false)
{code}
(see documentation https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...)
but when a data source is not configured then even when it's to be set to false there is an error that such operation is not possible
{code}
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0380: Attribute 'jdbc-store-datasource' needs to be set or passed before attribute 'use-jdbc-store' can be correctly set",
"rolled-back" => true
}
{code}
I would expect that when I want to disable the jdbc store I don't need to provide a data source for a connection before. Setting-up the {{false}} should not throw an error in CLI.
was:
If the JDBC store is for to be disabled it's needed to be used CLI command
{code}
/subsystem=transactions:write-attribute(name=use-jdbc-store, value=false)
{code}
(see documentation https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...)
but when a datasource is not configured then even when it's to be set to false there is error that such operation is not possible
{code}
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0380: Attribute 'jdbc-store-datasource' needs to be set or passed before attribute 'use-jdbc-store' can be correctly set",
"rolled-back" => true
}
{code}
I would expect that when I won't to disable jdbc store I don't need to provide a datasource for connection before. Setting-up the {{false}} should not throw an error in CLI.
> Transaction JDBC object store CLI operation fails when set to false with information JDBC connection is needed
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12121
> URL: https://issues.jboss.org/browse/WFLY-12121
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Minor
>
> If the JDBC store is for to be disabled it's needed to be used CLI command
> {code}
> /subsystem=transactions:write-attribute(name=use-jdbc-store, value=false)
> {code}
> (see documentation https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...)
> but when a data source is not configured then even when it's to be set to false there is an error that such operation is not possible
> {code}
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0380: Attribute 'jdbc-store-datasource' needs to be set or passed before attribute 'use-jdbc-store' can be correctly set",
> "rolled-back" => true
> }
> {code}
> I would expect that when I want to disable the jdbc store I don't need to provide a data source for a connection before. Setting-up the {{false}} should not throw an error in CLI.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12099) Cannot change transaction log store type via CLI
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-12099?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka commented on WFLY-12099:
-----------------------------------------
When I'm playing with it I found a small error (at least from my PoV): https://issues.jboss.org/browse/WFLY-12121
> Cannot change transaction log store type via CLI
> ------------------------------------------------
>
> Key: WFLY-12099
> URL: https://issues.jboss.org/browse/WFLY-12099
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 17.0.0.Alpha1
> Reporter: Kabir Khan
> Assignee: Ondrej Chaloupka
> Priority: Critical
>
> For the OpenShift image work we need to be able to handle configuration of datasources. There is an effort underway to replace the current template marker replacement done in standalone.xml with CLI commands.
> While this works for the datasource subsystem itself, the OpenShift image scripts also touch other subsystems. For example if it is configured to use the Tx subsystem JDBC log store, we need to change the value of the /subsystem=transactions/log-store=log-store's 'type' attribute and to set the values of jdbc-action-store-table-prefix, jdbc-communication-store-table-prefix and jdbc-state-store-table-prefix and jdbc-store-datasource attributes on the subsystem itself.
> The equivalent in the existing xml marker replacement is to inject the following xml into the subsystem (the 'os77c791d37250' is calculated by the OpenShift launch scripts):
> {code}
> <jdbc-store datasource-jndi-name="java:jboss/datasources/testtx_postgresqlObjectStore">
> <action table-prefix="os77c791d37250"/>
> <communication table-prefix="os77c791d37250"/>
> <state table-prefix="os77c791d37250"/>
> </jdbc-store>
> {code}
> However, this is not possible to do via CLI. Starting the server without a jdbc-store, you end up with the following
> {code}
> [standalone@localhost:9990 /] /subsystem=transactions/log-store=log-store:read-resource
> {
> "outcome" => "success",
> "result" => {
> "type" => "default",
> "transactions" => undefined
> }
> }
> {code}
> If you try to write the 'type' attribute it gives the error than it is read-only
> {code}
> [standalone@embedded /] /subsystem=transactions/log-store=log-store:write-attribute(name=type, value=jdbc)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0048: Attribute type is not writable",
> "rolled-back" => true
> }
> {code}
> If you try to delete the resource and add it again, it gives another error:
> {code}
> [standalone@embedded /] /subsystem=transactions/log-store=log-store:remove
> {
> "outcome" => "success",
> "result" => undefined
> }
> [standalone@embedded /] /subsystem=transactions/log-store=log-store:add(type=jdbc)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0212: Duplicate resource [
> (\"subsystem\" => \"transactions\"),
> (\"log-store\" => \"log-store\")
> ]",
> "rolled-back" => true
> }
> {code}
> Despite the change looking like it has taken effect:
> {code}
> [standalone@embedded /] /subsystem=transactions/log-store=log-store:read-resource
> {
> "outcome" => "success",
> "result" => {
> "type" => "jdbc",
> "transactions" => undefined
> }
> }
> {code}
> However, it is not persisted in xml, so restarting the server it says the type is 'default' again
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12121) Transaction JDBC object store CLI operation fails when set to false with information JDBC connection is needed
by Ondrej Chaloupka (Jira)
Ondrej Chaloupka created WFLY-12121:
---------------------------------------
Summary: Transaction JDBC object store CLI operation fails when set to false with information JDBC connection is needed
Key: WFLY-12121
URL: https://issues.jboss.org/browse/WFLY-12121
Project: WildFly
Issue Type: Bug
Components: Transactions
Reporter: Ondrej Chaloupka
Assignee: Ondrej Chaloupka
If the JDBC store is for to be disabled it's needed to be used CLI command
{code}
/subsystem=transactions:write-attribute(name=use-jdbc-store, value=false)
{code}
(see documentation https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...)
but when a datasource is not configured then even when it's to be set to false there is error that such operation is not possible
{code}
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0380: Attribute 'jdbc-store-datasource' needs to be set or passed before attribute 'use-jdbc-store' can be correctly set",
"rolled-back" => true
}
{code}
I would expect that when I won't to disable jdbc store I don't need to provide a datasource for connection before. Setting-up the {{false}} should not throw an error in CLI.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12099) Cannot change transaction log store type via CLI
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-12099?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka edited comment on WFLY-12099 at 5/24/19 4:54 AM:
------------------------------------------------------------------
Hi [~kabirkhan],
I'm sorry for not getting to this sooner. But with your permission, I'm closing this as not a bug. If you consider that's not correct feel free to reopen and we can discuss more.
The way how to set up the JDBC object store is explained in steps in doc (https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...) so from the technical perspective I would mention that it's needed to be used the operation {{/subsystem=transactions:write-attribute(name=use-jdbc-store, value=true)}}. The operation should change the datastore type from the default/journal to jdbc.
For the JDBC that the datasource is defined to be with {{jta}} set to {{false}}.
For set up the horneq/journal there is equivalent command
{{/subsystem=transactions:write-attribute(name=use-journal-store, value=true)}}
To set the default one you need to run "back" with false.
{{/subsystem=transactions:write-attribute(name=use-journal-store, value=false)}}
I understand that the usage of the CLI is not intuitive as it does not follow how other subsystems are configured. But that's all that I'm able to say to it. I just do how it was done.
was (Author: ochaloup):
Hi [~kabirkhan],
I'm sorry for not getting to this sooner. But with your permission, I'm closing this as not a bug. If you consider that's not correct feel free to reopen and we can discuss more.
The way how to set up the JDBC object store is explained in steps in doc (https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...) so from the technical perspective I would mention that it's needed to be used the operation {{/subsystem=transactions:write-attribute(name=use-jdbc-store, value=true)}}. Ensure that the datasource is defined to be with {{jta}} set to {{false}}.
I understand that the usage of the CLI is not intuitive as it does not follow how other subsystems are configured. But that's all that I'm able to say to it. I just do how it was done.
> Cannot change transaction log store type via CLI
> ------------------------------------------------
>
> Key: WFLY-12099
> URL: https://issues.jboss.org/browse/WFLY-12099
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 17.0.0.Alpha1
> Reporter: Kabir Khan
> Assignee: Ondrej Chaloupka
> Priority: Critical
>
> For the OpenShift image work we need to be able to handle configuration of datasources. There is an effort underway to replace the current template marker replacement done in standalone.xml with CLI commands.
> While this works for the datasource subsystem itself, the OpenShift image scripts also touch other subsystems. For example if it is configured to use the Tx subsystem JDBC log store, we need to change the value of the /subsystem=transactions/log-store=log-store's 'type' attribute and to set the values of jdbc-action-store-table-prefix, jdbc-communication-store-table-prefix and jdbc-state-store-table-prefix and jdbc-store-datasource attributes on the subsystem itself.
> The equivalent in the existing xml marker replacement is to inject the following xml into the subsystem (the 'os77c791d37250' is calculated by the OpenShift launch scripts):
> {code}
> <jdbc-store datasource-jndi-name="java:jboss/datasources/testtx_postgresqlObjectStore">
> <action table-prefix="os77c791d37250"/>
> <communication table-prefix="os77c791d37250"/>
> <state table-prefix="os77c791d37250"/>
> </jdbc-store>
> {code}
> However, this is not possible to do via CLI. Starting the server without a jdbc-store, you end up with the following
> {code}
> [standalone@localhost:9990 /] /subsystem=transactions/log-store=log-store:read-resource
> {
> "outcome" => "success",
> "result" => {
> "type" => "default",
> "transactions" => undefined
> }
> }
> {code}
> If you try to write the 'type' attribute it gives the error than it is read-only
> {code}
> [standalone@embedded /] /subsystem=transactions/log-store=log-store:write-attribute(name=type, value=jdbc)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0048: Attribute type is not writable",
> "rolled-back" => true
> }
> {code}
> If you try to delete the resource and add it again, it gives another error:
> {code}
> [standalone@embedded /] /subsystem=transactions/log-store=log-store:remove
> {
> "outcome" => "success",
> "result" => undefined
> }
> [standalone@embedded /] /subsystem=transactions/log-store=log-store:add(type=jdbc)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0212: Duplicate resource [
> (\"subsystem\" => \"transactions\"),
> (\"log-store\" => \"log-store\")
> ]",
> "rolled-back" => true
> }
> {code}
> Despite the change looking like it has taken effect:
> {code}
> [standalone@embedded /] /subsystem=transactions/log-store=log-store:read-resource
> {
> "outcome" => "success",
> "result" => {
> "type" => "jdbc",
> "transactions" => undefined
> }
> }
> {code}
> However, it is not persisted in xml, so restarting the server it says the type is 'default' again
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12099) Cannot change transaction log store type via CLI
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-12099?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka edited comment on WFLY-12099 at 5/24/19 4:50 AM:
------------------------------------------------------------------
Hi [~kabirkhan],
I'm sorry for not getting to this sooner. But with your permission, I'm closing this as not a bug. If you consider that's not correct feel free to reopen and we can discuss more.
The way how to set up the JDBC object store is explained in steps in doc (https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...) so from the technical perspective I would mention that it's need to be used the operation {{/subsystem=transactions:write-attribute(name=use-jdbc-store, value=true)}}. Ensure that the datasource is defined to be with {{jta}} set to {{false}}.
I understand that the usage of the CLI is not intuitive as it does not follow how other subsystems are configured. But that's all that I'm able to say to it. I just do how it was done.
was (Author: ochaloup):
Hi [~kabirkhan],
I'm sorry for not getting to this sooner. But with your permission, I'm closing this as not a bug. If you consider that's not correct feel free to reopen and discuss more it.
The way how to set up the JDBC object store is explained in steps in doc (https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...) so from the technical perspective I would mention that it's need to be used the operation {{/subsystem=transactions:write-attribute(name=use-jdbc-store, value=true)}}. Ensure that the datasource is defined to be with {{jta}} set to {{false}}.
I understand that the usage of the CLI is not intuitive as it does not follow how other subsystems are configured. But that's all that I'm able to say to it. I just do how it was done.
> Cannot change transaction log store type via CLI
> ------------------------------------------------
>
> Key: WFLY-12099
> URL: https://issues.jboss.org/browse/WFLY-12099
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 17.0.0.Alpha1
> Reporter: Kabir Khan
> Assignee: Ondrej Chaloupka
> Priority: Critical
>
> For the OpenShift image work we need to be able to handle configuration of datasources. There is an effort underway to replace the current template marker replacement done in standalone.xml with CLI commands.
> While this works for the datasource subsystem itself, the OpenShift image scripts also touch other subsystems. For example if it is configured to use the Tx subsystem JDBC log store, we need to change the value of the /subsystem=transactions/log-store=log-store's 'type' attribute and to set the values of jdbc-action-store-table-prefix, jdbc-communication-store-table-prefix and jdbc-state-store-table-prefix and jdbc-store-datasource attributes on the subsystem itself.
> The equivalent in the existing xml marker replacement is to inject the following xml into the subsystem (the 'os77c791d37250' is calculated by the OpenShift launch scripts):
> {code}
> <jdbc-store datasource-jndi-name="java:jboss/datasources/testtx_postgresqlObjectStore">
> <action table-prefix="os77c791d37250"/>
> <communication table-prefix="os77c791d37250"/>
> <state table-prefix="os77c791d37250"/>
> </jdbc-store>
> {code}
> However, this is not possible to do via CLI. Starting the server without a jdbc-store, you end up with the following
> {code}
> [standalone@localhost:9990 /] /subsystem=transactions/log-store=log-store:read-resource
> {
> "outcome" => "success",
> "result" => {
> "type" => "default",
> "transactions" => undefined
> }
> }
> {code}
> If you try to write the 'type' attribute it gives the error than it is read-only
> {code}
> [standalone@embedded /] /subsystem=transactions/log-store=log-store:write-attribute(name=type, value=jdbc)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0048: Attribute type is not writable",
> "rolled-back" => true
> }
> {code}
> If you try to delete the resource and add it again, it gives another error:
> {code}
> [standalone@embedded /] /subsystem=transactions/log-store=log-store:remove
> {
> "outcome" => "success",
> "result" => undefined
> }
> [standalone@embedded /] /subsystem=transactions/log-store=log-store:add(type=jdbc)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0212: Duplicate resource [
> (\"subsystem\" => \"transactions\"),
> (\"log-store\" => \"log-store\")
> ]",
> "rolled-back" => true
> }
> {code}
> Despite the change looking like it has taken effect:
> {code}
> [standalone@embedded /] /subsystem=transactions/log-store=log-store:read-resource
> {
> "outcome" => "success",
> "result" => {
> "type" => "jdbc",
> "transactions" => undefined
> }
> }
> {code}
> However, it is not persisted in xml, so restarting the server it says the type is 'default' again
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12099) Cannot change transaction log store type via CLI
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-12099?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka edited comment on WFLY-12099 at 5/24/19 4:50 AM:
------------------------------------------------------------------
Hi [~kabirkhan],
I'm sorry for not getting to this sooner. But with your permission, I'm closing this as not a bug. If you consider that's not correct feel free to reopen and we can discuss more.
The way how to set up the JDBC object store is explained in steps in doc (https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...) so from the technical perspective I would mention that it's needed to be used the operation {{/subsystem=transactions:write-attribute(name=use-jdbc-store, value=true)}}. Ensure that the datasource is defined to be with {{jta}} set to {{false}}.
I understand that the usage of the CLI is not intuitive as it does not follow how other subsystems are configured. But that's all that I'm able to say to it. I just do how it was done.
was (Author: ochaloup):
Hi [~kabirkhan],
I'm sorry for not getting to this sooner. But with your permission, I'm closing this as not a bug. If you consider that's not correct feel free to reopen and we can discuss more.
The way how to set up the JDBC object store is explained in steps in doc (https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...) so from the technical perspective I would mention that it's need to be used the operation {{/subsystem=transactions:write-attribute(name=use-jdbc-store, value=true)}}. Ensure that the datasource is defined to be with {{jta}} set to {{false}}.
I understand that the usage of the CLI is not intuitive as it does not follow how other subsystems are configured. But that's all that I'm able to say to it. I just do how it was done.
> Cannot change transaction log store type via CLI
> ------------------------------------------------
>
> Key: WFLY-12099
> URL: https://issues.jboss.org/browse/WFLY-12099
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 17.0.0.Alpha1
> Reporter: Kabir Khan
> Assignee: Ondrej Chaloupka
> Priority: Critical
>
> For the OpenShift image work we need to be able to handle configuration of datasources. There is an effort underway to replace the current template marker replacement done in standalone.xml with CLI commands.
> While this works for the datasource subsystem itself, the OpenShift image scripts also touch other subsystems. For example if it is configured to use the Tx subsystem JDBC log store, we need to change the value of the /subsystem=transactions/log-store=log-store's 'type' attribute and to set the values of jdbc-action-store-table-prefix, jdbc-communication-store-table-prefix and jdbc-state-store-table-prefix and jdbc-store-datasource attributes on the subsystem itself.
> The equivalent in the existing xml marker replacement is to inject the following xml into the subsystem (the 'os77c791d37250' is calculated by the OpenShift launch scripts):
> {code}
> <jdbc-store datasource-jndi-name="java:jboss/datasources/testtx_postgresqlObjectStore">
> <action table-prefix="os77c791d37250"/>
> <communication table-prefix="os77c791d37250"/>
> <state table-prefix="os77c791d37250"/>
> </jdbc-store>
> {code}
> However, this is not possible to do via CLI. Starting the server without a jdbc-store, you end up with the following
> {code}
> [standalone@localhost:9990 /] /subsystem=transactions/log-store=log-store:read-resource
> {
> "outcome" => "success",
> "result" => {
> "type" => "default",
> "transactions" => undefined
> }
> }
> {code}
> If you try to write the 'type' attribute it gives the error than it is read-only
> {code}
> [standalone@embedded /] /subsystem=transactions/log-store=log-store:write-attribute(name=type, value=jdbc)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0048: Attribute type is not writable",
> "rolled-back" => true
> }
> {code}
> If you try to delete the resource and add it again, it gives another error:
> {code}
> [standalone@embedded /] /subsystem=transactions/log-store=log-store:remove
> {
> "outcome" => "success",
> "result" => undefined
> }
> [standalone@embedded /] /subsystem=transactions/log-store=log-store:add(type=jdbc)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0212: Duplicate resource [
> (\"subsystem\" => \"transactions\"),
> (\"log-store\" => \"log-store\")
> ]",
> "rolled-back" => true
> }
> {code}
> Despite the change looking like it has taken effect:
> {code}
> [standalone@embedded /] /subsystem=transactions/log-store=log-store:read-resource
> {
> "outcome" => "success",
> "result" => {
> "type" => "jdbc",
> "transactions" => undefined
> }
> }
> {code}
> However, it is not persisted in xml, so restarting the server it says the type is 'default' again
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12099) Cannot change transaction log store type via CLI
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-12099?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka resolved WFLY-12099.
-------------------------------------
Resolution: Rejected
Hi [~kabirkhan],
I'm sorry for not getting to this sooner. But with your permission, I'm closing this as not a bug. If you consider that's not correct feel free to reopen and discuss more it.
The way how to set up the JDBC object store is explained in steps in doc (https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...) so from the technical perspective I would mention that it's need to be used the operation {{/subsystem=transactions:write-attribute(name=use-jdbc-store, value=true)}}. Ensure that the datasource is defined to be with {{jta}} set to {{false}}.
I understand that the usage of the CLI is not intuitive as it does not follow how other subsystems are configured. But that's all that I'm able to say to it. I just do how it was done.
> Cannot change transaction log store type via CLI
> ------------------------------------------------
>
> Key: WFLY-12099
> URL: https://issues.jboss.org/browse/WFLY-12099
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 17.0.0.Alpha1
> Reporter: Kabir Khan
> Assignee: Ondrej Chaloupka
> Priority: Critical
>
> For the OpenShift image work we need to be able to handle configuration of datasources. There is an effort underway to replace the current template marker replacement done in standalone.xml with CLI commands.
> While this works for the datasource subsystem itself, the OpenShift image scripts also touch other subsystems. For example if it is configured to use the Tx subsystem JDBC log store, we need to change the value of the /subsystem=transactions/log-store=log-store's 'type' attribute and to set the values of jdbc-action-store-table-prefix, jdbc-communication-store-table-prefix and jdbc-state-store-table-prefix and jdbc-store-datasource attributes on the subsystem itself.
> The equivalent in the existing xml marker replacement is to inject the following xml into the subsystem (the 'os77c791d37250' is calculated by the OpenShift launch scripts):
> {code}
> <jdbc-store datasource-jndi-name="java:jboss/datasources/testtx_postgresqlObjectStore">
> <action table-prefix="os77c791d37250"/>
> <communication table-prefix="os77c791d37250"/>
> <state table-prefix="os77c791d37250"/>
> </jdbc-store>
> {code}
> However, this is not possible to do via CLI. Starting the server without a jdbc-store, you end up with the following
> {code}
> [standalone@localhost:9990 /] /subsystem=transactions/log-store=log-store:read-resource
> {
> "outcome" => "success",
> "result" => {
> "type" => "default",
> "transactions" => undefined
> }
> }
> {code}
> If you try to write the 'type' attribute it gives the error than it is read-only
> {code}
> [standalone@embedded /] /subsystem=transactions/log-store=log-store:write-attribute(name=type, value=jdbc)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0048: Attribute type is not writable",
> "rolled-back" => true
> }
> {code}
> If you try to delete the resource and add it again, it gives another error:
> {code}
> [standalone@embedded /] /subsystem=transactions/log-store=log-store:remove
> {
> "outcome" => "success",
> "result" => undefined
> }
> [standalone@embedded /] /subsystem=transactions/log-store=log-store:add(type=jdbc)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0212: Duplicate resource [
> (\"subsystem\" => \"transactions\"),
> (\"log-store\" => \"log-store\")
> ]",
> "rolled-back" => true
> }
> {code}
> Despite the change looking like it has taken effect:
> {code}
> [standalone@embedded /] /subsystem=transactions/log-store=log-store:read-resource
> {
> "outcome" => "success",
> "result" => {
> "type" => "jdbc",
> "transactions" => undefined
> }
> }
> {code}
> However, it is not persisted in xml, so restarting the server it says the type is 'default' again
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12031) Memory leak in wildfly transaction client
by Joachim Petrich (Jira)
[ https://issues.jboss.org/browse/WFLY-12031?page=com.atlassian.jira.plugin... ]
Joachim Petrich commented on WFLY-12031:
----------------------------------------
Your proposed change is working.
> Memory leak in wildfly transaction client
> -----------------------------------------
>
> Key: WFLY-12031
> URL: https://issues.jboss.org/browse/WFLY-12031
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 15.0.1.Final
> Environment: wildfly-transaction-client-1.1.3.Final
> wildfly.15.0.1.Final
> Windows 10
> Reporter: Joachim Petrich
> Assignee: Cheng Fang
> Priority: Critical
>
> After a volume run of our system we recognized millions of entries in the openFilePaths Object of class FileSystemXAResourceRegistry. When enabling traces for org.wildfly.transaction it seems that for adding an entry a xid string is used
> {code:java}
> XAResourceRegistryFile(Xid xid) throws SystemException {
> xaRecoveryPath.toFile().mkdir(); // create dir if non existent
> final String xidString = SimpleXid.of(xid).toHexString('_');
> this.filePath = xaRecoveryPath.resolve(xidString);
> openFilePaths.add(*xidString*);
> {code}
> and for removing the entire file path:
> {code:java}
> protected void removeResource(XAResource resource) throws XAException {
> if (resources.remove(resource)) {
> if (resources.isEmpty()) {
> // delete file
> try {
> if (fileChannel != null) {
> fileChannel.close();
> }
> Files.delete(filePath);
> // deleting using the filepath as key caused a memory leak,
> // if xid string have been added, therefore build the xid string for removing
> openFilePaths.remove(*filePath.toString()*);
> {code}
> We didn't find any code where this xid are cleaned up.
> As workaround we additionally extract the xid String from the file path and remove the corresponding entry.
> {code:java}
> String xidString = filePath.toString().substring(filePath.toString().indexOf(
> xaRecoveryPath.toString()) + xaRecoveryPath.toString().length() + 1);
> openFilePaths.remove(xidString);
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12031) Memory leak in wildfly transaction client
by Joachim Petrich (Jira)
[ https://issues.jboss.org/browse/WFLY-12031?page=com.atlassian.jira.plugin... ]
Joachim Petrich updated WFLY-12031:
-----------------------------------
Environment:
wildfly-transaction-client-1.1.3.Final
wildfly.15.0.1.Final
Windows 10
was:
wildfly-transaction-client-1.1.3.Final
wildfly.15.0.1.Final
Window 10
> Memory leak in wildfly transaction client
> -----------------------------------------
>
> Key: WFLY-12031
> URL: https://issues.jboss.org/browse/WFLY-12031
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 15.0.1.Final
> Environment: wildfly-transaction-client-1.1.3.Final
> wildfly.15.0.1.Final
> Windows 10
> Reporter: Joachim Petrich
> Assignee: Cheng Fang
> Priority: Critical
>
> After a volume run of our system we recognized millions of entries in the openFilePaths Object of class FileSystemXAResourceRegistry. When enabling traces for org.wildfly.transaction it seems that for adding an entry a xid string is used
> {code:java}
> XAResourceRegistryFile(Xid xid) throws SystemException {
> xaRecoveryPath.toFile().mkdir(); // create dir if non existent
> final String xidString = SimpleXid.of(xid).toHexString('_');
> this.filePath = xaRecoveryPath.resolve(xidString);
> openFilePaths.add(*xidString*);
> {code}
> and for removing the entire file path:
> {code:java}
> protected void removeResource(XAResource resource) throws XAException {
> if (resources.remove(resource)) {
> if (resources.isEmpty()) {
> // delete file
> try {
> if (fileChannel != null) {
> fileChannel.close();
> }
> Files.delete(filePath);
> // deleting using the filepath as key caused a memory leak,
> // if xid string have been added, therefore build the xid string for removing
> openFilePaths.remove(*filePath.toString()*);
> {code}
> We didn't find any code where this xid are cleaned up.
> As workaround we additionally extract the xid String from the file path and remove the corresponding entry.
> {code:java}
> String xidString = filePath.toString().substring(filePath.toString().indexOf(
> xaRecoveryPath.toString()) + xaRecoveryPath.toString().length() + 1);
> openFilePaths.remove(xidString);
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (DROOLS-3997) [DMN Designer] Included Model Name marshalling issues depending on imported model name
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3997?page=com.atlassian.jira.plugi... ]
Jozef Marko commented on DROOLS-3997:
-------------------------------------
[~dadossan] thank you for investigation, you were right, I reported as a separate issue here RHDM-969.
> [DMN Designer] Included Model Name marshalling issues depending on imported model name
> --------------------------------------------------------------------------------------
>
> Key: DROOLS-3997
> URL: https://issues.jboss.org/browse/DROOLS-3997
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.22.0.Final
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
> Attachments: Screenshot from 2019-05-10 08-20-54.png, Screenshot from 2019-05-10 08-28-42.png, connect-imported-error.log, connect-imported-node.webm, routes-v2.log, routes-v2.zip, routes.zip
>
>
> There is issue in marshalling, if the included model name contains *whitespace* character. In such case xml editor is opened instead of the dmn editor. See the attached picture and steps to reproduce for more details.
> Issue spotted during review of DROOLS-3720 and DROOLS-3721. However it is probably not related.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months