[JBoss JIRA] (WFLY-12099) Cannot change transaction log store type via CLI
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-12099?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-12099:
---------------------------------
Labels: closed (was: )
> 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
> Labels: closed
>
> 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)
6 years, 10 months
[JBoss JIRA] (WFLY-12099) Cannot change transaction log store type via CLI
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-12099?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-12099:
---------------------------------
Labels: (was: closed)
> 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)
6 years, 10 months
[JBoss JIRA] (WFLY-12099) Cannot change transaction log store type via CLI
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-12099?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-12099:
---------------------------------
Labels: closed (was: )
> 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)
6 years, 10 months
[JBoss JIRA] (WFLY-10134) ee8.preview.mode property is racy
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-10134?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-10134:
---------------------------------
Labels: (was: known-issues)
> ee8.preview.mode property is racy
> ---------------------------------
>
> Key: WFLY-10134
> URL: https://issues.jboss.org/browse/WFLY-10134
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Reporter: David Lloyd
> Assignee: Stuart Douglas
> Priority: Critical
>
> The {{ee8-temp}} tests set the {{ee8.preview.mode}} property in the server management model, relying on system properties to get parsed and set before extensions which use Java EE 8 APIs are loaded. This assumption appears to be invalid.
> System properties are installed by the boot controller thread, and extensions are loaded in server service threads. In testing with the latest jboss-modules, I've observed cases where the controller thread does not add system properties until after some extension loading has happened in the server service threads. I haven't untangled why this happens only with the most recent jboss-modules in play, but the race exists regardless.
> Setting the {{ee8.preview.mode}} in {{arquillian.xml}} appears to work around the issue.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-10134) ee8.preview.mode property is racy
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-10134?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-10134:
---------------------------------
Labels: known-issues (was: )
> ee8.preview.mode property is racy
> ---------------------------------
>
> Key: WFLY-10134
> URL: https://issues.jboss.org/browse/WFLY-10134
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Reporter: David Lloyd
> Assignee: Stuart Douglas
> Priority: Critical
> Labels: known-issues
>
> The {{ee8-temp}} tests set the {{ee8.preview.mode}} property in the server management model, relying on system properties to get parsed and set before extensions which use Java EE 8 APIs are loaded. This assumption appears to be invalid.
> System properties are installed by the boot controller thread, and extensions are loaded in server service threads. In testing with the latest jboss-modules, I've observed cases where the controller thread does not add system properties until after some extension loading has happened in the server service threads. I haven't untangled why this happens only with the most recent jboss-modules in play, but the race exists regardless.
> Setting the {{ee8.preview.mode}} in {{arquillian.xml}} appears to work around the issue.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-10817) Incorrect data check when clearing body of large compressed message after failover
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-10817?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-10817:
---------------------------------
Fix Version/s: 14.0.0.Final
> Incorrect data check when clearing body of large compressed message after failover
> ----------------------------------------------------------------------------------
>
> Key: WFLY-10817
> URL: https://issues.jboss.org/browse/WFLY-10817
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 13.0.0.Final
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Critical
> Fix For: 14.0.0.Final
>
>
> *Scenario*
> * There are two WildFly (Artemis) servers in dedicated shared store HA topology
> * Connection factory is configured to compress large messages
> * Live server is killed
> * Clients do failover to backup
> After the clients do failover to backup, I can see following exceptions in the log when a receiver tries to clear body of large message. The test fails because of lost messages.
> I can see this issue with Artemis 1.5.5.jbossorg-012.
> I am not able to reproduce it locally but I hit it on Jenkins every time.
> {code}
> javax.jms.JMSException: AMQ119029: Error writing body of message
> at org.apache.activemq.artemis.jms.client.ActiveMQBytesMessage.clearBody(ActiveMQBytesMessage.java:337)
> at org.jboss.qa.hornetq.apps.clients.Client.cleanMessage(Client.java:144)
> at org.jboss.qa.hornetq.apps.clients.Receiver11.receiveMessage(Receiver11.java:153)
> at org.jboss.qa.hornetq.apps.clients.ReceiverTransAck.run(ReceiverTransAck.java:89)
> Caused by: java.lang.RuntimeException: AMQ119029: Error writing body of message
> at org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.getBodyBuffer(ClientLargeMessageImpl.java:93)
> at org.apache.activemq.artemis.jms.client.ActiveMQBytesMessage.getBuffer(ActiveMQBytesMessage.java:363)
> at org.apache.activemq.artemis.jms.client.ActiveMQBytesMessage.clearBody(ActiveMQBytesMessage.java:335)
> ... 3 more
> Caused by: ActiveMQLargeMessageException[errorType=LARGE_MESSAGE_ERROR_BODY message=AMQ119029: Error writing body of message]
> at org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.sendPacketToOutput(LargeMessageControllerImpl.java:1077)
> at org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.setOutputStream(LargeMessageControllerImpl.java:258)
> at org.apache.activemq.artemis.core.client.impl.CompressedLargeMessageControllerImpl.setOutputStream(CompressedLargeMessageControllerImpl.java:75)
> at org.apache.activemq.artemis.core.client.impl.CompressedLargeMessageControllerImpl.saveBuffer(CompressedLargeMessageControllerImpl.java:80)
> at org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.checkBuffer(ClientLargeMessageImpl.java:159)
> at org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.getBodyBuffer(ClientLargeMessageImpl.java:91)
> ... 5 more
> Caused by: java.io.IOException: incorrect data check
> at org.apache.activemq.artemis.utils.InflaterWriter.close(InflaterWriter.java:81)
> at org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.sendPacketToOutput(LargeMessageControllerImpl.java:1074)
> ... 10 more
> Caused by: java.util.zip.DataFormatException: incorrect data check
> at java.util.zip.Inflater.inflateBytes(Native Method)
> at java.util.zip.Inflater.inflate(Inflater.java:259)
> at java.util.zip.Inflater.inflate(Inflater.java:280)
> at org.apache.activemq.artemis.utils.InflaterWriter.close(InflaterWriter.java:77)
> ... 11 more
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (DROOLS-4205) DMN: UI enhancements for Data Type editor
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-4205?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton commented on DROOLS-4205:
-------------------------------------------
[~tirelli] [~aglass] * Please note: Related keyboard navigation and shortcut issues are being tracked and handled through these efforts: https://issues.jboss.org/browse/DROOLS-4148 & https://issues.jboss.org/browse/AF-2081.
> DMN: UI enhancements for Data Type editor
> -----------------------------------------
>
> Key: DROOLS-4205
> URL: https://issues.jboss.org/browse/DROOLS-4205
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam, drools-tools
>
> *User Story*
> As a practitioner I want to be able to:
> * select an existing data type
> * create a simple or structured data type
> * create a “compound” (or complex) data type, easily.
> *
expand/collapse views of compound data types, so that I can___
> *
navigate between levels in a compound data type, so that I can___
> * edit an existing data type
> * remove an existing data type
>
…so that I can use the data type when creating a decision related asset.
> *Requested UI enhancements, based on user feedback from 7.4 implementation (keyboard shortcuts are covered in a separate Epic)*
> NESTING ISSUES ARE HIGH PRIORITY
> - Fix Dropdown menu labeling (Structure)
> - Weird tooltip on Structured row.
> - It wasn’t clear wasn’t what was nested, and looking for drag-n-drop to nest and reorder.
> - Finding “Structure” in the dropdown - was separate, blue and at the bottom. Terminology.
> - Nested data types, - all 3 used the field already open, but confusion about adding additional rows. Kebab didn’t work so well. Terminology for kebab menu.
> - Due to the icon at the top level and no icons at the second level, the indenting of second level items is not very clear for users. Make sure the nesting is very clear at a glance.
> - Better way to add a new field that is always visible to the user and clear to use without having to go into a kabob menu
> RELATED SAVE INTERACTIONS (Save, Delete, Remove)
> - Inline editing of the content in the rows would make the experience nicer than having a whole row edit model
> - - It's not obvious that you have to select the "check mark" to commit the change.
> - After adding a new data type field, undo becomes available but instead of removing the field, it resets the field name and type to the defaults. Redo then becomes available but doesn't appear to do anything when clicked.
> OTHER:
> - “Constraint” link was confusing, but location was good.
> - In the dialog, “Add” wasn’t found too well. (Bug adding a null constraint.)
> - Questions around Save - should it not require Save at the row level.
> - It feels unnatural to have to click the "Constraints" to open the Constraints modal.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (DROOLS-4205) DMN: UI enhancements for Data Type editor
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-4205?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton commented on DROOLS-4205:
-------------------------------------------
[~tirelli] [~karreiro] I have created revised designs to address user feedback, and posted mockups to this document: https://docs.google.com/presentation/d/10GZUd6oLaQohK27iJ1S6eF-WfvF8whXH5....
If these proposed solutions look acceptable/viable, I will create a functional prototype to articulate the fine grain interaction details. The prototype will also be used for a follow-up usability study.
> DMN: UI enhancements for Data Type editor
> -----------------------------------------
>
> Key: DROOLS-4205
> URL: https://issues.jboss.org/browse/DROOLS-4205
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UX, UXTeam, drools-tools
>
> *User Story*
> As a practitioner I want to be able to:
> * select an existing data type
> * create a simple or structured data type
> * create a “compound” (or complex) data type, easily.
> *
expand/collapse views of compound data types, so that I can___
> *
navigate between levels in a compound data type, so that I can___
> * edit an existing data type
> * remove an existing data type
>
…so that I can use the data type when creating a decision related asset.
> *Requested UI enhancements, based on user feedback from 7.4 implementation (keyboard shortcuts are covered in a separate Epic)*
> NESTING ISSUES ARE HIGH PRIORITY
> - Fix Dropdown menu labeling (Structure)
> - Weird tooltip on Structured row.
> - It wasn’t clear wasn’t what was nested, and looking for drag-n-drop to nest and reorder.
> - Finding “Structure” in the dropdown - was separate, blue and at the bottom. Terminology.
> - Nested data types, - all 3 used the field already open, but confusion about adding additional rows. Kebab didn’t work so well. Terminology for kebab menu.
> - Due to the icon at the top level and no icons at the second level, the indenting of second level items is not very clear for users. Make sure the nesting is very clear at a glance.
> - Better way to add a new field that is always visible to the user and clear to use without having to go into a kabob menu
> RELATED SAVE INTERACTIONS (Save, Delete, Remove)
> - Inline editing of the content in the rows would make the experience nicer than having a whole row edit model
> - - It's not obvious that you have to select the "check mark" to commit the change.
> - After adding a new data type field, undo becomes available but instead of removing the field, it resets the field name and type to the defaults. Redo then becomes available but doesn't appear to do anything when clicked.
> OTHER:
> - “Constraint” link was confusing, but location was good.
> - In the dialog, “Add” wasn’t found too well. (Bug adding a null constraint.)
> - Questions around Save - should it not require Save at the row level.
> - It feels unnatural to have to click the "Constraints" to open the Constraints modal.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
