August 2016 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2714) Remove deprecated Reasteasy API from RTS

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2714?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2714. ------------------------------- > Remove deprecated Reasteasy API from RTS > ---------------------------------------- > > Key: JBTM-2714 > URL: https://issues.jboss.org/browse/JBTM-2714 > Project: JBoss Transaction Manager > Issue Type: Task > Components: REST > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Fix For: 5.3.4.Final > > > Deprecated Resteasy 2 APIs are being removed by 3.1.0. We need to upgrade the version and update our code to use new APIs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2715) Note compensations weld dependency in the docs

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2715?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2715. ------------------------------- > Note compensations weld dependency in the docs > ---------------------------------------------- > > Key: JBTM-2715 > URL: https://issues.jboss.org/browse/JBTM-2715 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations, Documentation > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.3.4.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2722) AtomicTransaction equals method is incorrect

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2722?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2722. ------------------------------- > AtomicTransaction equals method is incorrect > -------------------------------------------- > > Key: JBTM-2722 > URL: https://issues.jboss.org/browse/JBTM-2722 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > Fix For: 5.3.4.Final > > > Method returns false even for equal objects. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2724) Blacktie should not override maven-assembly-plugin version from parent

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2724?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2724. ------------------------------- > Blacktie should not override maven-assembly-plugin version from parent > ---------------------------------------------------------------------- > > Key: JBTM-2724 > URL: https://issues.jboss.org/browse/JBTM-2724 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Affects Versions: 5.3.3.Final > Environment: windows (http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-catelyn/1089) > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Blocker > Fix For: 5.3.4.Final > > > One of our PRs (http://albany.eng.hst.ams2.redhat.com/job/btny-pulls-narayana-catelyn/1089) ran on windows and failed due to a version issue with the maven-assembly-plugin. The blacktie/blacktie/pom.xml overrides the version set in the parent: > {quote} >  > <version>2.4</version> > {quote} > We should either retest without the version override or try to find another solution if the latest version of the plugin still has the same issue ([~zhfeng] are you aware of any alternative?). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2727) Add debug profile

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2727?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2727. ------------------------------- > Add debug profile > ----------------- > > Key: JBTM-2727 > URL: https://issues.jboss.org/browse/JBTM-2727 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Optional > Fix For: 5.3.4.Final > > > Add debug profile to the main pom.xml to make it easier to debug arquillian tests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2730) Moving txn datastore to machine with different default encoding can cause in-doubt participants not being recovered

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-2730?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-2730: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1047 > Moving txn datastore to machine with different default encoding can cause in-doubt participants not being recovered > ------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2730 > URL: https://issues.jboss.org/browse/JBTM-2730 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > Narayana uses system default encoding when encode and decode data for object store. This could be a trouble if user uses non-ASCII characters for node identifier and object store is meanwhile moved between machines with different default encodings. > I've currently revealed two cases which could cause a trouble: > * node id set as {{...}} _(there is needed to use some characters which are encoded in UTF-8 as more bytes characters)_ will let container being started for encoding ISO-8859-1 and won't be started for encoding UTF-8. That's when configuration moved from ISO-8859-1 machine to UTF-8 machine when the another machine will be expected to finish recovery of some failed txn the second machine fails to start. (sure, workaround is to set jvm default encoding via parameter {{-Dfile.encoding}}) > * node id set to {{kulaťoučký}}, whole eap installation moved from one machine with ISO-8859-1 to machine with default encoding set to UTF-8. Txn object store is copied too for second machine finishing in-doubt transaction by recovery. The second machine won't finish transactions which depends on node identifer check (bottom-up recovery) as node id will be decoded differently than it was understood at the first machine. > This issue was found by using static code analysis and reacts to report message > {code} > 21994 Dm: Dubious method used In org.jboss.narayana.osgi.jta.internal.ObjStoreBrowserImpl.ObjStoreBrowserImpl (com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser): Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2632) Allow the setting of an initial delay in PeriodRecovery

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2632?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2632. ------------------------------- Fix Version/s: (was: 5.next) Resolution: Duplicate Issue Duplicate of: https://issues.jboss.org/browse/JBTM-2720 > Allow the setting of an initial delay in PeriodRecovery > ------------------------------------------------------- > > Key: JBTM-2632 > URL: https://issues.jboss.org/browse/JBTM-2632 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Matthew Robson > Assignee: Tom Jenkinson > > Currently Periodic Recovery kicks off at the same interval on every server. As a domain mode cluster grows in size, this leads to significant contention in the DB, especially for RAC implementations. Completion time goes from milliseconds with 1 server to 20+ seconds with 20+ servers. > In an effort to avoid this, an offset the initial start of Periodic Recovery could be provided for the nodes in the cluster. > Periodic Recovery currently leverages 2 properties: > <system-properties> > <property name="RecoveryEnvironmentBean.periodicRecoveryPeriod" value="120"/> > <property name="RecoveryEnvironmentBean.recoveryBackoffPeriod" value="10"/> > </system-properties> > The proposal would be to add a 3rd property, 'RecoveryEnvironmentBean.periodicRecoveryInitilizationOffset' which, when set, would be used for each node. If not set, it would default to current behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2730) Moving txn datastore to machine with different default encoding can cause in-doubt participants not being recovered

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-2730?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated JBTM-2730: ---------------------------------- Affects Version/s: 5.3.3.Final > Moving txn datastore to machine with different default encoding can cause in-doubt participants not being recovered > ------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2730 > URL: https://issues.jboss.org/browse/JBTM-2730 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > Narayana uses system default encoding when encode and decode data for object store. This could be a trouble if user uses non-ASCII characters for node identifier and object store is meanwhile moved between machines with different default encodings. > I've currently revealed two cases which could cause a trouble: > * node id set as {{...}} _(there is needed to use some characters which are encoded in UTF-8 as more bytes characters)_ will let container being started for encoding ISO-8859-1 and won't be started for encoding UTF-8. That's when configuration moved from ISO-8859-1 machine to UTF-8 machine when the another machine will be expected to finish recovery of some failed txn the second machine fails to start. (sure, workaround is to set jvm default encoding via parameter {{-Dfile.encoding}}) > * node id set to {{kulaťoučký}}, whole eap installation moved from one machine with ISO-8859-1 to machine with default encoding set to UTF-8. Txn object store is copied too for second machine finishing in-doubt transaction by recovery. The second machine won't finish transactions which depends on node identifer check (bottom-up recovery) as node id will be decoded differently than it was understood at the first machine. > This issue was found by using static code analysis and reacts to report message > {code} > 21994 Dm: Dubious method used In org.jboss.narayana.osgi.jta.internal.ObjStoreBrowserImpl.ObjStoreBrowserImpl (com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser): Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2730) Moving txn datastore to machine with different default encoding can cause in-doubt participants not being recovered

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-2730?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka reassigned JBTM-2730: ------------------------------------- Assignee: Ondra Chaloupka > Moving txn datastore to machine with different default encoding can cause in-doubt participants not being recovered > ------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2730 > URL: https://issues.jboss.org/browse/JBTM-2730 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > Narayana uses system default encoding when encode and decode data for object store. This could be a trouble if user uses non-ASCII characters for node identifier and object store is meanwhile moved between machines with different default encodings. > I've currently revealed two cases which could cause a trouble: > * node id set as {{...}} _(there is needed to use some characters which are encoded in UTF-8 as more bytes characters)_ will let container being started for encoding ISO-8859-1 and won't be started for encoding UTF-8. That's when configuration moved from ISO-8859-1 machine to UTF-8 machine when the another machine will be expected to finish recovery of some failed txn the second machine fails to start. (sure, workaround is to set jvm default encoding via parameter {{-Dfile.encoding}}) > * node id set to {{kulaťoučký}}, whole eap installation moved from one machine with ISO-8859-1 to machine with default encoding set to UTF-8. Txn object store is copied too for second machine finishing in-doubt transaction by recovery. The second machine won't finish transactions which depends on node identifer check (bottom-up recovery) as node id will be decoded differently than it was understood at the first machine. > This issue was found by using static code analysis and reacts to report message > {code} > 21994 Dm: Dubious method used In org.jboss.narayana.osgi.jta.internal.ObjStoreBrowserImpl.ObjStoreBrowserImpl (com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser): Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2730) Moving txn datastore to machine with different default encoding can cause in-doubt participants not being recovered

