[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, 4 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, 4 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, 4 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 commented on WFCORE-4532:
----------------------------------------
Related issue https://bugs.openjdk.java.net/browse/JDK-8228396
> 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, 4 months
[JBoss JIRA] (DROOLS-2602) Download link for particular KIE Execution Server war instead of zip with wars for all containers
by Michael Biarnes Kiefer (Jira)
[ https://issues.jboss.org/browse/DROOLS-2602?page=com.atlassian.jira.plugi... ]
Michael Biarnes Kiefer closed DROOLS-2602.
------------------------------------------
Resolution: Done
> Download link for particular KIE Execution Server war instead of zip with wars for all containers
> -------------------------------------------------------------------------------------------------
>
> Key: DROOLS-2602
> URL: https://issues.jboss.org/browse/DROOLS-2602
> Project: Drools
> Issue Type: Feature Request
> Components: kie server
> Affects Versions: 7.7.0.Final
> Reporter: Igor Azarny
> Assignee: Michael Biarnes Kiefer
> Priority: Optional
> Labels: distribution
>
> Could you please provide the download link for particular KIE Execution Server war instead of zip with wars for all containers?
> Reason - need to create buildpack with kie server for pivotal cloud foundry on CI env. So I need just kie-server-7.7.0.Final-webc.war instead of kie-server-distribution-7.7.0.Final.zip
> Thanks, Igor
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months
[JBoss JIRA] (JGRP-2357) ConnectException error messages when using TCP protocol
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2357?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2357.
----------------------------
Resolution: Done
> ConnectException error messages when using TCP protocol
> -------------------------------------------------------
>
> Key: JGRP-2357
> URL: https://issues.jboss.org/browse/JGRP-2357
> Project: JGroups
> Issue Type: Bug
> Reporter: Dante Wang
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.2
>
>
> When using TCP protocol with JGroups 4.1.1 Final, various kinds of java.net.ConnectException error messages occasionally appear in the log. These exception log messages were by default suppressed with logging level "TRACE" before JGRP-2332 (commit 538a5431b8fd06d644a72f48d584f8114f26a295).
> The ConnectExceptions in this case happen upon attempts to discover nodes, verify node status when another node dies and send ACK when another node leaves.
> The ConnectException messages of node discovery can be avoided by carefully changing configuration of TCPPING or using other ping like JDBC_PING. But the two kinds of messages upon node exiting seem to have no way to avoid.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months
[JBoss JIRA] (JGRP-2357) ConnectException error messages when using TCP protocol
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2357?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2357:
--------------------------------
The problem is that the bundler which sends messages runs on a separate thread; I cannot just catch exceptions in TCPPING that are caused by non-existant members.
Hmm, I changed the ERROR log message back to TRACE. OTOH, this prevents people from seeing real (serious) errors, ie. caused by misconfiguration. In this case, they have to enable TRACE level logging for the transport.
> ConnectException error messages when using TCP protocol
> -------------------------------------------------------
>
> Key: JGRP-2357
> URL: https://issues.jboss.org/browse/JGRP-2357
> Project: JGroups
> Issue Type: Bug
> Reporter: Dante Wang
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.2
>
>
> When using TCP protocol with JGroups 4.1.1 Final, various kinds of java.net.ConnectException error messages occasionally appear in the log. These exception log messages were by default suppressed with logging level "TRACE" before JGRP-2332 (commit 538a5431b8fd06d644a72f48d584f8114f26a295).
> The ConnectExceptions in this case happen upon attempts to discover nodes, verify node status when another node dies and send ACK when another node leaves.
> The ConnectException messages of node discovery can be avoided by carefully changing configuration of TCPPING or using other ping like JDBC_PING. But the two kinds of messages upon node exiting seem to have no way to avoid.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months
[JBoss JIRA] (JGRP-2357) ConnectException error messages when using TCP protocol
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2357?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2357:
---------------------------
Fix Version/s: 4.1.2
> ConnectException error messages when using TCP protocol
> -------------------------------------------------------
>
> Key: JGRP-2357
> URL: https://issues.jboss.org/browse/JGRP-2357
> Project: JGroups
> Issue Type: Bug
> Reporter: Dante Wang
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.2
>
>
> When using TCP protocol with JGroups 4.1.1 Final, various kinds of java.net.ConnectException error messages occasionally appear in the log. These exception log messages were by default suppressed with logging level "TRACE" before JGRP-2332 (commit 538a5431b8fd06d644a72f48d584f8114f26a295).
> The ConnectExceptions in this case happen upon attempts to discover nodes, verify node status when another node dies and send ACK when another node leaves.
> The ConnectException messages of node discovery can be avoided by carefully changing configuration of TCPPING or using other ping like JDBC_PING. But the two kinds of messages upon node exiting seem to have no way to avoid.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months