[JBoss JIRA] (WFCORE-4525) Fix failing tests on IBM JDK
by Richard Opalka (Jira)
[ https://issues.jboss.org/browse/WFCORE-4525?page=com.atlassian.jira.plugi... ]
Richard Opalka commented on WFCORE-4525:
----------------------------------------
SilentModeTestCase started to pass in IBM JDK [~jamezp].
You meant that both
* CLIEmbedHostControllerTestCase
* CLIEmbedServerTestCase
should be annotated with @Ignore if IBM JDK is detected?
> Fix failing tests on IBM JDK
> ----------------------------
>
> Key: WFCORE-4525
> URL: https://issues.jboss.org/browse/WFCORE-4525
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Richard Opalka
> Assignee: James Perkins
> Priority: Major
> Attachments: forked-booter.png, ibm-jdk8.png, oracle-jdk.png
>
>
> The following tests are failing on latest IBM JDK 8:
> ---
> # testsuite/standalone
> SilentModeTestCase
> # testsuite/manualmode
> CLIEmbedHostControllerTestCase
> CLIEmbedServerTestCase
> ---
> Tested on:
> ---
> java version "1.8.0_211"
> Java(TM) SE Runtime Environment (build 8.0.5.36 - pxa6480sr5fp36-20190510_01(SR5 FP36))
> IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20190502_415899 (JIT enabled, AOT enabled)
> OpenJ9 - 46e57f9
> OMR - 06a046a
> IBM - 0b909bf)
> JCL - 20190409_01 based on Oracle jdk8u211-b25
> ---
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (WFCORE-4525) Fix failing tests on IBM JDK
by Richard Opalka (Jira)
[ https://issues.jboss.org/browse/WFCORE-4525?page=com.atlassian.jira.plugi... ]
Richard Opalka edited comment on WFCORE-4525 at 7/31/19 6:54 AM:
-----------------------------------------------------------------
SilentModeTestCase started to pass in IBM JDK [~jamezp].
You meant that both
* CLIEmbedHostControllerTestCase
* CLIEmbedServerTestCase
should be annotated with @Ignore if IBM JDK is detected?
was (Author: ropalka):
SilentModeTestCase started to pass in IBM JDK [~jamezp].
You meant that both
* CLIEmbedHostControllerTestCase
* CLIEmbedServerTestCase
should be annotated with @Ignore if IBM JDK is detected?
> Fix failing tests on IBM JDK
> ----------------------------
>
> Key: WFCORE-4525
> URL: https://issues.jboss.org/browse/WFCORE-4525
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Richard Opalka
> Assignee: James Perkins
> Priority: Major
> Attachments: forked-booter.png, ibm-jdk8.png, oracle-jdk.png
>
>
> The following tests are failing on latest IBM JDK 8:
> ---
> # testsuite/standalone
> SilentModeTestCase
> # testsuite/manualmode
> CLIEmbedHostControllerTestCase
> CLIEmbedServerTestCase
> ---
> Tested on:
> ---
> java version "1.8.0_211"
> Java(TM) SE Runtime Environment (build 8.0.5.36 - pxa6480sr5fp36-20190510_01(SR5 FP36))
> IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20190502_415899 (JIT enabled, AOT enabled)
> OpenJ9 - 46e57f9
> OMR - 06a046a
> IBM - 0b909bf)
> JCL - 20190409_01 based on Oracle jdk8u211-b25
> ---
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (JGRP-2364) simply lock and unlock JGroups lock repeatedly will create chaos
by Yong Deng (Jira)
[ https://issues.jboss.org/browse/JGRP-2364?page=com.atlassian.jira.plugin.... ]
Yong Deng commented on JGRP-2364:
---------------------------------
Following is the temporary fix on my side in org.jgroups.protocols.Locking.ClientLock#_unlock. I add 10 seconds timeout in order not to hang when we hit other JGroups bugs and RELEASE_LOCK_OK is not sent back ever.
{code:java}
protected synchronized void _unlock(boolean force) {
if(!acquired && !denied && !force)
return;
this.timeout=0;
this.is_trylock=false;
if (!denied) {
if (!force)
addToPendingReleaseRequests(this);
sendReleaseLockRequest(name, lock_id, owner);// lock will be released on RELEASE_LOCK_OK response
if (force && removeClientLock(name, owner))
notifyLockDeleted(name);
if (!force) {
//unlock will return only when get RELEASE_LOCK_OK or timeLeft after some seconds
long timeLeft = 10000;
while (acquired || denied) {
long start = System.currentTimeMillis();
try {
wait(timeLeft);
} catch (InterruptedException ie) {
break;
}
long duration = System.currentTimeMillis() - start;
if (duration > 0)
timeLeft -= duration;
if (timeLeft <= 0) {
if (log.isWarnEnabled()) {
log.warn(format("[%s]: timeout wait for RELEASE_LOCK_OK response for lock=%s", local_addr, this));
}
//defensive fix
acquired = denied = false;
break;
}
}
}
}
else
_unlockOK();
}
{code}
> simply lock and unlock JGroups lock repeatedly will create chaos
> ----------------------------------------------------------------
>
> Key: JGRP-2364
> URL: https://issues.jboss.org/browse/JGRP-2364
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.1
> Environment: JDK: 1.8
> JGroups: 4.1.1
> Lock: CENTRAL_LOCK
> Reporter: Yong Deng
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.2
>
> Attachments: LockSimpleTest.java
>
>
> I have one simple use case to reproduce the issue. In same thread, just lock/unlock the lock repeatedly. Turn the log level to TRACE, you will find the communication chaos between the client and the coordinate. *JGroups unlock will return immediately after sending out RELEASE_LOCK currently. Why unlock don’t wait and only return after receiving the RELEASE_LOCK_OK response?*
> * Current log:
> {code:java}
> 16:56:40,399 TRACE [CENTRAL_LOCK] A --> A: GRANT_LOCK[sample-lock, lock_id=1, owner=A::31, trylock, timeout=10000]
> 16:56:40,404 TRACE [CENTRAL_LOCK] A <-- A: GRANT_LOCK[sample-lock, lock_id=1, owner=A::31, trylock, timeout=10000, sender=A]
> 16:56:40,410 TRACE [CENTRAL_LOCK] A --> A: LOCK_GRANTED[sample-lock, lock_id=1, owner=A::31]
> 16:56:40,411 TRACE [CENTRAL_LOCK] A <-- A: LOCK_GRANTED[sample-lock, lock_id=1, owner=A::31, sender=A]
> 16:56:40,413 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31]
> 16:56:40,414 TRACE [CENTRAL_LOCK] A <-- A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31, sender=A]
> 16:56:40,414 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31]
> 16:56:40,415 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK_OK[sample-lock, lock_id=1, owner=A::31]
> 16:56:40,415 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31]
> {code}
> * The expected log:
> {code:java}
> 2019-07-24 17:01:52,849 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] GRANT_LOCK [sample-lock, lock_id=1, owner=A::63, trylock (timeout=10000)
> 2019-07-24 17:01:52,849 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] GRANT_LOCK [sample-lock, lock_id=1, owner=A::63, trylock (timeout=10000)
> 2019-07-24 17:01:52,852 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] LOCK_GRANTED [sample-lock, lock_id=1, owner=A::63 ]
> 2019-07-24 17:01:52,852 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] LOCK_GRANTED [sample-lock, lock_id=1, owner=A::63 ]
> 2019-07-24 17:01:52,853 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] RELEASE_LOCK [sample-lock, lock_id=1, owner=A::63 ]
> 2019-07-24 17:01:52,853 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] RELEASE_LOCK [sample-lock, lock_id=1, owner=A::63 ]
> 2019-07-24 17:01:52,853 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] RELEASE_LOCK_OK [sample-lock, lock_id=1, owner=A::63 ]
> 2019-07-24 17:01:52,854 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] RELEASE_LOCK_OK [sample-lock, lock_id=1, owner=A::63 ]
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (WFLY-12337) Wildfly Transaction REQUIRES_NEW not working
by Thomas Jenkinson (Jira)
[ https://issues.jboss.org/browse/WFLY-12337?page=com.atlassian.jira.plugin... ]
Thomas Jenkinson commented on WFLY-12337:
-----------------------------------------
[~maeste]do you have any ideas what this could be about? I think the TransactionDefinition is a Spring thing: https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/spri...
[~hchen00] This might be better as a discussion on the wildfly space - if you do create a topic feel free to ping Stefano and myself on the topic
> Wildfly Transaction REQUIRES_NEW not working
> --------------------------------------------
>
> Key: WFLY-12337
> URL: https://issues.jboss.org/browse/WFLY-12337
> Project: WildFly
> Issue Type: Bug
> Components: JCA, Transactions
> Affects Versions: 16.0.0.Final
> Reporter: Hao Chen
> Assignee: Thomas Jenkinson
> Priority: Major
>
> We recently upgraded from jboss-eap-6.4 to Wildfly 16. Most things worked fine until we find one issue in the case that a method that is called using TransactionTemplate with TransactionDefinition.PROPAGATION_REQUIRES_NEW is not working...
> The case is that: we use this PROPAGATION_REQUIRES_NEW transaction to commit a log of login failure, while the main transaction is rolled back due login exception.
> This used to work without problem in jboss-eap-6.4 though we were seeing warnings like:
> Trying to change transaction TransactionImple < ac, BasicAction: 0:ffff0a004b01:513406f2:5d37ce0b:2a0 status: ActionStatus.RUNNING > in enlist!
> But in Wildfly 16 PROPAGATION_REQUIRES_NEW doesn't work any more -- the new transaction seems to rolled back together with the main transaction. After spending quite some time debugging into the Wildfly/Jboss code, I found that in org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.enlist method, there is a new line:
> if (isEnlisted() || getState().equals(ConnectionState.DESTROY) || getState().equals(ConnectionState.DESTROYED))
> return;
> And in our case, the TxConnectionListener object is the same in the new transaction as in the old transaction, so it's already marked as "enlisted". And therefore the rest of enlist is never executed for the new transaction, so Wildfly never issued a "XA Start" command for the new transaction.
> So the question is: is the added isEnlisted() check a bug introduced or there is something wrong we did to configure Wildfly and/or Spring? How should the REUIRES_NEW case work?
> Here is a trace except I captured:
> TransactionTemplate.execute(TransactionCallback<T>) line: 130 JtaTransactionManager(AbstractPlatformTransactionManager).getTransaction(TransactionDefinition) line: 353 JtaTransactionManager(AbstractPlatformTransactionManager).handleExistingTransaction(TransactionDefinition, Object, boolean) line: 433
> JtaTransactionManager.doBegin(Object, TransactionDefinition) line: 831
> JtaTransactionManager.doJtaBegin(JtaTransactionObject, TransactionDefinition) line: 872
> LocalUserTransaction.begin() line: 48
> ContextTransactionManager.begin(CreationListener$CreatedBy) line: 62
> LocalTransactionContext.beginTransaction(int, boolean, CreationListener$CreatedBy) line: 188 JBossJTALocalTransactionProvider(JBossLocalTransactionProvider).createNewTransaction(int)
> ...
> ContextTransactionManager.resume(AbstractTransaction) line: 158
> LocalTransaction.resume() line: 248
> TransactionManagerDelegate(BaseTransactionManagerDelegate).resume(Transaction) line: 122
> TransactionManagerImple.resume(Transaction) line: 111
> AtomicAction.resume(AtomicAction) line: 361
> LocalTransaction(AbstractTransaction).notifyAssociationListeners(boolean) line: 115
> TransactionManagerService$2.associationChanged(AbstractTransaction, boolean) line: 97
> UserTransactionRegistry.userTransactionStarted() line: 119
> UserTransactionListenerImpl.userTransactionStarted() line: 52
> CachedConnectionManagerImpl.userTransactionStarted() line: 249
> TxConnectionManagerImpl.transactionStarted(Collection<ConnectionRecord>) line: 460
> TxConnectionListener.enlist() line: 264
> !-- changed in ironjacamar-core-impl-1.2
> // If we are already enlisted there is no reason to check again, as this method
> // could be called multiple times during a transaction lifecycle.
> // We know that we can only be inside this method if we are allowed to
> if (isEnlisted() || getState().equals(ConnectionState.DESTROY) || getState().equals(ConnectionState.DESTROYED))
> return;
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (WFLY-12337) Wildfly Transaction REQUIRES_NEW not working
by Thomas Jenkinson (Jira)
[ https://issues.jboss.org/browse/WFLY-12337?page=com.atlassian.jira.plugin... ]
Thomas Jenkinson edited comment on WFLY-12337 at 7/31/19 6:39 AM:
------------------------------------------------------------------
[~maeste]do you have any ideas what this could be about? I think the TransactionDefinition is a Spring thing: https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/spri...
[~hchen00] This might be better as a discussion on the wildfly space - if you do create a topic feel free to ping Stefano and myself on the topic https://developer.jboss.org/en/wildfly
was (Author: tomjenkinson):
[~maeste]do you have any ideas what this could be about? I think the TransactionDefinition is a Spring thing: https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/spri...
[~hchen00] This might be better as a discussion on the wildfly space - if you do create a topic feel free to ping Stefano and myself on the topic
> Wildfly Transaction REQUIRES_NEW not working
> --------------------------------------------
>
> Key: WFLY-12337
> URL: https://issues.jboss.org/browse/WFLY-12337
> Project: WildFly
> Issue Type: Bug
> Components: JCA, Transactions
> Affects Versions: 16.0.0.Final
> Reporter: Hao Chen
> Assignee: Thomas Jenkinson
> Priority: Major
>
> We recently upgraded from jboss-eap-6.4 to Wildfly 16. Most things worked fine until we find one issue in the case that a method that is called using TransactionTemplate with TransactionDefinition.PROPAGATION_REQUIRES_NEW is not working...
> The case is that: we use this PROPAGATION_REQUIRES_NEW transaction to commit a log of login failure, while the main transaction is rolled back due login exception.
> This used to work without problem in jboss-eap-6.4 though we were seeing warnings like:
> Trying to change transaction TransactionImple < ac, BasicAction: 0:ffff0a004b01:513406f2:5d37ce0b:2a0 status: ActionStatus.RUNNING > in enlist!
> But in Wildfly 16 PROPAGATION_REQUIRES_NEW doesn't work any more -- the new transaction seems to rolled back together with the main transaction. After spending quite some time debugging into the Wildfly/Jboss code, I found that in org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.enlist method, there is a new line:
> if (isEnlisted() || getState().equals(ConnectionState.DESTROY) || getState().equals(ConnectionState.DESTROYED))
> return;
> And in our case, the TxConnectionListener object is the same in the new transaction as in the old transaction, so it's already marked as "enlisted". And therefore the rest of enlist is never executed for the new transaction, so Wildfly never issued a "XA Start" command for the new transaction.
> So the question is: is the added isEnlisted() check a bug introduced or there is something wrong we did to configure Wildfly and/or Spring? How should the REUIRES_NEW case work?
> Here is a trace except I captured:
> TransactionTemplate.execute(TransactionCallback<T>) line: 130 JtaTransactionManager(AbstractPlatformTransactionManager).getTransaction(TransactionDefinition) line: 353 JtaTransactionManager(AbstractPlatformTransactionManager).handleExistingTransaction(TransactionDefinition, Object, boolean) line: 433
> JtaTransactionManager.doBegin(Object, TransactionDefinition) line: 831
> JtaTransactionManager.doJtaBegin(JtaTransactionObject, TransactionDefinition) line: 872
> LocalUserTransaction.begin() line: 48
> ContextTransactionManager.begin(CreationListener$CreatedBy) line: 62
> LocalTransactionContext.beginTransaction(int, boolean, CreationListener$CreatedBy) line: 188 JBossJTALocalTransactionProvider(JBossLocalTransactionProvider).createNewTransaction(int)
> ...
> ContextTransactionManager.resume(AbstractTransaction) line: 158
> LocalTransaction.resume() line: 248
> TransactionManagerDelegate(BaseTransactionManagerDelegate).resume(Transaction) line: 122
> TransactionManagerImple.resume(Transaction) line: 111
> AtomicAction.resume(AtomicAction) line: 361
> LocalTransaction(AbstractTransaction).notifyAssociationListeners(boolean) line: 115
> TransactionManagerService$2.associationChanged(AbstractTransaction, boolean) line: 97
> UserTransactionRegistry.userTransactionStarted() line: 119
> UserTransactionListenerImpl.userTransactionStarted() line: 52
> CachedConnectionManagerImpl.userTransactionStarted() line: 249
> TxConnectionManagerImpl.transactionStarted(Collection<ConnectionRecord>) line: 460
> TxConnectionListener.enlist() line: 264
> !-- changed in ironjacamar-core-impl-1.2
> // If we are already enlisted there is no reason to check again, as this method
> // could be called multiple times during a transaction lifecycle.
> // We know that we can only be inside this method if we are allowed to
> if (isEnlisted() || getState().equals(ConnectionState.DESTROY) || getState().equals(ConnectionState.DESTROYED))
> return;
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (WFLY-12337) Wildfly Transaction REQUIRES_NEW not working
by Thomas Jenkinson (Jira)
[ https://issues.jboss.org/browse/WFLY-12337?page=com.atlassian.jira.plugin... ]
Thomas Jenkinson updated WFLY-12337:
------------------------------------
Component/s: JCA
> Wildfly Transaction REQUIRES_NEW not working
> --------------------------------------------
>
> Key: WFLY-12337
> URL: https://issues.jboss.org/browse/WFLY-12337
> Project: WildFly
> Issue Type: Bug
> Components: JCA, Transactions
> Affects Versions: 16.0.0.Final
> Reporter: Hao Chen
> Assignee: Thomas Jenkinson
> Priority: Major
>
> We recently upgraded from jboss-eap-6.4 to Wildfly 16. Most things worked fine until we find one issue in the case that a method that is called using TransactionTemplate with TransactionDefinition.PROPAGATION_REQUIRES_NEW is not working...
> The case is that: we use this PROPAGATION_REQUIRES_NEW transaction to commit a log of login failure, while the main transaction is rolled back due login exception.
> This used to work without problem in jboss-eap-6.4 though we were seeing warnings like:
> Trying to change transaction TransactionImple < ac, BasicAction: 0:ffff0a004b01:513406f2:5d37ce0b:2a0 status: ActionStatus.RUNNING > in enlist!
> But in Wildfly 16 PROPAGATION_REQUIRES_NEW doesn't work any more -- the new transaction seems to rolled back together with the main transaction. After spending quite some time debugging into the Wildfly/Jboss code, I found that in org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.enlist method, there is a new line:
> if (isEnlisted() || getState().equals(ConnectionState.DESTROY) || getState().equals(ConnectionState.DESTROYED))
> return;
> And in our case, the TxConnectionListener object is the same in the new transaction as in the old transaction, so it's already marked as "enlisted". And therefore the rest of enlist is never executed for the new transaction, so Wildfly never issued a "XA Start" command for the new transaction.
> So the question is: is the added isEnlisted() check a bug introduced or there is something wrong we did to configure Wildfly and/or Spring? How should the REUIRES_NEW case work?
> Here is a trace except I captured:
> TransactionTemplate.execute(TransactionCallback<T>) line: 130 JtaTransactionManager(AbstractPlatformTransactionManager).getTransaction(TransactionDefinition) line: 353 JtaTransactionManager(AbstractPlatformTransactionManager).handleExistingTransaction(TransactionDefinition, Object, boolean) line: 433
> JtaTransactionManager.doBegin(Object, TransactionDefinition) line: 831
> JtaTransactionManager.doJtaBegin(JtaTransactionObject, TransactionDefinition) line: 872
> LocalUserTransaction.begin() line: 48
> ContextTransactionManager.begin(CreationListener$CreatedBy) line: 62
> LocalTransactionContext.beginTransaction(int, boolean, CreationListener$CreatedBy) line: 188 JBossJTALocalTransactionProvider(JBossLocalTransactionProvider).createNewTransaction(int)
> ...
> ContextTransactionManager.resume(AbstractTransaction) line: 158
> LocalTransaction.resume() line: 248
> TransactionManagerDelegate(BaseTransactionManagerDelegate).resume(Transaction) line: 122
> TransactionManagerImple.resume(Transaction) line: 111
> AtomicAction.resume(AtomicAction) line: 361
> LocalTransaction(AbstractTransaction).notifyAssociationListeners(boolean) line: 115
> TransactionManagerService$2.associationChanged(AbstractTransaction, boolean) line: 97
> UserTransactionRegistry.userTransactionStarted() line: 119
> UserTransactionListenerImpl.userTransactionStarted() line: 52
> CachedConnectionManagerImpl.userTransactionStarted() line: 249
> TxConnectionManagerImpl.transactionStarted(Collection<ConnectionRecord>) line: 460
> TxConnectionListener.enlist() line: 264
> !-- changed in ironjacamar-core-impl-1.2
> // If we are already enlisted there is no reason to check again, as this method
> // could be called multiple times during a transaction lifecycle.
> // We know that we can only be inside this method if we are allowed to
> if (isEnlisted() || getState().equals(ConnectionState.DESTROY) || getState().equals(ConnectionState.DESTROYED))
> return;
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (WFLY-12337) Wildfly Transaction REQUIRES_NEW not working
by Hao Chen (Jira)
Hao Chen created WFLY-12337:
-------------------------------
Summary: Wildfly Transaction REQUIRES_NEW not working
Key: WFLY-12337
URL: https://issues.jboss.org/browse/WFLY-12337
Project: WildFly
Issue Type: Bug
Components: Transactions
Affects Versions: 16.0.0.Final
Reporter: Hao Chen
Assignee: Thomas Jenkinson
We recently upgraded from jboss-eap-6.4 to Wildfly 16. Most things worked fine until we find one issue in the case that a method that is called using TransactionTemplate with TransactionDefinition.PROPAGATION_REQUIRES_NEW is not working...
The case is that: we use this PROPAGATION_REQUIRES_NEW transaction to commit a log of login failure, while the main transaction is rolled back due login exception.
This used to work without problem in jboss-eap-6.4 though we were seeing warnings like:
Trying to change transaction TransactionImple < ac, BasicAction: 0:ffff0a004b01:513406f2:5d37ce0b:2a0 status: ActionStatus.RUNNING > in enlist!
But in Wildfly 16 PROPAGATION_REQUIRES_NEW doesn't work any more -- the new transaction seems to rolled back together with the main transaction. After spending quite some time debugging into the Wildfly/Jboss code, I found that in org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.enlist method, there is a new line:
if (isEnlisted() || getState().equals(ConnectionState.DESTROY) || getState().equals(ConnectionState.DESTROYED))
return;
And in our case, the TxConnectionListener object is the same in the new transaction as in the old transaction, so it's already marked as "enlisted". And therefore the rest of enlist is never executed for the new transaction, so Wildfly never issued a "XA Start" command for the new transaction.
So the question is: is the added isEnlisted() check a bug introduced or there is something wrong we did to configure Wildfly and/or Spring? How should the REUIRES_NEW case work?
Here is a trace except I captured:
TransactionTemplate.execute(TransactionCallback<T>) line: 130 JtaTransactionManager(AbstractPlatformTransactionManager).getTransaction(TransactionDefinition) line: 353 JtaTransactionManager(AbstractPlatformTransactionManager).handleExistingTransaction(TransactionDefinition, Object, boolean) line: 433
JtaTransactionManager.doBegin(Object, TransactionDefinition) line: 831
JtaTransactionManager.doJtaBegin(JtaTransactionObject, TransactionDefinition) line: 872
LocalUserTransaction.begin() line: 48
ContextTransactionManager.begin(CreationListener$CreatedBy) line: 62
LocalTransactionContext.beginTransaction(int, boolean, CreationListener$CreatedBy) line: 188 JBossJTALocalTransactionProvider(JBossLocalTransactionProvider).createNewTransaction(int)
...
ContextTransactionManager.resume(AbstractTransaction) line: 158
LocalTransaction.resume() line: 248
TransactionManagerDelegate(BaseTransactionManagerDelegate).resume(Transaction) line: 122
TransactionManagerImple.resume(Transaction) line: 111
AtomicAction.resume(AtomicAction) line: 361
LocalTransaction(AbstractTransaction).notifyAssociationListeners(boolean) line: 115
TransactionManagerService$2.associationChanged(AbstractTransaction, boolean) line: 97
UserTransactionRegistry.userTransactionStarted() line: 119
UserTransactionListenerImpl.userTransactionStarted() line: 52
CachedConnectionManagerImpl.userTransactionStarted() line: 249
TxConnectionManagerImpl.transactionStarted(Collection<ConnectionRecord>) line: 460
TxConnectionListener.enlist() line: 264
!-- changed in ironjacamar-core-impl-1.2
// If we are already enlisted there is no reason to check again, as this method
// could be called multiple times during a transaction lifecycle.
// We know that we can only be inside this method if we are allowed to
if (isEnlisted() || getState().equals(ConnectionState.DESTROY) || getState().equals(ConnectionState.DESTROYED))
return;
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months
[JBoss JIRA] (WFCORE-4532) Investigate new JDK 13 regressions
by Richard Opalka (Jira)
[ https://issues.jboss.org/browse/WFCORE-4532?page=com.atlassian.jira.plugi... ]
Richard Opalka reassigned WFCORE-4532:
--------------------------------------
Assignee: Richard Opalka
> Investigate new JDK 13 regressions
> ----------------------------------
>
> Key: WFCORE-4532
> URL: https://issues.jboss.org/browse/WFCORE-4532
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Reporter: Richard Opalka
> Assignee: Richard Opalka
> Priority: Critical
> Labels: jdk13
>
> Latest Open JDK 13 Early Access 25 introduced six new regressions in our test suites.
> Failing tests in WILDFLY-CORE are:
> * wildfly-core/elytron/src/test/java/org/wildfly/extension/elytron/TlsTestCase.java
> * wildfly-core/testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/sasl/mgmt/KerberosHttpMgmtSaslTestCase.java
> * wildfly-core/testsuite/elytron/src/test/java/org/wildfly/test/integration/elytron/sasl/mgmt/KerberosNativeMgmtSaslTestCase.java
> Failing tests in WILDFLY are:
> * wildfly/testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/web/ssl/CertificateRolesLoginModuleTestCase.java
> * wildfly/testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/web/ssl/DatabaseCertLoginModuleTestCase.java
> * wildfly/testsuite/integration/manualmode/src/test/java/org/jboss/as/test/manualmode/web/ssl/HTTPSWebConnectorTestCase.java
> Could somebody from our security team have a look what is going on [~darran] ?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 2 months