[JBoss JIRA] (WFLY-9854) jgroups-channel cannot use name which is already used by jgroups/stacks
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-9854?page=com.atlassian.jira.plugin.... ]
Jason Greene commented on WFLY-9854:
------------------------------------
Just responding to the ask, that I agree its not a compatibility concern. Anything that was previously invalid but did not generate an error may generate an error in the future. In some cases we can try to be nice and be liberal in what we accept, but thats not always practical.
> jgroups-channel cannot use name which is already used by jgroups/stacks
> -----------------------------------------------------------------------
>
> Key: WFLY-9854
> URL: https://issues.jboss.org/browse/WFLY-9854
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, JMS
> Affects Versions: 12.0.0.Beta1
> Reporter: Erich Duda
> Assignee: Paul Ferraro
> Priority: Blocker
>
> The configuration \[1\] results to an error \[2\]. This is backward compatibility issue since the configuration works with previous releases of Wildfly.
> \[1\]
> {code:xml}
> <broadcast-group name="bg-group1" jgroups-stack="udp" jgroups-channel="udp" broadcast-period="2000" connectors="connector"/>
> {code}
> \[2\]
> {code}
> 10:52:29,982 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 15) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "jgroups"),
> ("channel" => "udp")
> ]) - failure description: "WFLYCTL0436: Cannot register capability 'org.wildfly.clustering.jgroups.channel-factory.udp' at location '[
> (\"subsystem\" => \"jgroups\"),
> (\"channel\" => \"udp\")
> ]' as it is already registered in context 'global' at location(s) '[[
> (\"subsystem\" => \"jgroups\"),
> (\"stack\" => \"udp\")
> ]]'"
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (ELY-1526) Update the default provider supplier to be an aggregate of the WildFlyElytronProvider plus the installed providers in order to ensure the WildFlyElytronProvider comes first
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/ELY-1526?page=com.atlassian.jira.plugin.s... ]
Farah Juma updated ELY-1526:
----------------------------
Description:
As Martin Choma [mentioned|https://issues.jboss.org/browse/WFLY-9899?focusedCommentId=1353...] on WFLY-9899, the security providers are being loaded in a different order on JDK 8 vs JDK 9. With JDK 9, the WildFlyElytronProvider is no longer at the beginning of the providers array as it is with JDK 8. With JDK 9, the providers array also contains duplicate providers - they're being added once from the service loader and once from the installed providers.
Update the default provider supplier to be an aggregate of:
# WildFlyElytronProvider
# The security providers loaded using the service loader mechanism ensuring that any provider that is already an installed provider is skipped
# The installed providers
For WildFly 13, we can look at enhancing this by introducing a security provider selector mechanism. This is tracked in ELY-1530.
was:As Martin Choma [mentioned|https://issues.jboss.org/browse/WFLY-9899?focusedCommentId=1353...] on WFLY-9899, the security providers are being loaded in a different order on JDK 8 vs JDK 9. With JDK 9, the WildFlyElytronProvider is no longer at the beginning of the providers array as it is with JDK 8. With JDK 9, the providers array also contains duplicate providers - they're being added once from the service loader and once from the installed providers. As discussed with David Lloyd, the best way to fix this is likely to just have the default supplier be an aggregate of the WildFlyElytronProvider plus the installed providers and drop the service loader part.
> Update the default provider supplier to be an aggregate of the WildFlyElytronProvider plus the installed providers in order to ensure the WildFlyElytronProvider comes first
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1526
> URL: https://issues.jboss.org/browse/ELY-1526
> Project: WildFly Elytron
> Issue Type: Task
> Components: Authentication Client
> Reporter: Farah Juma
> Assignee: Farah Juma
> Fix For: 1.2.2.Final
>
>
> As Martin Choma [mentioned|https://issues.jboss.org/browse/WFLY-9899?focusedCommentId=1353...] on WFLY-9899, the security providers are being loaded in a different order on JDK 8 vs JDK 9. With JDK 9, the WildFlyElytronProvider is no longer at the beginning of the providers array as it is with JDK 8. With JDK 9, the providers array also contains duplicate providers - they're being added once from the service loader and once from the installed providers.
> Update the default provider supplier to be an aggregate of:
> # WildFlyElytronProvider
> # The security providers loaded using the service loader mechanism ensuring that any provider that is already an installed provider is skipped
> # The installed providers
> For WildFly 13, we can look at enhancing this by introducing a security provider selector mechanism. This is tracked in ELY-1530.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (ELY-1530) Introduce a security provider selector mechanism
by Farah Juma (JIRA)
Farah Juma created ELY-1530:
-------------------------------
Summary: Introduce a security provider selector mechanism
Key: ELY-1530
URL: https://issues.jboss.org/browse/ELY-1530
Project: WildFly Elytron
Issue Type: Enhancement
Components: Authentication Client
Reporter: Farah Juma
ELY-1526 updated the default provider supplier to be an aggregate of:
# {{WildFlyElytronProvider}}
# The security providers loaded using the service loader mechanism ensuring that any provider that is already an installed provider is skipped
# The installed providers
This was done to fix a difference in behaviour on JDK 8 vs. JDK 9. In particular, on JDK 9, the security providers were being loaded in a different order, resulting in the WildFlyElytronProvider no longer being loaded first. Some security providers were also being loaded twice - once from the service loader mechanism and once from the installed list of providers.
This task follows up on ELY-1526 to introduce a security provider selector mechanism that allows security providers to be selected and ordered based on certain criteria. David Lloyd mentioned the following idea for this in WFLY-9899:
{quote}
Introduce a security provider selector mechanism that works similarly to the SASL and TLS cipher suite selector mechanisms, which allows providers to be selected and ordered by whatever criteria we can (name, name+version, class name, package name, source module all spring to mind, but there may be more as well including filtering (i.e. allowing only certain service entries of a given provider to "peek through"))
{quote}
See WFLY-9899 for the full discussion.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (JBJCA-1368) JDBC XAManagedConnection.end could loop endlessly when broadcasting error
by Flavia Rainone (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1368?page=com.atlassian.jira.plugin... ]
Flavia Rainone resolved JBJCA-1368.
-----------------------------------
Resolution: Done
> JDBC XAManagedConnection.end could loop endlessly when broadcasting error
> -------------------------------------------------------------------------
>
> Key: JBJCA-1368
> URL: https://issues.jboss.org/browse/JBJCA-1368
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Reporter: Flavia Rainone
> Assignee: Flavia Rainone
>
> If a connection.end operation broadcasts an error for a XA JDBC connection, it could loop endlessly:
> 09/01/2018 14:43:16,805 WARN [com.arjuna.ats.jta] (http task-73) ARJUNA016056: TransactionImple.delistResource - caught exception during delist : XAException.XAER_RMFAIL: oracle.jdbc.xa.OracleXAException
> at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1110)
> at oracle.jdbc.xa.client.OracleXAResource.end(OracleXAResource.java:436)
> at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.end(XAManagedConnection.java:295)
> at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.end(XAResourceWrapperImpl.java:118)
> at org.jboss.jca.core.tx.jbossts.XAResourceWrapperStatImpl.end(XAResourceWrapperStatImpl.java:96)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.delistResource(TransactionImple.java:914)
> at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.haltCatchFire(TxConnectionListener.java:768)
> at org.jboss.jca.core.connectionmanager.listener.AbstractConnectionListener.connectionErrorOccurred(AbstractConnectionListener.java:468)
> at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.broadcastConnectionError(BaseWrapperManagedConnection.java:673)
> at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.end(XAManagedConnection.java:301)
> at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.end(XAResourceWrapperImpl.java:118)
> at org.jboss.jca.core.tx.jbossts.XAResourceWrapperStatImpl.end(XAResourceWrapperStatImpl.java:96)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.delistResource(TransactionImple.java:914)
> at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.haltCatchFire(TxConnectionListener.java:768)
> at org.jboss.jca.core.connectionmanager.listener.AbstractConnectionListener.connectionErrorOccurred(AbstractConnectionListener.java:468)
> at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.broadcastConnectionError(BaseWrapperManagedConnection.java:673)
> ....
> REPEAT ENDLESSLY
> ....
> at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.end(XAManagedConnection.java:301)
> at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.end(XAResourceWrapperImpl.java:118)
> at org.jboss.jca.core.tx.jbossts.XAResourceWrapperStatImpl.end(XAResourceWrapperStatImpl.java:96)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.delistResource(TransactionImple.java:914)
> at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.haltCatchFire(TxConnectionListener.java:768)
> at org.jboss.jca.core.connectionmanager.listener.AbstractConnectionListener.connectionErrorOccurred(AbstractConnectionListener.java:468)
> at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.broadcastConnectionError(BaseWrapperManagedConnection.java:673)
> at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.end(XAManagedConnection.java:301)
> at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.end(XAResourceWrapperImpl.java:118)
> at org.jboss.jca.core.tx.jbossts.XAResourceWrapperStatImpl.end(XAResourceWrapperStatImpl.java:96)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.delistResource(TransactionImple.java:914)
> at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.haltCatchFire(TxConnectionListener.java:768)
> at org.jboss.jca.core.connectionmanager.listener.AbstractConnectionListener.connectionErrorOccurred(AbstractConnectionListener.java:468)
> at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.broadcastConnectionError(BaseWrapperManagedConnection.java:673)
> at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.end(XAManagedConnection.java:301)
> at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.end(XAResourceWrapperImpl.java:118)
> at org.jboss.jca.core.tx.jbossts.XAResourceWrapperStatImpl.end(XAResourceWrapperStatImpl.java:96)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.delistResource(TransactionImple.java:914)
> at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.haltCatchFire(TxConnectionListener.java:768)
> at org.jboss.jca.core.connectionmanager.listener.AbstractConnectionListener.connectionErrorOccurred(AbstractConnectionListener.java:468)
> at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.broadcastConnectionError(BaseWrapperManagedConnection.java:673)
> at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.end(XAManagedConnection.java:301)
> at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.end(XAResourceWrapperImpl.java:118)
> at org.jboss.jca.core.tx.jbossts.XAResourceWrapperStatImpl.end(XAResourceWrapperStatImpl.java:96)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.delistResource(TransactionImple.java:914)
> at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.haltCatchFire(TxConnectionListener.java:768)
> at org.jboss.jca.core.connectionmanager.listener.AbstractConnectionListener.connectionErrorOccurred(AbstractConnectionListener.java:468)
> at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.broadcastConnectionError(BaseWrapperManagedConnection.java:673)
> As a result, the reentrant lock/unlock system gets out of hand the lock in the connection is not entirely unlocked.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (JBJCA-1356) BaseWrapperManagedConnection.unlock fails to unlock
by Flavia Rainone (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1356?page=com.atlassian.jira.plugin... ]
Flavia Rainone resolved JBJCA-1356.
-----------------------------------
Fix Version/s: (was: WildFly/IronJacamar 1.4.3.Final)
Resolution: Done
> BaseWrapperManagedConnection.unlock fails to unlock
> ---------------------------------------------------
>
> Key: JBJCA-1356
> URL: https://issues.jboss.org/browse/JBJCA-1356
> Project: IronJacamar
> Issue Type: Bug
> Affects Versions: WildFly/IronJacamar 1.4.2.Final
> Reporter: Flavia Rainone
> Assignee: Flavia Rainone
>
> There is a possibility of unlock missing the call to reentrantLock.unlock:
> {noformat}
> protected void unlock()
> {
> if (tryLock < 0)
> return;
> if (getLog().isTraceEnabled())
> dumpLockInformation(false);
> if (lock.isHeldByCurrentThread())
> lock.unlock();
> }
> {noformat}
> This bug is random.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (JBJCA-1369) SemaphoreConcurrentLinkedDequeManagedConnectionPool.returnConnection throws NPE
by Flavia Rainone (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1369?page=com.atlassian.jira.plugin... ]
Flavia Rainone resolved JBJCA-1369.
-----------------------------------
Resolution: Done
> SemaphoreConcurrentLinkedDequeManagedConnectionPool.returnConnection throws NPE
> -------------------------------------------------------------------------------
>
> Key: JBJCA-1369
> URL: https://issues.jboss.org/browse/JBJCA-1369
> Project: IronJacamar
> Issue Type: Bug
> Reporter: Flavia Rainone
> Assignee: Flavia Rainone
>
> This happens whenever there is no corresponding connection listener wrapper in the cls map.
> Example of the error:
> 05/02/2018 12:45:31,558 ERROR [org.jboss.jca.core.connectionmanager.TxConnectionManager] (http task-74) IJ000406: Throwable in returning connection: org.jboss.jca.adapters.jdbc.xa.XAManagedConnection@75c05dd6: java.lang.NullPointerException
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.returnConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:731)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.returnConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:611)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.returnConnection(AbstractPool.java:849)
> at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.returnManagedConnection(AbstractConnectionManager.java:748)
> at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener$TransactionSynchronization.afterCompletion(TxConnectionListener.java:1155)
> at org.jboss.jca.core.connectionmanager.transaction.TransactionSynchronizer.invokeAfter(TransactionSynchronizer.java:456)
> at org.jboss.jca.core.connectionmanager.transaction.TransactionSynchronizer.afterCompletion(TransactionSynchronizer.java:392)
> at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.afterCompletion(JCAOrderedLastSynchronizationList.java:163)
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:545)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:101)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
> at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:193)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months