February 2017 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2862) Check places where trace logs are not conditional, especially see xts bridge

by Ondra Chaloupka (JIRA)

Ondra Chaloupka created JBTM-2862: ------------------------------------- Summary: Check places where trace logs are not conditional, especially see xts bridge Key: JBTM-2862 URL: https://issues.jboss.org/browse/JBTM-2862 Project: JBoss Transaction Manager Issue Type: Enhancement Components: XTS Affects Versions: 5.5.3.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Priority: Minor During an investigation on JBTM-2853 and JBTM-2858 was discovered there are places where {{txbridgeLogger.logger.trace}} is used without conditional check if trace logging is enabled or not as it's good practice in other parts of the code. It should be checked where the conditional trace logging misses and fix those places. A hot candidate is XTS but there could be other places in code base too. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2861) Introduce the authorization checking

by Amos Feng (JIRA)

Amos Feng created JBTM-2861: ------------------------------- Summary: Introduce the authorization checking Key: JBTM-2861 URL: https://issues.jboss.org/browse/JBTM-2861 Project: JBoss Transaction Manager Issue Type: Enhancement Components: JTS Reporter: Amos Feng Assignee: Amos Feng -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2860) Add new event types for authorization checking

by Amos Feng (JIRA)

Amos Feng created JBTM-2860: ------------------------------- Summary: Add new event types for authorization checking Key: JBTM-2860 URL: https://issues.jboss.org/browse/JBTM-2860 Project: JBoss Transaction Manager Issue Type: Enhancement Components: SPI Reporter: Amos Feng Assignee: Amos Feng -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2831) Fix RTS inbound bridge participant deserialiser registration

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2831?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2831: -------------------------------- Fix Version/s: 5.next (was: 5.5.3.Final) > Fix RTS inbound bridge participant deserialiser registration > ------------------------------------------------------------ > > Key: JBTM-2831 > URL: https://issues.jboss.org/browse/JBTM-2831 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Fix For: 5.next > > > Inbound bridge participant deserialiser is registered when InboundBridgeManager is created [1]. That deserialiser is immediately used to recreate participants and update REST-AT coordinator via its HTTP resource. > In WildFly deserialiser registration used to be triggered by creating InboundBridgeManager instance in InboundBridgeService#start method. > However, Undertow subsystem update was introduced which collected and held all HTTP requests until application server completed boot-up. This caused a lock because HTTP call to REST-AT coordinator was being held and InboundBridgeService was waiting for the response. As a result server never completed boot. > Tom has removed that initialisation as a workaround [2]. Everything still works, because inbound bridge recovery manager initialises InboundBridgeManager too. However, only in the second pass. This causes warnings messages during the first cycle of the recovery by REST-AT recovery module. > I'm suggesting to remove deserialiser registration from InboundBridgeManager constructor to keep it as simple as possible and move it to other place were it could be invoked safely and on time e.g. start of first pass of InboundBridgeRecoveryModule. > [1] https://github.com/jbosstm/narayana/blob/5.5.0.Final/rts/at/bridge/src/ma... > [2] https://github.com/wildfly/wildfly/commit/6bc2e6a20b665201505f12c1c22fda9... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2833) Move deprecated tooling classes into an internal package

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2833?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2833: -------------------------------- Fix Version/s: 5.next (was: 5.5.3.Final) > Move deprecated tooling classes into an internal package > -------------------------------------------------------- > > Key: JBTM-2833 > URL: https://issues.jboss.org/browse/JBTM-2833 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Tooling > Affects Versions: 5.5.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > commit 66a9291f56f (JBTM-2308]) "Mark classes deprecated since we need to rejig package names" marked many/most of the tooling instrumentation classes deprecated - these need to be moved to internal packages and the then marked as not deprecated. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2542) Migrate performance tests to the performance repo

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2542?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2542: -------------------------------- Fix Version/s: 5.next (was: 5.5.3.Final) > Migrate performance tests to the performance repo > ------------------------------------------------- > > Key: JBTM-2542 > URL: https://issues.jboss.org/browse/JBTM-2542 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > Attachments: config.xml, eap-cmp-config.xml > > > We still have lots of performance related unit tests that need migrating: > rts/at/tx/src/test/java/org/jboss/jbossts/star/test/PerformanceTest.java > ArjunaJTA/jta/tests/classes/com/arjuna/ats/jta/xa/performance/OnePhasePerformanceDefaultUnitTest.java > ArjunaJTA/jta/tests/classes/com/arjuna/ats/jta/xa/performance/OnePhasePerformanceVolatileUnitTest.java > ArjunaJTA/jta/tests/classes/com/arjuna/ats/jta/xa/performance/OnePhase2PCPerformanceVolatileUnitTest.java > ArjunaJTA/jta/tests/classes/com/arjuna/ats/jta/xa/performance/OnePhase2PCPerformanceDefaultUnitTest.java > ArjunaJTA/jta/tests/classes/com/hp/mwtests/ts/jta/commitmarkable/PerformanceTestCommitMarkableResource.java > ArjunaCore/arjuna/tests/classes/com/hp/mwtests/ts/arjuna/performance/Performance1.java > ArjunaCore/arjuna/tests/classes/com/hp/mwtests/ts/arjuna/performance/Performance2.java > ArjunaCore/arjuna/tests/classes/com/hp/mwtests/ts/arjuna/performance/Performance4.java > ArjunaCore/arjuna/tests/classes/com/hp/mwtests/ts/arjuna/performance/Performance3.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/orbspecific/local/performance/Performance1.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/orbspecific/local/performance/Performance2.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/orbspecific/local/performance/Performance3.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/remote/hammer/PerfHammer.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/remote/hammer/GridWorker.java > ArjunaJTS/jts/tests/classes/com/hp/mwtests/ts/jts/local/synchronizations/Performance.java > ArjunaJTA/jta/tests/classes/io/narayana/perf/product/Product.java > ArjunaJTA/jta/tests/classes/io/narayana/perf/product/ProductWorker.java -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2841) HybridSocketEndpointQueue::_send() needs wrapper around apr_socket_send()

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2841?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2841: -------------------------------- Fix Version/s: 5.next (was: 5.5.3.Final) > HybridSocketEndpointQueue::_send() needs wrapper around apr_socket_send() > ------------------------------------------------------------------------- > > Key: JBTM-2841 > URL: https://issues.jboss.org/browse/JBTM-2841 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > tpreturn() seems to non-block send without checking tranfer length. > It needs a wrapper of looping apr_socket_send() until all of the data write to the socket. > similar like [stomp_write_buffer|https://github.com/jbosstm/narayana/blob/c035f66960d18...] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2852) Transaction integration failures with CDI

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2852?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2852. ------------------------------- > Transaction integration failures with CDI > ----------------------------------------- > > Key: JBTM-2852 > URL: https://issues.jboss.org/browse/JBTM-2852 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.5.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Blocker > Fix For: 5.5.3.Final > > > There are failures in integration of transaction and cdi because of introducing of new wildfly transaction client. > The new client does not verify transaction availability where JTA-CDI requires IllegalStateException. > Related test case could be > https://github.com/scottmarlow/wildfly/commit/34385c25a2b0126eafe791914ef... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2849) Correct typo in docs regarding versions of the spec XTS supports

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2849?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2849. ------------------------------- > Correct typo in docs regarding versions of the spec XTS supports > ---------------------------------------------------------------- > > Key: JBTM-2849 > URL: https://issues.jboss.org/browse/JBTM-2849 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.5.3.Final > > > XTS implements 1.1 and 1.2, not 1.0: > https://github.com/jbosstm/documentation/edit/master/product/en-US/txbrid... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2846) Thread-safety problem in BasicAction

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2846?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2846. ------------------------------- > Thread-safety problem in BasicAction > ------------------------------------ > > Key: JBTM-2846 > URL: https://issues.jboss.org/browse/JBTM-2846 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.4.0.Final > Reporter: David Lloyd > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.5.3.Final > > > It is possible for multiple threads to have a given transaction association at the same time ({{com.arjuna.ats.arjuna.coordinator.BasicAction#_childThreads}}). However, only inconsistent protection is provided for {{com.arjuna.ats.arjuna.coordinator.BasicAction#actionStatus}}. In particular, the {{com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple#setRollbackOnly}} method directly calls {{com.arjuna.ats.arjuna.coordinator.BasicAction#preventCommit}}, which, without lock or atomicity, both reads and modifies {{actionStatus}}. This will result in a poorly-defined outcome when threads concurrently call {{setRollbackOnly()}} and, say, {{rollback()}}. > Other methods access {{actionStatus}} without regard to concurrently protection, including: > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#save_state}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#toString}} > * {{com.arjuna.ats.arjuna.coordinator.BasicAction#restore_state}} > Some methods appear to be assuming that other methods will acquire the instance monitor before calling them; as a matter of best practice, such methods should have {{assert Thread.holdsLock(this);}} at their beginning point. > Other fields in the class should also be analyzed for unsafe access. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues February 2017