[JBoss JIRA] (WFLY-6673) JTA does not set transaction timeout for XAResource for propagated transactions
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-6673?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka edited comment on WFLY-6673 at 3/5/18 4:49 AM:
---------------------------------------------------------------
Agree, this was fixed. I checked with the WFLY11 and the reported issue is not present there.
was (Author: ochaloup):
Agree, this was fixed. I've checked with the WFLY11 and the reported issue is not present there.
> JTA does not set transaction timeout for XAResource for propagated transactions
> -------------------------------------------------------------------------------
>
> Key: WFLY-6673
> URL: https://issues.jboss.org/browse/WFLY-6673
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Reporter: Ondra Chaloupka
> Assignee: David Lloyd
>
> I can see a fact that transaction timeout is not provided by subordinate transaction when passed by ejb remote call when JTA transaction are used.
> Even when transaction timeout is defined (it could be seen that timeout is used when xaresources is used on client) the server where transaction is propagated shows xa resources using the default timeou value.
> Client server (caller) - timeout is _6 seconds_
> {code}
> 2016-05-19 11:50:51,461 TRACE [com.arjuna.ats.jta] (default task-18) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:TestXAResource(TestXAResourceCommon(id:483, xid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:57a802d4:573d8c57:11, node_name=1, branch_uid=0:ffff7f000001:57a802d4:573d8c57:20, subordinatenodename=null, eis_name=java:/TestXAResource-483 >, timeout:6, prepareReturn:0)), txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:57a802d4:573d8c57:11, node_name=1, branch_uid=0:ffff7f000001:57a802d4:573d8c57:20, subordinatenodename=null, eis_name=java:/TestXAResource-483 >, heuristic: TwoPhaseOutcome.FINISH_OK, product: Crash Recovery Test/EAP Test, jndiName: java:/TestXAResource-483 com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@7b44816f >, record id=0:ffff7f000001:57a802d4:573d8c57:21
> {code}
> Server (callee) - uses timeout _0 seconds_
> {code}
> 2016-05-19 11:50:39,374 TRACE [com.arjuna.ats.jta] (default task-12) XAResourceRecord.topLevelPrepare for XAResourceRecord < resource:TestXAResource(TestXAResourceCommon(id:502, xid:< formatId=131077, gtrid_length=29, bqual_length=37, tx_uid=0:ffff7f000001:57a802d4:573d8c57:11, node_name=1, branch_uid=0:ffff7f000001:3b603de1:573d8c5f:17, subordinatenodename=2, eis_name=java:/TestXAResource-502 >, timeout:0, prepareReturn:0)), txid:< formatId=131077, gtrid_length=29, bqual_length=37, tx_uid=0:ffff7f000001:57a802d4:573d8c57:11, node_name=1, branch_uid=0:ffff7f000001:3b603de1:573d8c5f:17, subordinatenodename=2, eis_name=java:/TestXAResource-502 >, heuristic: TwoPhaseOutcome.FINISH_OK, product: Crash Recovery Test/EAP Test, jndiName: java:/TestXAResource-502 com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@4f35ed3f >, record id=0:ffff7f000001:3b603de1:573d8c5f:18
> {code}
> Scenario that I'm running is
> # enlist jms xa resource on client
> # call to second server, it means enlist ejb remoting xa resource to transaction
> # enlist test xa on server
> # enlist jms xa resource on server
> # enlist test xa on client
> # starting 2PC
> # prepare jms xa resource on server
> # prepare ejb remoting xa resource on server
> # prepare test xa resource on client
> # transaction timeout is hit
> # if underlying jms resource timeouts then XAResource.prepare call fails with XAER_NOTA and the whole transaction is rolled back
> #
> _(attaching server.log files for EAP 7.0.0/Narayana 5.2.16.Final where jbossts is caller and jbossts2 is callee)_
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-6673) JTA does not set transaction timeout for XAResource for propagated transactions
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-6673?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka commented on WFLY-6673:
---------------------------------------
Agree, this was fixed. I've checked with the WFLY11 and the reported issue is not present there.
> JTA does not set transaction timeout for XAResource for propagated transactions
> -------------------------------------------------------------------------------
>
> Key: WFLY-6673
> URL: https://issues.jboss.org/browse/WFLY-6673
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Reporter: Ondra Chaloupka
> Assignee: David Lloyd
>
> I can see a fact that transaction timeout is not provided by subordinate transaction when passed by ejb remote call when JTA transaction are used.
> Even when transaction timeout is defined (it could be seen that timeout is used when xaresources is used on client) the server where transaction is propagated shows xa resources using the default timeou value.
> Client server (caller) - timeout is _6 seconds_
> {code}
> 2016-05-19 11:50:51,461 TRACE [com.arjuna.ats.jta] (default task-18) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:TestXAResource(TestXAResourceCommon(id:483, xid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:57a802d4:573d8c57:11, node_name=1, branch_uid=0:ffff7f000001:57a802d4:573d8c57:20, subordinatenodename=null, eis_name=java:/TestXAResource-483 >, timeout:6, prepareReturn:0)), txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:57a802d4:573d8c57:11, node_name=1, branch_uid=0:ffff7f000001:57a802d4:573d8c57:20, subordinatenodename=null, eis_name=java:/TestXAResource-483 >, heuristic: TwoPhaseOutcome.FINISH_OK, product: Crash Recovery Test/EAP Test, jndiName: java:/TestXAResource-483 com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@7b44816f >, record id=0:ffff7f000001:57a802d4:573d8c57:21
> {code}
> Server (callee) - uses timeout _0 seconds_
> {code}
> 2016-05-19 11:50:39,374 TRACE [com.arjuna.ats.jta] (default task-12) XAResourceRecord.topLevelPrepare for XAResourceRecord < resource:TestXAResource(TestXAResourceCommon(id:502, xid:< formatId=131077, gtrid_length=29, bqual_length=37, tx_uid=0:ffff7f000001:57a802d4:573d8c57:11, node_name=1, branch_uid=0:ffff7f000001:3b603de1:573d8c5f:17, subordinatenodename=2, eis_name=java:/TestXAResource-502 >, timeout:0, prepareReturn:0)), txid:< formatId=131077, gtrid_length=29, bqual_length=37, tx_uid=0:ffff7f000001:57a802d4:573d8c57:11, node_name=1, branch_uid=0:ffff7f000001:3b603de1:573d8c5f:17, subordinatenodename=2, eis_name=java:/TestXAResource-502 >, heuristic: TwoPhaseOutcome.FINISH_OK, product: Crash Recovery Test/EAP Test, jndiName: java:/TestXAResource-502 com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@4f35ed3f >, record id=0:ffff7f000001:3b603de1:573d8c5f:18
> {code}
> Scenario that I'm running is
> # enlist jms xa resource on client
> # call to second server, it means enlist ejb remoting xa resource to transaction
> # enlist test xa on server
> # enlist jms xa resource on server
> # enlist test xa on client
> # starting 2PC
> # prepare jms xa resource on server
> # prepare ejb remoting xa resource on server
> # prepare test xa resource on client
> # transaction timeout is hit
> # if underlying jms resource timeouts then XAResource.prepare call fails with XAER_NOTA and the whole transaction is rolled back
> #
> _(attaching server.log files for EAP 7.0.0/Narayana 5.2.16.Final where jbossts is caller and jbossts2 is callee)_
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9949) Wildfly 12 : jboss-cli.sh in infinite loop
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFLY-9949?page=com.atlassian.jira.plugin.... ]
Jean-Francois Denise commented on WFLY-9949:
--------------------------------------------
Seems that the lxd container environment is causing this problem. Could you use the logging file attached to this Jira and attach the generated boss-cli.log? Thank-you.
> Wildfly 12 : jboss-cli.sh in infinite loop
> -------------------------------------------
>
> Key: WFLY-9949
> URL: https://issues.jboss.org/browse/WFLY-9949
> Project: WildFly
> Issue Type: Bug
> Components: CLI
> Affects Versions: 12.0.0.Final
> Environment: ubuntu 16.06 lxd container
> java version "1.8.0_161" oracle
> v12 migrated from v11
> Reporter: Gaétan QUENTIN
> Assignee: Jean-Francois Denise
> Labels: regression
> Attachments: jboss-cli-logging.properties, jboss-cli.25300
>
>
> i cannot use anymore the jboss-cli.sh to connect to the contoller since i migrated from v11 to with wildfly 12:
>
> wildfly@java2:/opt/Wildfly$ ls -la
> drwxr-xr-x 1 root root 156 Mar 3 20:36 jboss-server-migration
> drwxr-xr-x 1 root root 454 Mar 4 00:09 overlays
> drwxr-xr-x 1 root root 166 Mar 4 11:43 scripts
> drwxr-xr-x 1 root root 236 Oct 24 05:30 wildfly-11.0.0.Final
> drwxr-xr-x 1 root root 236 Mar 1 07:29 wildfly-12.0.0.Final
> lrwxrwxrwx 1 root root 20 Mar 4 12:49 wildfly-current -> wildfly-12.0.0.Final
>
>
> my wildfly management console is on 172.20.12.192.
> v12 has been migrated from v11 with the jboss-server-migration tool. Applications and app manager works fine and the wildfly instance controller is well binded on the requested ip.
>
>
> with wildfly-current link on -> wildfly-11.0.0.Final:
>
> this works perfectly:
> (cd /opt/Wildfly/wildfly-current/bin && ./jboss-cli.sh -c -u=xx -p=xx --controller=http-remoting://172.20.12.192:9990)
>
>
> with wildfly-current -> wildfly-12.0.0.Final:
> this go in infinite loop until crash :
> (cd /opt/Wildfly/wildfly-current/bin && ./jboss-cli.sh -c -u=xx -p=xx --controller=http-remoting://172.20.12.192:9990)
>
> output:
>
> '[standalone@172.20.12.192:9990' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] '[standalone@172.20.12.192:9990' is not a valid operation name.
> ''[standalone@172.20.12.192:9990'' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] ''[standalone@172.20.12.192:9990'' is not a valid operation name.
> '[standalone@172.20.12.192:9990' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] '''[standalone@172.20.12.192:9990''' is not a valid operation name.
> ''''[standalone@172.20.12.192:9990'''' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] ''[standalone@172.20.12.192:9990'' is not a valid oper is not a valid operation name.
> '[standalone@172.20.12.192:9990' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] '''''[standalone@172.20.12.192:9990''''' is not a valid operation name.
> ''''''[standalone@172.20.12.192:9990'''''' is not a valid operation name.
> attached is a strace capture file (one of thousands) of jboss-cli .
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9949) Wildfly 12 : jboss-cli.sh in infinite loop
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFLY-9949?page=com.atlassian.jira.plugin.... ]
Jean-Francois Denise updated WFLY-9949:
---------------------------------------
Attachment: jboss-cli-logging.properties
> Wildfly 12 : jboss-cli.sh in infinite loop
> -------------------------------------------
>
> Key: WFLY-9949
> URL: https://issues.jboss.org/browse/WFLY-9949
> Project: WildFly
> Issue Type: Bug
> Components: CLI
> Affects Versions: 12.0.0.Final
> Environment: ubuntu 16.06 lxd container
> java version "1.8.0_161" oracle
> v12 migrated from v11
> Reporter: Gaétan QUENTIN
> Assignee: Jean-Francois Denise
> Labels: regression
> Attachments: jboss-cli-logging.properties, jboss-cli.25300
>
>
> i cannot use anymore the jboss-cli.sh to connect to the contoller since i migrated from v11 to with wildfly 12:
>
> wildfly@java2:/opt/Wildfly$ ls -la
> drwxr-xr-x 1 root root 156 Mar 3 20:36 jboss-server-migration
> drwxr-xr-x 1 root root 454 Mar 4 00:09 overlays
> drwxr-xr-x 1 root root 166 Mar 4 11:43 scripts
> drwxr-xr-x 1 root root 236 Oct 24 05:30 wildfly-11.0.0.Final
> drwxr-xr-x 1 root root 236 Mar 1 07:29 wildfly-12.0.0.Final
> lrwxrwxrwx 1 root root 20 Mar 4 12:49 wildfly-current -> wildfly-12.0.0.Final
>
>
> my wildfly management console is on 172.20.12.192.
> v12 has been migrated from v11 with the jboss-server-migration tool. Applications and app manager works fine and the wildfly instance controller is well binded on the requested ip.
>
>
> with wildfly-current link on -> wildfly-11.0.0.Final:
>
> this works perfectly:
> (cd /opt/Wildfly/wildfly-current/bin && ./jboss-cli.sh -c -u=xx -p=xx --controller=http-remoting://172.20.12.192:9990)
>
>
> with wildfly-current -> wildfly-12.0.0.Final:
> this go in infinite loop until crash :
> (cd /opt/Wildfly/wildfly-current/bin && ./jboss-cli.sh -c -u=xx -p=xx --controller=http-remoting://172.20.12.192:9990)
>
> output:
>
> '[standalone@172.20.12.192:9990' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] '[standalone@172.20.12.192:9990' is not a valid operation name.
> ''[standalone@172.20.12.192:9990'' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] ''[standalone@172.20.12.192:9990'' is not a valid operation name.
> '[standalone@172.20.12.192:9990' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] '''[standalone@172.20.12.192:9990''' is not a valid operation name.
> ''''[standalone@172.20.12.192:9990'''' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] ''[standalone@172.20.12.192:9990'' is not a valid oper is not a valid operation name.
> '[standalone@172.20.12.192:9990' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] '''''[standalone@172.20.12.192:9990''''' is not a valid operation name.
> ''''''[standalone@172.20.12.192:9990'''''' is not a valid operation name.
> attached is a strace capture file (one of thousands) of jboss-cli .
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (LOGMGR-191) Amend NullPointerException in RegexFilter.isLoggable()
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-191?page=com.atlassian.jira.plugin... ]
Yeray Borges reassigned LOGMGR-191:
-----------------------------------
Assignee: Yeray Borges
> Amend NullPointerException in RegexFilter.isLoggable()
> ------------------------------------------------------
>
> Key: LOGMGR-191
> URL: https://issues.jboss.org/browse/LOGMGR-191
> Project: JBoss Log Manager
> Issue Type: Bug
> Components: core
> Affects Versions: 2.1.0.Alpha5
> Reporter: Toshiya Kobayashi
> Assignee: Yeray Borges
> Labels: support
>
> When log message is null, RegexFilter.isLoggable() throws NullPointerException.
> https://github.com/jboss-logging/jboss-logmanager/blob/master/src/main/ja...
> It often results in unexpected outcomes. For example, assuming you have a filter-spec with "not(match(xxx))" to suppress some messages in your logger configuration:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:logging:3.0">
> <console-handler name="CONSOLE">
> <level name="INFO"/>
> <filter-spec value="not(match("SOME_MESSAGE"))"/>
> <formatter>
> <named-formatter name="COLOR-PATTERN"/>
> </formatter>
> </console-handler>
> {code}
> and an application has a code like this:
> {code:java}
> try {
> ...
> } catch (Exception e) {
> logger.error(e.getMessage(), e);
> }
> {code}
> "e.getMessage()" could be null. But you want to log the stacktrace 'e' anyway.
> In this case, NullPointerException is thrown from RegexFilter and reaches to LoggerNode and disappears. ConsoleHandler cannot publish the log at all.
> https://github.com/jboss-logging/jboss-logmanager/blob/master/src/main/ja...
> I think 'null' message should simply return 'false' in RegexFilter.isLoggable().
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2362) [Guided Decision Table] Parsing Number from value list doesn't work with white spaces
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2362?page=com.atlassian.jira.plugi... ]
Jozef Marko moved RHDM-464 to DROOLS-2362:
------------------------------------------
Project: Drools (was: Red Hat Decision Manager)
Key: DROOLS-2362 (was: RHDM-464)
Workflow: GIT Pull Request workflow (was: CDW with docs v1)
Docs QE Status: NEW
Component/s: Guided Decision Table Editor
(was: Decision Central)
Affects Version/s: 7.7.0.Final
(was: 7.0.0.GA)
(was: 7.0.0)
QE Status: NEW
> [Guided Decision Table] Parsing Number from value list doesn't work with white spaces
> -------------------------------------------------------------------------------------
>
> Key: DROOLS-2362
> URL: https://issues.jboss.org/browse/DROOLS-2362
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Affects Versions: 7.7.0.Final
> Reporter: Jozef Marko
> Assignee: Jozef Marko
> Priority: Minor
> Attachments: Screenshot from 2017-09-21 16-09-35.png
>
>
> If user specifies list of allowed numbers in the "Value List" input, numbers that are separated by white spaces are not parsed, see the number " 6" in the screenshot, it should be available in the "Default Value" list box.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3665) Bump the kernel management API version to 7.0.0 and the xsd to 7.0
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFCORE-3665:
-----------------------------------
Summary: Bump the kernel management API version to 7.0.0 and the xsd to 7.0
Key: WFCORE-3665
URL: https://issues.jboss.org/browse/WFCORE-3665
Project: WildFly Core
Issue Type: Task
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 4.0.0.Alpha1
We know there are going to be API changes in WF Core 4, so we need to get the API version bumped so that when those changes happen appropriate transformers can be written to transform to the previous version.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months