October 2017 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2939) JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2939?page=com.atlassian.jira.plugin.... ] Michael Musgrove commented on JBTM-2939: ---------------------------------------- Just to add some clarification: since recovery is handling the transaction there must be a log for it which in turn means that the prepare phase has ended and a decision has been made to commit the transaction. Now since a resource is not allowed to forget a heuristic decision and since the resource no longer has record of the xid it is safe to infer that the resource has indeed successfully committed its branch (ie from the TM's point of view this is not a heuristic). > JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA > -------------------------------------------------------------------------------------------- > > Key: JBTM-2939 > URL: https://issues.jboss.org/browse/JBTM-2939 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTS > Affects Versions: 5.7.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > JTS moves transaction to heuristic state when participant during recovery returns {{XAExeption.XAER_NOTA}} error code. This is a bit pointless as this particular error code does not mean that there was some trouble with RM but that RM just already does not know about the transaction branch. For recovery it means that the branch was committed/rolled-back either before recovery started or in some previous recovery run (where probably something crashed). > We can assumed the transaction was completed and ignore the {{XAER_NOTA}} (in case of recovery). This behaviour is already present in JTA. > This came from EAP issue: JBEAP-13023 where you can find more on the reproducing. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2939) JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-2939?page=com.atlassian.jira.plugin.... ] Work on JBTM-2939 started by Ondra Chaloupka. --------------------------------------------- > JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA > -------------------------------------------------------------------------------------------- > > Key: JBTM-2939 > URL: https://issues.jboss.org/browse/JBTM-2939 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTS > Affects Versions: 5.7.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > JTS moves transaction to heuristic state when participant during recovery returns {{XAExeption.XAER_NOTA}} error code. This is a bit pointless as this particular error code does not mean that there was some trouble with RM but that RM just already does not know about the transaction branch. For recovery it means that the branch was committed/rolled-back either before recovery started or in some previous recovery run (where probably something crashed). > We can assumed the transaction was completed and ignore the {{XAER_NOTA}} (in case of recovery). This behaviour is already present in JTA. > This came from EAP issue: JBEAP-13023 where you can find more on the reproducing. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2939) JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-2939?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1229 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA > -------------------------------------------------------------------------------------------- > > Key: JBTM-2939 > URL: https://issues.jboss.org/browse/JBTM-2939 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTS > Affects Versions: 5.7.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > JTS moves transaction to heuristic state when participant during recovery returns {{XAExeption.XAER_NOTA}} error code. This is a bit pointless as this particular error code does not mean that there was some trouble with RM but that RM just already does not know about the transaction branch. For recovery it means that the branch was committed/rolled-back either before recovery started or in some previous recovery run (where probably something crashed). > We can assumed the transaction was completed and ignore the {{XAER_NOTA}} (in case of recovery). This behaviour is already present in JTA. > This came from EAP issue: JBEAP-13023 where you can find more on the reproducing. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2880) Refactor codebase to minimize usage of e.printStackTrace() call and change for using logger

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/JBTM-2880?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1229 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Refactor codebase to minimize usage of e.printStackTrace() call and change for using logger > ------------------------------------------------------------------------------------------- > > Key: JBTM-2880 > URL: https://issues.jboss.org/browse/JBTM-2880 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Affects Versions: 5.5.6.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > The code base uses call `e.printStackTrace()` on several places. That usage should be minimized and used only when it's good reason for it. In general such calls should be replaced printing with `logger`, probably in level `WARN` with some additional information, why the stacktrace is printed - what error occured - included. > By quick check these are places where exception stack trace is printed directly to `stderr`. > {code} > -vertx/shared/src/main/java/ClientVerticle.java- > -vertx/shared/src/main/java/SampleVerticle2.java- > -vertx/shared/src/main/java/SampleVerticle1.java- > osgi/jta/src/main/java/org/jboss/narayana/osgi/jta/internal/ObjStoreBrowserImpl.java > XTS/WSAS/classes/com/arjuna/mwlabs/wsas/UserActivityImple.java > XTS/WSAS/classes/com/arjuna/mwlabs/wsas/activity/ActivityHandleImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf11/model/sagas/arjunacore/SagasHLSImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf11/model/twophase/arjunacore/TwoPhaseHLSImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/sagas/arjunacore/ParticipantRecord.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/sagas/arjunacore/CoordinatorControl.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/ParticipantRecord.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/CoordinatorControl.java > XTS/WSCF/classes/com/arjuna/mw/wscf/utils/DomUtil.java > XTS/WSCF/classes/com/arjuna/mw/wscf/protocols/ProtocolManager.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/RegistrarImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/context/ArjunaContextImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/TransactionManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/UserTransactionImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/UserTransactionStandaloneImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/participants/CleanupSynchronization.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/ContextFactoryImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/context/ArjunaContextImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/UserBusinessActivityImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/BusinessActivityManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/BAParticipantManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/UserBusinessActivityStandaloneImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/participants/CleanupSynchronization.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/ContextFactoryImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst/at/participants/DurableTwoPhaseCommitParticipant.java > XTS/localjunit/WSTX11-interop/src/main/java/com/jboss/transaction/txinterop/proxy/ProxyListenerService.java > XTS/localjunit/WSTFSC07-interop/src/main/java/com/jboss/transaction/wstf/proxy/ProxyListenerService.java > XTS/WS-T/dev/src/com/arjuna/schemas/ws/_2005/_10/wsarjtx/TerminationCoordinatorRPCService.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/CompletionStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/CompletionRPCStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/BusinessActivityTerminatorRPCStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/TerminationCoordinatorRPCProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/CompletionCoordinatorProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/CompletionCoordinatorRPCProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/TerminationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/wsc11/messaging/ActivationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/wsc11/messaging/RegistrationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/webservices/SoapFault.java > ArjunaJTA/jta/classes/com/arjuna/ats/jta/xa/XidImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/XATerminatorImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/TransactionImporterImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/TransactionImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/subordinate/TransactionImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/recovery/arjunacore/SubordinateJTAXAResourceOrphanFilter.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/DirectRecoverableConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/ConnectionManager.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/ProvidedXADataSourceConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/IndirectRecoverableConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/recovery/JDBCXARecovery.java > blacktie/utils/cpp-plugin/src/main/java/org/jboss/narayana/blacktie/plugins/AddCommonSources.java > blacktie/jatmibroker-xatmi/src/main/java/org/jboss/narayana/blacktie/jatmibroker/core/server/SocketServer.java > blacktie/wildfly-blacktie/subsystem/src/main/java/org/codehaus/stomp/jms/ProtocolConverter.java > blacktie/blacktie-admin-services/src/main/java/org/jboss/narayana/blacktie/administration/core/AdministrationProxy.java > tools/src/main/java/io/narayana/perf/Measurement.java > rts/at/tx/src/main/java/org/jboss/jbossts/star/resource/RESTRecord.java > rts/at/tx/src/main/java/org/jboss/jbossts/star/service/Coordinator.java > txframework/src/main/java/org/jboss/narayana/txframework/impl/Participant.java > compensations/src/main/java/org/jboss/narayana/compensations/internal/ParticipantInterceptor.java > compensations/src/main/java/org/jboss/narayana/compensations/internal/ParticipantImpl.java > ArjunaCore/arjuna/services/classes/com/arjuna/ats/arjuna/services/recovery/RecoveryManagerService.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/utils/AndroidProcessId.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/abstractrecords/CadaverRecord.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/ShadowingStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/CacheStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/LogStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/AbstractRecord.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/BasicAction.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/common/ObjectStoreEnvironmentBean.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/log/LogBrowser.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/stats/TxPerfGraph.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/OTM.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/StateManager.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/recovery/RecoveryManager.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jta/jca/XATerminator.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jts/jca/XATerminator.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jts/PropagationContextManager.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/jca/XATerminatorImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/BaseTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/TransactionImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/jca/coordinator/ServerTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/jca/SubordinateAtomicTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/TransactionImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/SubordinateAtomicTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/resources/jts/orbspecific/XAResourceRecord.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/recovery/jts/JCAServerTransactionRecoveryModule.java > ArjunaJTS/orbportability/classes/com/arjuna/orbportability/common/ant/IDLCompiler.java > ArjunaJTS/jts/services/classes/com/arjuna/ats/jts/services/transactionserver/TransactionServerService.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/utils/TxStoreLog.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/interposition/ServerControl.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/coordinator/ArjunaTransactionImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/jacorb/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/jacorb/recoverycoordinators/JacOrbRCServiceInit.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/ibmorb/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/javaidl/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/CurrentImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/TransactionFactoryImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/recovery/RecoveryEnablement.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/context/ContextManager.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/resources/ExtendedResourceRecord.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/TransactionServer.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/jacorb/interceptors/interposition/InterpositionClientRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/jacorb/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/ibmorb/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/javaidl/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/ExplicitInterposition.java > STM/src/main/java/org/jboss/stm/internal/reflect/InvocationHandler.java > STM/src/main/java/org/jboss/stm/internal/proxy/OptimisticLockManagerProxy.java > STM/src/main/java/org/jboss/stm/internal/proxy/LockManagerProxy.java > STM/src/main/java/org/jboss/stm/internal/optimistic/OptimisticLockRecord.java > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2943) Remove ability for participants to return business logic from their completion handlers

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2943?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2943: -------------------------------- Component/s: LRA > Remove ability for participants to return business logic from their completion handlers > --------------------------------------------------------------------------------------- > > Key: JBTM-2943 > URL: https://issues.jboss.org/browse/JBTM-2943 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > > This would be an anti-pattern - the MSA could get this data from eventing. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2943) Remove ability for participants to return business logic from their completion handlers

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2943?page=com.atlassian.jira.plugin.... ] Tom Jenkinson reassigned JBTM-2943: ----------------------------------- Assignee: Michael Musgrove > Remove ability for participants to return business logic from their completion handlers > --------------------------------------------------------------------------------------- > > Key: JBTM-2943 > URL: https://issues.jboss.org/browse/JBTM-2943 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > > This would be an anti-pattern - the MSA could get this data from eventing. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2943) Remove ability for participants to return business logic from their completion handlers

