[JBoss JIRA] (WFLY-11811) Default transaction timeout coud be wrongly configured because of the TM initiation race condition
by Ondra Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-11811?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka updated WFLY-11811:
-----------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/12140
> Default transaction timeout coud be wrongly configured because of the TM initiation race condition
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-11811
> URL: https://issues.jboss.org/browse/WFLY-11811
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 16.0.0.Final
> Reporter: Ondra Chaloupka
> Assignee: Ondra Chaloupka
> Priority: Major
>
> Transaction default timeout could be wrongly set up because of race condition in configuration of the {{CoordinatorEnvironmentBean}} and the {{TxControl}} class which is used on transaction begin and loads data from the coordinator bean to static variable.
> The default transaction timeout defined by Narayana is 60 seconds. It's coded in source at https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes...
> The {{CoordinatorEnvironmentBean}} is instantiated with the default value or with value taken from system property or xml descriptor (https://jbossts.blogspot.com/2018/01/narayana-periodic-recovery-of-xa.htm...).
> When new transaction is started it does not use directly the {{CoordinatorEnvironmentBean#getDefaultTimeout()}} but the {{TxControl#getDefaultTimeout()}} (https://github.com/jbosstm/narayana/blob/5.9.3.Final/ArjunaCore/arjuna/cl...).
> From the [~stephen.fikes] testing with Byteman[1] when there is used the environment property {{-Dcom.arjuna.ats.arjuna.coordinator.defaultTimeout=301}} (should not be used for WFLY) and WFLY model configuration {{<coordinator-environment default-timeout="302"/>}} we can see the {{CoordinatorEnvironmentBean.setDefaultTimeout}} is called twice. First time it's time of the bean initialization and the value of 301 is taken ({{BeanPopulator}} instantiates the bean and reset the default value of {{60}} to {{301}}. Next the ArjunaTransactionManagerService is started and set the value to 302 as model defines https://github.com/wildfly/wildfly/blob/16.0.0.Final/transactions/src/mai....
> Unfortunately, there is no changes for the {{TxControl}} class which is used during transaction startup. If the {{TxControl}} would be initialized before the {{ArjunaTransactionService}} is started then the value defined in the WFLY model would not be considered until a change in the CLI ({{/subsystem=transactions:write-attribute(name=default-timeout, value=100)}}) is done. The cli command causes the {{TxControl}} is reset - https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java...
> We should ensure the {{TxControl._defaultTimeout}} value is configured during {{ArjunaTransactionManagerService}} start up as well.
> [1]
> {code}
> INFO [stdout] (MSC service thread 1-2) [BMAN]
> CoordinatorEnvironmentBean.setDefaultTimeout(301)
> com.arjuna.ats.arjuna.common.CoordinatorEnvironmentBean.setDefaultTimeout(CoordinatorEnvironmentBean.java:-1)
> sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-2)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:498)
> com.arjuna.common.internal.util.propertyservice.BeanPopulator.handleSimpleProperty(BeanPopulator.java:312)
> com.arjuna.common.internal.util.propertyservice.BeanPopulator.configureFromProperties(BeanPopulator.java:172)
> com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance(BeanPopulator.java:87)
> com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance(BeanPopulator.java:53)
> com.arjuna.ats.arjuna.common.arjPropertyManager.getCoordinatorEnvironmentBean(arjPropertyManager.java:51)
> com.arjuna.ats.arjuna.coordinator.BasicAction.<clinit>(BasicAction.java:3754)
> com.arjuna.ats.internal.jta.recovery.arjunacore.CommitMarkableResourceRecordRecoveryModule.<clinit>(CommitMarkableResourceRecordRecoveryModule.java:79)
> java.lang.Class.forName0(Class.java:-2)
> java.lang.Class.forName(Class.java:264)
> com.arjuna.common.internal.util.ClassloadingUtility.loadClass(ClassloadingUtility.java:57)
> com.arjuna.common.internal.util.ClassloadingUtility.loadClass(ClassloadingUtility.java:85)
> com.arjuna.common.internal.util.ClassloadingUtility.loadAndInstantiateClass(ClassloadingUtility.java:117)
> com.arjuna.common.internal.util.ClassloadingUtility.loadAndInstantiateClassesWithInit(ClassloadingUtility.java:192)
> com.arjuna.ats.arjuna.common.RecoveryEnvironmentBean.getRecoveryModules(RecoveryEnvironmentBean.java:465)
> com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.loadModules(PeriodicRecovery.java:883)
> com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.<init>(PeriodicRecovery.java:121)
> com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:107)
> com.arjuna.ats.arjuna.recovery.RecoveryManager.<init>(RecoveryManager.java:477)
> com.arjuna.ats.arjuna.recovery.RecoveryManager.manager(RecoveryManager.java:132)
> com.arjuna.ats.arjuna.recovery.RecoveryManager.manager(RecoveryManager.java:112)
> com.arjuna.ats.jbossatx.jta.RecoveryManagerService.create(RecoveryManagerService.java:54)
> org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:126)
> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> java.lang.Thread.run(Thread.java:748)
> INFO [stdout] (MSC service thread 1-2) [BMAN]
> CoordinatorEnvironmentBean.setDefaultTimeout(302)
> com.arjuna.ats.arjuna.common.CoordinatorEnvironmentBean.setDefaultTimeout(CoordinatorEnvironmentBean.java:-1)
> org.jboss.as.txn.service.ArjunaTransactionManagerService.start(ArjunaTransactionManagerService.java:88)
> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (WFLY-11812) Error trying to build the Quickstart README.html Files
by Wolfgang Mayer (Jira)
[ https://issues.jboss.org/browse/WFLY-11812?page=com.atlassian.jira.plugin... ]
Wolfgang Mayer updated WFLY-11812:
----------------------------------
Description:
When executing the command
mvn clean generate-resources -Pdocs
Quickstart: app-client - ear failes:
INFO] Quickstart: messaging-clustering ................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:07 min
[INFO] Finished at: 2019-03-02T10:59:42+01:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project app-client-ear: Could not resolve dependencies for project org.wildfly.quickstarts:app-client-ear:ear:16.0.0.Final: The following artifacts could not be resolved: org.wildfly.quickstarts:app-client-client-simple:jar:16.0.0.Final, org.wildfly.quickstarts:app-client-ejb:jar:16.0.0.Final: Failure to find org.wildfly.quickstarts:app-client-client-simple:jar:16.0.0.Final in https://maven.repository.redhat.com/ga/ was cached in the local repository, resolution will not be reattempted until the update interval of jboss-enterprise-maven-repository has elapsed or updates are forced -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
mvn -v
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T20:41:47+02:00)
Maven home: /apps/apache-maven-3.6.0
Java version: 11.0.2, vendor: Oracle Corporation, runtime: /usr/java/jdk-11.0.2
Default locale: de_DE, platform encoding: UTF-8
OS name: "linux", version: "4.12.14-lp150.12.48-default", arch: "amd64", family: "unix"
Either maven build or docs should be fixed.
Recommended workaround: "please use "mvn clean install -Pdocs".
(see also: https://developer.jboss.org/message/988269?et=watches.email.thread#988269)
> Error trying to build the Quickstart README.html Files
> ------------------------------------------------------
>
> Key: WFLY-11812
> URL: https://issues.jboss.org/browse/WFLY-11812
> Project: WildFly
> Issue Type: Bug
> Components: Documentation
> Affects Versions: 16.0.0.Final
> Reporter: Wolfgang Mayer
> Priority: Minor
>
> When executing the command
>
> mvn clean generate-resources -Pdocs
>
> Quickstart: app-client - ear failes:
>
> INFO] Quickstart: messaging-clustering ................... SKIPPED
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 01:07 min
> [INFO] Finished at: 2019-03-02T10:59:42+01:00
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal on project app-client-ear: Could not resolve dependencies for project org.wildfly.quickstarts:app-client-ear:ear:16.0.0.Final: The following artifacts could not be resolved: org.wildfly.quickstarts:app-client-client-simple:jar:16.0.0.Final, org.wildfly.quickstarts:app-client-ejb:jar:16.0.0.Final: Failure to find org.wildfly.quickstarts:app-client-client-simple:jar:16.0.0.Final in https://maven.repository.redhat.com/ga/ was cached in the local repository, resolution will not be reattempted until the update interval of jboss-enterprise-maven-repository has elapsed or updates are forced -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>
> mvn -v
> Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T20:41:47+02:00)
> Maven home: /apps/apache-maven-3.6.0
> Java version: 11.0.2, vendor: Oracle Corporation, runtime: /usr/java/jdk-11.0.2
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "linux", version: "4.12.14-lp150.12.48-default", arch: "amd64", family: "unix"
> Either maven build or docs should be fixed.
> Recommended workaround: "please use "mvn clean install -Pdocs".
> (see also: https://developer.jboss.org/message/988269?et=watches.email.thread#988269)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (DROOLS-3077) Enhance data type restrictions UX - Decision Table/properties
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3077?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-3077:
----------------------------------------
[~uxdlc] LGTM.
[~tirelli] Could you please confirm/clarify.
On https://redhat.invisionapp.com/share/DEQTMGIXU3Y#/screens/350182304 (where Age is the selected Data Type, with a Data Type constraint defined) it is clear that the _additional constraint_ will be on the {{InputClause}}'s {{UnaryTest}. However on https://redhat.invisionapp.com/share/DEQTMGIXU3Y#/screens/350182306 (where the selected Data Type has no Data Type constraint defined) should the _additional constraint_ be added to the Data Type or the {{InputClause}}'s {{UnaryTest}} - I'd assume, for consistency, it'd be on the {{InputClause}}'s {{UnaryTest}} but want to be sure!
> Enhance data type restrictions UX - Decision Table/properties
> -------------------------------------------------------------
>
> Key: DROOLS-3077
> URL: https://issues.jboss.org/browse/DROOLS-3077
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Priority: Major
> Labels: UX, UXTeam, drools-tools
> Attachments: DataType selection ('Properties Panel' and 'in-grid').png, Screen Shot 2018-08-10 at 10.23.36 AM.png, Screen Shot 2018-08-24 at 8.38.37 AM.png, Screen Shot 2018-09-28 at 2.44.59 PM.png, date-time.png, date.png, enumration-widget.png, pop-overc.png, pop-overcSpecs.png, read-mode.png, select.png, time.png
>
>
> *Background*
> Persona: Business analyst or Rules practitioner
> Use Cases:
> * From the DMN canvas view - as a user I want to define data type restrictions (one-off instances) from a decision table .
> * From the Data Types dialog - as a user I want the ability to define constraints for the following types: https://docs.google.com/spreadsheets/d/1HLYwi5JrCEU6IxWRge7RCKANLiHCL0d2E...
> Functional considerations/ pre conditions:
> * Consider interaction in light of Property panel and consistency.
> * Underscore the notion of one-off constraints.
> Verification conditions:
> * Scrum team and PO review.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (DROOLS-3731) DMN UX - More info overlaid on models.
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3731?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-3731:
----------------------------------------
[~uxdlc] Yes, that is correct (we'd probably look at doing it _dynamically_ within the editor rather than overlaying a _static_ SVG).
That however is an implementation consideration and should have no real relevance to UX's designs :-)
> DMN UX - More info overlaid on models.
> --------------------------------------
>
> Key: DROOLS-3731
> URL: https://issues.jboss.org/browse/DROOLS-3731
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Priority: Major
> Labels: UX, UXTeam
> Attachments: download (1).png, download.png
>
>
> As a practitioner, there are situations where I need to show additional information about a model... for instance: test coverage report: I need to draw a model and color code the nodes to show which nodes were executed by tests, or which rows on a DT were a match. Or when I execute a single test, what was the actual value of a given node or expression.
> Note: Maybe in read-only mode with an "overlay" on top of the model the additional metadata information. See process instance diagram design examples.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months
[JBoss JIRA] (WFLY-11806) socket-binding/jgroups-tcp client mappings do not map to jgroups.external_addr properly
by G. Richard Bellamy (Jira)
[ https://issues.jboss.org/browse/WFLY-11806?page=com.atlassian.jira.plugin... ]
G. Richard Bellamy updated WFLY-11806:
--------------------------------------
Workaround Description:
The workaround is to pass in the required external address via the {{jgroups.external_addr}} system property:
{code:title=option 1}
/system-property=jgroups.external_addr:add(value=${env.JGROUPS_NAME:external.host.zzz})
{code}
{code:title=option 2}
standalone.sh -b 0.0.0.0 -bmanagement 0.0.0.0 -bprivate 0.0.0.0 -Djgroups.external_addr=external.host.zzz
{code}
was:
The workaround is to pass in the required external address via the {{jgroups.external_addr}} system property:
{code}
standalone.sh -b 0.0.0.0 -bmanagement 0.0.0.0 -bprivate 0.0.0.0 -Djgroups.external_addr=external.host.zzz
{code}
> socket-binding/jgroups-tcp client mappings do not map to jgroups.external_addr properly
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-11806
> URL: https://issues.jboss.org/browse/WFLY-11806
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 15.0.1.Final
> Reporter: G. Richard Bellamy
> Assignee: Paul Ferraro
> Priority: Major
> Labels: JGroups
>
> socket-binding/jgroups-tcp client mappings do not map to the system property {{jgroups.external_addr}} correctly, and therefore jgroups ALWAYS advertises the address bound to the {{private}} interface.
> When setting the client mappings for the {{jgroups-tcp}} socket binding, wildfly should ensure that the pingdata for various discovery protocols announces the destination address set there, presumably by setting the {{jgroups.external_addr}} value.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 4 months