[JBoss JIRA] (JGRP-1732) UNICAST/NAKACK: threads from the internal thread pool should not do work stealing
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1732?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1732:
--------------------------------
Done for UNICAST3 and NAKACK2 which are the recommended protocols for unicast and multicast retransmission respectively.
> UNICAST/NAKACK: threads from the internal thread pool should not do work stealing
> ---------------------------------------------------------------------------------
>
> Key: JGRP-1732
> URL: https://issues.jboss.org/browse/JGRP-1732
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> In NAKACK\{2\} and UNICAST\{2,3\}, threads from all thread pools (regular, OOB and internal) add messages to the table, then grab as many (ordered) messages as possible from the table and pass them up.
> This could lead to the case where an internal thread passes up regular or OOB messages, which might block. There's a (small) chance that this exhausts the internal thread pool.
> Internal threads should therefore never block, and never steal work from other thread pools.
> SOLUTION:
> * An internal thread only adds the message to the table and passes it up if in order
> * If the internal message is OOB, it is passed up and then the thread returns
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JGRP-1732) UNICAST/NAKACK: threads from the internal thread pool should not do work stealing
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1732?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1732:
--------------------------------
This is only done for single messages which are marked as {{OOB | INTERNAL}}. For message *batches*, all OOB messages are delivered before regular messages. Internal-only (non OOB) messages are delivered in the order in which they were batched.
The suggestion at this point is to send internal messages as {{INTERNAL | OOB | DONT_BUNDLE}}. When JGRP-1737 is implemented, all messages will be bundled, but messages tagged with {{DONT_BUNDLE}} will get delivered on a seperate thread.
> UNICAST/NAKACK: threads from the internal thread pool should not do work stealing
> ---------------------------------------------------------------------------------
>
> Key: JGRP-1732
> URL: https://issues.jboss.org/browse/JGRP-1732
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> In NAKACK\{2\} and UNICAST\{2,3\}, threads from all thread pools (regular, OOB and internal) add messages to the table, then grab as many (ordered) messages as possible from the table and pass them up.
> This could lead to the case where an internal thread passes up regular or OOB messages, which might block. There's a (small) chance that this exhausts the internal thread pool.
> Internal threads should therefore never block, and never steal work from other thread pools.
> SOLUTION:
> * An internal thread only adds the message to the table and passes it up if in order
> * If the internal message is OOB, it is passed up and then the thread returns
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2485) @Transactional not working correctly with @Stereotype wrt. Exception handling
by David Mann (JIRA)
David Mann created WFLY-2485:
--------------------------------
Summary: @Transactional not working correctly with @Stereotype wrt. Exception handling
Key: WFLY-2485
URL: https://issues.jboss.org/browse/WFLY-2485
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Transactions
Affects Versions: 8.0.0.Beta1
Reporter: David Mann
Assignee: Tom Jenkinson
Priority: Minor
Hi,
suppose I have a @Stereotype with a @Transactional annotation:
@Named
@ViewScoped
@Transactional
@Stereotype
@Retention (RetentionPolicy.RUNTIME)
@Target (ElementType.TYPE)
public @interface Boundary
{ }
I annotate a CDI Bean with this stereotype
@Boundary
public class BusinessLogic {
public void doSomething(){
throw new RuntimeException("foo");
}
}
If any exceptions are thrown when calling the business method, the user will get the (incorrect) info that the Class is missing a @Transactional annotation, because the Interceptor doesn't bother to look further into the Stereotype (see below).
What's worse, the interceptor is swallowing the real exeption in the process. We get the following Stacktrace:
java.lang.RuntimeException: ARJUNA016107: Expected an @Transactional annotation at class and/or method level
at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.getTransactional(TransactionalInterceptorBase.java:61)
at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.handleException(TransactionalInterceptorBase.java:96)
at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:72)
Which is pretty clear from the implementation of TransactionalInterceptorBase (taken from here):
private Transactional getTransactional(InvocationContext ic) {
Transactional transactional = ic.getMethod().getAnnotation(Transactional.class);
if (transactional != null) {
return transactional;
}
Class<?> targetClass = ic.getTarget().getClass();
transactional = targetClass.getAnnotation(Transactional.class); // needs to look further
if (transactional != null) {
return transactional;
}
throw new RuntimeException(jtaLogger.i18NLogger.get_expected_transactional_annotation()); // swallows the exception that occured at ic.proceed()
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2485) @Transactional not working correctly with @Stereotype wrt. Exception handling
by David Mann (JIRA)
[ https://issues.jboss.org/browse/WFLY-2485?page=com.atlassian.jira.plugin.... ]
David Mann updated WFLY-2485:
-----------------------------
Description:
Hi,
suppose I have a @Stereotype with a @Transactional annotation:
@Named
@ViewScoped
@Transactional
@Stereotype
@Retention (RetentionPolicy.RUNTIME)
@Target (ElementType.TYPE)
public @interface Boundary
{ }
I annotate a CDI Bean with this stereotype
@Boundary
public class BusinessLogic {
public void doSomething(){
throw new RuntimeException("foo");
}
}
If any exceptions are thrown when calling the business method, the user will get the (incorrect) info that the Class is missing a @Transactional annotation, because the Interceptor doesn't bother to look further into the Stereotype (see below).
What's worse, the interceptor is swallowing the real exeption in the process. We get the following Stacktrace:
java.lang.RuntimeException: ARJUNA016107: Expected an @Transactional annotation at class and/or method level
at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.getTransactional(TransactionalInterceptorBase.java:61)
at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.handleException(TransactionalInterceptorBase.java:96)
at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:72)
Which is pretty clear from the implementation of TransactionalInterceptorBase:
private Transactional getTransactional(InvocationContext ic) {
Transactional transactional = ic.getMethod().getAnnotation(Transactional.class);
if (transactional != null) {
return transactional;
}
Class<?> targetClass = ic.getTarget().getClass();
transactional = targetClass.getAnnotation(Transactional.class); // needs to look further
if (transactional != null) {
return transactional;
}
throw new RuntimeException(jtaLogger.i18NLogger.get_expected_transactional_annotation()); // swallows the exception that occured at ic.proceed()
}
was:
Hi,
suppose I have a @Stereotype with a @Transactional annotation:
@Named
@ViewScoped
@Transactional
@Stereotype
@Retention (RetentionPolicy.RUNTIME)
@Target (ElementType.TYPE)
public @interface Boundary
{ }
I annotate a CDI Bean with this stereotype
@Boundary
public class BusinessLogic {
public void doSomething(){
throw new RuntimeException("foo");
}
}
If any exceptions are thrown when calling the business method, the user will get the (incorrect) info that the Class is missing a @Transactional annotation, because the Interceptor doesn't bother to look further into the Stereotype (see below).
What's worse, the interceptor is swallowing the real exeption in the process. We get the following Stacktrace:
java.lang.RuntimeException: ARJUNA016107: Expected an @Transactional annotation at class and/or method level
at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.getTransactional(TransactionalInterceptorBase.java:61)
at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.handleException(TransactionalInterceptorBase.java:96)
at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:72)
Which is pretty clear from the implementation of TransactionalInterceptorBase (taken from here):
private Transactional getTransactional(InvocationContext ic) {
Transactional transactional = ic.getMethod().getAnnotation(Transactional.class);
if (transactional != null) {
return transactional;
}
Class<?> targetClass = ic.getTarget().getClass();
transactional = targetClass.getAnnotation(Transactional.class); // needs to look further
if (transactional != null) {
return transactional;
}
throw new RuntimeException(jtaLogger.i18NLogger.get_expected_transactional_annotation()); // swallows the exception that occured at ic.proceed()
}
> @Transactional not working correctly with @Stereotype wrt. Exception handling
> -----------------------------------------------------------------------------
>
> Key: WFLY-2485
> URL: https://issues.jboss.org/browse/WFLY-2485
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transactions
> Affects Versions: 8.0.0.Beta1
> Reporter: David Mann
> Assignee: Tom Jenkinson
> Priority: Minor
>
> Hi,
>
> suppose I have a @Stereotype with a @Transactional annotation:
>
> @Named
> @ViewScoped
> @Transactional
> @Stereotype
> @Retention (RetentionPolicy.RUNTIME)
> @Target (ElementType.TYPE)
> public @interface Boundary
> { }
>
> I annotate a CDI Bean with this stereotype
>
> @Boundary
> public class BusinessLogic {
> public void doSomething(){
> throw new RuntimeException("foo");
> }
> }
>
> If any exceptions are thrown when calling the business method, the user will get the (incorrect) info that the Class is missing a @Transactional annotation, because the Interceptor doesn't bother to look further into the Stereotype (see below).
>
> What's worse, the interceptor is swallowing the real exeption in the process. We get the following Stacktrace:
>
> java.lang.RuntimeException: ARJUNA016107: Expected an @Transactional annotation at class and/or method level
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.getTransactional(TransactionalInterceptorBase.java:61)
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.handleException(TransactionalInterceptorBase.java:96)
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:72)
> Which is pretty clear from the implementation of TransactionalInterceptorBase:
> private Transactional getTransactional(InvocationContext ic) {
>
> Transactional transactional = ic.getMethod().getAnnotation(Transactional.class);
> if (transactional != null) {
> return transactional;
> }
>
> Class<?> targetClass = ic.getTarget().getClass();
> transactional = targetClass.getAnnotation(Transactional.class); // needs to look further
> if (transactional != null) {
> return transactional;
> }
>
> throw new RuntimeException(jtaLogger.i18NLogger.get_expected_transactional_annotation()); // swallows the exception that occured at ic.proceed()
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-1284) ClientCompatibilityUnitTestCase does not test 7.0.0 or 7.0.1
by Emanuel Muckenhuber (JIRA)
[ https://issues.jboss.org/browse/WFLY-1284?page=com.atlassian.jira.plugin.... ]
Emanuel Muckenhuber resolved WFLY-1284.
---------------------------------------
Resolution: Out of Date
I fixed the instantiation of the client, however there are some problems with older clients to connect therefore those tests remain ignored.
> ClientCompatibilityUnitTestCase does not test 7.0.0 or 7.0.1
> ------------------------------------------------------------
>
> Key: WFLY-1284
> URL: https://issues.jboss.org/browse/WFLY-1284
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite
> Reporter: Stuart Douglas
> Assignee: Emanuel Muckenhuber
>
> org.jboss.as.controller.client.impl.ClientConfigurationImpl was not present in these versions, so the test actually ends up with the current model controller client rather than an old version.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-1982) NPE in ModelControllerLock
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1982?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1982:
-----------------------------------------------
Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1024862|https://bugzilla.redhat.com/show_bug.cgi?id=1024862] from ON_QA to VERIFIED
> NPE in ModelControllerLock
> --------------------------
>
> Key: WFLY-1982
> URL: https://issues.jboss.org/browse/WFLY-1982
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Emanuel Muckenhuber
> Fix For: 8.0.0.CR1
>
>
> Just noticed this in the host-controller.log while looking into a non-progressing RespawnTestCase:
> 22:23:50,552 ERROR [org.jboss.as.controller.management-operation] (proxy-threads - 1) JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.NullPointerException
> at org.jboss.as.controller.ModelControllerLock$Sync.tryAcquire(ModelControllerLock.java:75) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1220) [rt.jar:1.7.0_15]
> at org.jboss.as.controller.ModelControllerLock.lockInterruptibly(ModelControllerLock.java:48) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.acquireLock(ModelControllerImpl.java:582) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.takeWriteLock(OperationContextImpl.java:403) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.acquireControllerLock(OperationContextImpl.java:700) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1$1.execute(ServerToHostProtocolHandler.java:268)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:257) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:292) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService.access$600(DomainModelControllerService.java:148)
> at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:899)
> at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1.execute(ServerToHostProtocolHandler.java:282)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-1982) NPE in ModelControllerLock
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1982?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1982:
-----------------------------------------------
Petr Kremensky <pkremens(a)redhat.com> made a comment on [bug 1024862|https://bugzilla.redhat.com/show_bug.cgi?id=1024862]
This issue was verified using the 6.2.0.CR1 preview bits.
> NPE in ModelControllerLock
> --------------------------
>
> Key: WFLY-1982
> URL: https://issues.jboss.org/browse/WFLY-1982
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Emanuel Muckenhuber
> Fix For: 8.0.0.CR1
>
>
> Just noticed this in the host-controller.log while looking into a non-progressing RespawnTestCase:
> 22:23:50,552 ERROR [org.jboss.as.controller.management-operation] (proxy-threads - 1) JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.NullPointerException
> at org.jboss.as.controller.ModelControllerLock$Sync.tryAcquire(ModelControllerLock.java:75) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1220) [rt.jar:1.7.0_15]
> at org.jboss.as.controller.ModelControllerLock.lockInterruptibly(ModelControllerLock.java:48) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.acquireLock(ModelControllerImpl.java:582) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.takeWriteLock(OperationContextImpl.java:403) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.acquireControllerLock(OperationContextImpl.java:700) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1$1.execute(ServerToHostProtocolHandler.java:268)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:257) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:292) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService.access$600(DomainModelControllerService.java:148)
> at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:899)
> at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1.execute(ServerToHostProtocolHandler.java:282)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (WFLY-2455) Cannot configure the list of recovery modules due to ArjunaRecoveryManagerService hardcoding them
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-2455?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on WFLY-2455:
-------------------------------------
Just to comment as per the forum discussion, the HQ XAResourceRecovery should certainly be enlisted we have a lot of tests for that so if you have a test case for that please can you add it here?
Otherwise we should look at this rather an enhancement than a bug.
Thanks for the report
> Cannot configure the list of recovery modules due to ArjunaRecoveryManagerService hardcoding them
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-2455
> URL: https://issues.jboss.org/browse/WFLY-2455
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transactions
> Affects Versions: 8.0.0.Beta1
> Reporter: gui borland
> Assignee: Tom Jenkinson
>
> Using a custom jbossts-properties.xml file defined via the com.arjuna.ats.arjuna.common.propertiesFile systemsetting, i can register a custom recovery manager for arjuna.
> However, the ArjunaRecoveryManagerService class overwrite the recovery configuration mentioned in my jbossts-properties.xml file with a hardcoded list of recovery modules.
> This makes me wonder if/how the hornetq recovery (org.hornetq.jms.server.recovery.HornetQXAResourceRecover) gets registered in wildfly..
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months