by Tom Jenkinson (JIRA)

Tom Jenkinson created JBTM-2943: ----------------------------------- Summary: Remove ability for participants to return business logic from their completion handlers Key: JBTM-2943 URL: https://issues.jboss.org/browse/JBTM-2943 Project: JBoss Transaction Manager Issue Type: Bug Reporter: Tom Jenkinson This would be an anti-pattern - the MSA could get this data from eventing. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2936) JAX-RS response headers from an LRA @Nested method doesn't include the parent LRA id

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2936?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2936: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > JAX-RS response headers from an LRA @Nested method doesn't include the parent LRA id > ------------------------------------------------------------------------------------ > > Key: JBTM-2936 > URL: https://issues.jboss.org/browse/JBTM-2936 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > When a JAX-RS resource method annotated with @Nested returns the response headers do not include the parent LRA id. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2934) LRA nested and parent coordinators should optimise calls when in a single VM

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2934?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2934: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > LRA nested and parent coordinators should optimise calls when in a single VM > ---------------------------------------------------------------------------- > > Key: JBTM-2934 > URL: https://issues.jboss.org/browse/JBTM-2934 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Application Server Integration, LRA > Affects Versions: 5.6.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > LRA nested and parent coordinators use JAX-RS requests to driver the LRA protocol. When the two coordinators are in the same JVM direct jave method calls should be used. > The need for this enhancement is to support running on OpenShift. A secondary benefit is performance. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2938) LRA participant complete/compensate methods should use HTTP PUT

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2938?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2938: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > LRA participant complete/compensate methods should use HTTP PUT > --------------------------------------------------------------- > > Key: JBTM-2938 > URL: https://issues.jboss.org/browse/JBTM-2938 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > LRA participant complete and compensate methods are currently called using an HTTP POST request. Since these methods should be idempotent they should respond to PUT since in a REST based system PUT is idempotent and POST is not. > Both the implementation and the specification need changing. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 2 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 October 2017