by Ondra Chaloupka (JIRA)

Ondra Chaloupka created JBTM-2730: ------------------------------------- Summary: Moving txn datastore to machine with different default encoding can cause in-doubt participants not being recovered Key: JBTM-2730 URL: https://issues.jboss.org/browse/JBTM-2730 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Ondra Chaloupka Narayana uses system default encoding when encode and decode data for object store. This could be a trouble if user uses non-ASCII characters for node identifier and object store is meanwhile moved between machines with different default encodings. I've currently revealed two cases which could cause a trouble: * node id set as {{...}} _(there is needed to use some characters which are encoded in UTF-8 as more bytes characters)_ will let container being started for encoding ISO-8859-1 and won't be started for encoding UTF-8. That's when configuration moved from ISO-8859-1 machine to UTF-8 machine when the another machine will be expected to finish recovery of some failed txn the second machine fails to start. (sure, workaround is to set jvm default encoding via parameter {{-Dfile.encoding}}) * node id set to {{kulaťoučký}}, whole eap installation moved from one machine with ISO-8859-1 to machine with default encoding set to UTF-8. Txn object store is copied too for second machine finishing in-doubt transaction by recovery. The second machine won't finish transactions which depends on node identifer check (bottom-up recovery) as node id will be decoded differently than it was understood at the first machine. This issue was found by using static code analysis and reacts to report message {code} 21994 Dm: Dubious method used In org.jboss.narayana.osgi.jta.internal.ObjStoreBrowserImpl.ObjStoreBrowserImpl (com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser): Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable) {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues August 2016