[JBoss JIRA] (JBJCA-1371) Deadlock for threads executing org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.isEqual
by Flavia Rainone (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1371?page=com.atlassian.jira.plugin... ]
Flavia Rainone updated JBJCA-1371:
----------------------------------
Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/657
> Deadlock for threads executing org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.isEqual
> ------------------------------------------------------------------------------------------------
>
> Key: JBJCA-1371
> URL: https://issues.jboss.org/browse/JBJCA-1371
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Reporter: Flavia Rainone
> Assignee: Flavia Rainone
>
> Two or more threads hold one lock on an instance of java.util.Collections$SynchronizedMap and attempt to obtain a lock on a different instance (e.g. locks on 0x00000001d0d08bd8 and 0x00000001cea22628 in the example below)
> "thread-one" ...
> java.lang.Thread.State: BLOCKED (on object monitor)
> at java.util.Collections$SynchronizedMap.get(Collections.java:2584)
> - waiting to lock <0x00000001cea22628> (a java.util.Collections$SynchronizedMap)
> at java.util.AbstractMap.equals(AbstractMap.java:495)
> at java.util.Collections$SynchronizedMap.equals(Collections.java:2631)
> - locked <0x00000001d0d08bd8> (a java.util.Collections$SynchronizedMap)
> at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.isEqual(XAManagedConnectionFactory.java:563)
> - locked <0x00000001d0d08bd8> (a java.util.Collections$SynchronizedMap)
> at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.equals(XAManagedConnectionFactory.java:598)
> at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory$SubjectActions.doCheck(BaseWrapperManagedConnectionFactory.java:1397)
> at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory$SubjectActions.addMatchingProperties(BaseWrapperManagedConnectionFactory.java:1508)
> at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.getConnectionProperties(BaseWrapperManagedConnectionFactory.java:1135)
> at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.matchManagedConnections(XAManagedConnectionFactory.java:533)
> ...
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
> at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:66)
> ...
> "thread-two" ...
> java.lang.Thread.State: BLOCKED (on object monitor)
> at java.util.Collections$SynchronizedMap.size(Collections.java:2572)
> - waiting to lock <0x00000001d0d08bd8> (a java.util.Collections$SynchronizedMap)
> at java.util.AbstractMap.equals(AbstractMap.java:482)
> at java.util.Collections$SynchronizedMap.equals(Collections.java:2631)
> - locked <0x00000001cea22628> (a java.util.Collections$SynchronizedMap)
> at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.isEqual(XAManagedConnectionFactory.java:563)
> - locked <0x00000001cea22628> (a java.util.Collections$SynchronizedMap)
> at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.equals(XAManagedConnectionFactory.java:598)
> ... [same stack as thread-one above] ...
> at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
> at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:66)
> ...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (WFLY-10182) Unstable work of the persistent EJB timers with Oracle DB. ORA-08177: can't serialize access for this transaction
by Maxim Karavaev (JIRA)
[ https://issues.jboss.org/browse/WFLY-10182?page=com.atlassian.jira.plugin... ]
Maxim Karavaev updated WFLY-10182:
----------------------------------
Workaround Description: Patch attached
> Unstable work of the persistent EJB timers with Oracle DB. ORA-08177: can't serialize access for this transaction
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10182
> URL: https://issues.jboss.org/browse/WFLY-10182
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final, 11.0.0.Final, 12.0.0.Final
> Environment: WildFly cluster in domain mode.
> Oracle 12c DB
> Reporter: Maxim Karavaev
> Attachments: Stable_persistence_logic_of_EJB_Timers.patch
>
>
> The main signal is an exception in logs:
> {noformat}
> ORA-08177: can't serialize access for this transaction
> {noformat}
> When one cluster node is halted (the one on the witch "Timer" is actually working) then the other nodes are still can't catch up this "timer" from the DB due to the mentioned exception. Even worth scenario - when all nodes work perfectly, but occasionally all nodes start to decline, that timer is in the state IN_TIMEOUT and it really is due to the DB state, just because the last timer's invocation did not manage to commit final state after processing due to the same reason (SQL exception).
> So, why Oracle DB is so special? That's because it never manages transactions by themselves. It's full responsibility of the client.
> Looking into the code of the class
> {noformat}
> org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence
> {noformat}
> I didn't find transaction management, except one method, and even in it, I found, that it probably doesn't manage transaction as desired, due to the lack of resource participation.
> After I've made some changes to enable transactions for that functionality I have managed to stable EJB Timer logic on the server. Let's have a look at the attached patch (it's for 11 version, but it also works for 12).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (WFLY-10182) Unstable work of the persistent EJB timers with Oracle DB. ORA-08177: can't serialize access for this transaction
by Maxim Karavaev (JIRA)
[ https://issues.jboss.org/browse/WFLY-10182?page=com.atlassian.jira.plugin... ]
Maxim Karavaev updated WFLY-10182:
----------------------------------
Description:
The main signal is an exception in logs:
{noformat}
ORA-08177: can't serialize access for this transaction
{noformat}
When one cluster node is halted (the one on the witch "Timer" is actually working) then the other nodes are still can't catch up this "timer" from the DB due to the mentioned exception. Even worth scenario - when all nodes work perfectly, but occasionally all nodes start to decline, that timer is in the state IN_TIMEOUT and it really is due to the DB state, just because the last timer's invocation did not manage to commit final state after processing due to the same reason (SQL exception).
So, why Oracle DB is so special? That's because it never manages transactions by themselves. It's full responsibility of the client.
Looking into the code of the class
{noformat}
org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence
{noformat}
I didn't find transaction management, except one method, and even in it, I found, that it probably doesn't manage transaction as desired, due to the lack of resource participation.
After I've made some changes to enable transactions for that functionality I have managed to stable EJB Timer logic on the server. Let's have a look at the attached patch (it's for 11 version, but it also works for 12).
was:
The main signal is an exception in logs:
{noformat}
ORA-08177: can't serialize access for this transaction
{noformat}
When one cluster node is halted (the one on the witch "Timer" is actually working) then the other nodes are still can't catch up this "timer" from the DB due to the mentioned exception. Even worth scenario - when all nodes work perfectly, but occasionally all nodes start to decline, that timer is in the state IN_TIMEOUT and it really is due to the DB state, just because the last timer's invocation did not manage to commit final state after processing due to the same reason (SQL exception).
So, why Oracle DB is so special? That's because it never manages transactions by themselves. It's full responsibility of the client.
Looking into the code of the class
{noformat}
org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence
{noformat}
I didn't find transaction management, except one method, and even in it, I found, that it probably doesn't manage transaction as desired, due to the lack of resource participation.
After I've made some changes to enable transactions for that functionality I have managed to stable EJB Timer logic on the server. Let's have a look in attached patch.
> Unstable work of the persistent EJB timers with Oracle DB. ORA-08177: can't serialize access for this transaction
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10182
> URL: https://issues.jboss.org/browse/WFLY-10182
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final, 11.0.0.Final, 12.0.0.Final
> Environment: WildFly cluster in domain mode.
> Oracle 12c DB
> Reporter: Maxim Karavaev
> Attachments: Stable_persistence_logic_of_EJB_Timers.patch
>
>
> The main signal is an exception in logs:
> {noformat}
> ORA-08177: can't serialize access for this transaction
> {noformat}
> When one cluster node is halted (the one on the witch "Timer" is actually working) then the other nodes are still can't catch up this "timer" from the DB due to the mentioned exception. Even worth scenario - when all nodes work perfectly, but occasionally all nodes start to decline, that timer is in the state IN_TIMEOUT and it really is due to the DB state, just because the last timer's invocation did not manage to commit final state after processing due to the same reason (SQL exception).
> So, why Oracle DB is so special? That's because it never manages transactions by themselves. It's full responsibility of the client.
> Looking into the code of the class
> {noformat}
> org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence
> {noformat}
> I didn't find transaction management, except one method, and even in it, I found, that it probably doesn't manage transaction as desired, due to the lack of resource participation.
> After I've made some changes to enable transactions for that functionality I have managed to stable EJB Timer logic on the server. Let's have a look at the attached patch (it's for 11 version, but it also works for 12).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (WFLY-10182) Unstable work of the persistent EJB timers with Oracle DB. ORA-08177: can't serialize access for this transaction
by Maxim Karavaev (JIRA)
[ https://issues.jboss.org/browse/WFLY-10182?page=com.atlassian.jira.plugin... ]
Maxim Karavaev updated WFLY-10182:
----------------------------------
Description:
The main signal is an exception in logs:
{noformat}
ORA-08177: can't serialize access for this transaction
{noformat}
When one cluster node is halted (the one on the witch "Timer" is actually working) then the other nodes are still can't catch up this "timer" from the DB due to the mentioned exception. Even worth scenario - when all nodes work perfectly, but occasionally all nodes start to decline, that timer is in the state IN_TIMEOUT and it really is due to the DB state, just because the last timer's invocation did not manage to commit final state after processing due to the same reason (SQL exception).
So, why Oracle DB is so special? That's because it never manages transactions by themselves. It's full responsibility of the client.
Looking into the code of the class
{noformat}
org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence
{noformat}
I didn't find transaction management, except one method, and even in it, I found, that it probably doesn't manage transaction as desired, due to the lack of resource participation.
After I've made some changes to enable transactions for that functionality I have managed to stable EJB Timer logic on the server. Let's have a look in attached patch.
was:
The main signal is an exception in logs:
{noformat}
ORA-08177: can't serialize access for this transaction
{noformat}
When one cluster node is halted (the one on the witch "Timer" is actually working) then the other nodes are still can't catch up this "timer" from the DB due to the mentioned exception. Even worth scenario - when all nodes work perfectly, but occasionally all nodes start to decline, that timer is in the state IN_TIMEOUT and it really is due to the DB state, just because the last timer's invocation did not manage to commit final state after processing due to the same reason (SQL exception).
So, why Oracle DB is so special? That's because it never manages transactions by themselves. It's full responsibility of the client.
Looking into the code of the class
{noformat}
org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence
{noformat}
I didn't find transaction management, except one method, and even in it, I found, that it probably doesn't manage transaction as desired, due to the lack of resource participation.
After I've made some changes to enable transactions for that functionality I have managed to stable EJB Timer logic on the server.
> Unstable work of the persistent EJB timers with Oracle DB. ORA-08177: can't serialize access for this transaction
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10182
> URL: https://issues.jboss.org/browse/WFLY-10182
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final, 11.0.0.Final, 12.0.0.Final
> Environment: WildFly cluster in domain mode.
> Oracle 12c DB
> Reporter: Maxim Karavaev
> Attachments: Stable_persistence_logic_of_EJB_Timers.patch
>
>
> The main signal is an exception in logs:
> {noformat}
> ORA-08177: can't serialize access for this transaction
> {noformat}
> When one cluster node is halted (the one on the witch "Timer" is actually working) then the other nodes are still can't catch up this "timer" from the DB due to the mentioned exception. Even worth scenario - when all nodes work perfectly, but occasionally all nodes start to decline, that timer is in the state IN_TIMEOUT and it really is due to the DB state, just because the last timer's invocation did not manage to commit final state after processing due to the same reason (SQL exception).
> So, why Oracle DB is so special? That's because it never manages transactions by themselves. It's full responsibility of the client.
> Looking into the code of the class
> {noformat}
> org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence
> {noformat}
> I didn't find transaction management, except one method, and even in it, I found, that it probably doesn't manage transaction as desired, due to the lack of resource participation.
> After I've made some changes to enable transactions for that functionality I have managed to stable EJB Timer logic on the server. Let's have a look in attached patch.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (WFLY-10182) Unstable work of the persistent EJB timers with Oracle DB. ORA-08177: can't serialize access for this transaction
by Maxim Karavaev (JIRA)
Maxim Karavaev created WFLY-10182:
-------------------------------------
Summary: Unstable work of the persistent EJB timers with Oracle DB. ORA-08177: can't serialize access for this transaction
Key: WFLY-10182
URL: https://issues.jboss.org/browse/WFLY-10182
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 12.0.0.Final, 11.0.0.Final, 10.1.0.Final
Environment: WildFly cluster in domain mode.
Oracle 12c DB
Reporter: Maxim Karavaev
Attachments: Stable_persistence_logic_of_EJB_Timers.patch
The main signal is an exception in logs:
{noformat}
ORA-08177: can't serialize access for this transaction
{noformat}
When one cluster node is halted (the one on the witch "Timer" is actually working) then the other nodes are still can't catch up this "timer" from the DB due to the mentioned exception. Even worth scenario - when all nodes work perfectly, but occasionally all nodes start to decline, that timer is in the state IN_TIMEOUT and it really is due to the DB state, just because the last timer's invocation did not manage to commit final state after processing due to the same reason (SQL exception).
So, why Oracle DB is so special? That's because it never manages transactions by themselves. It's full responsibility of the client.
Looking into the code of the class
{noformat}
org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence
{noformat}
I didn't find transaction management, except one method, and even in it, I found, that it probably doesn't manage transaction as desired, due to the lack of resource participation.
After I've made some changes to enable transactions for that functionality I have managed to stable EJB Timer logic on the server.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (WFLY-10182) Unstable work of the persistent EJB timers with Oracle DB. ORA-08177: can't serialize access for this transaction
by Maxim Karavaev (JIRA)
[ https://issues.jboss.org/browse/WFLY-10182?page=com.atlassian.jira.plugin... ]
Maxim Karavaev updated WFLY-10182:
----------------------------------
Attachment: Stable_persistence_logic_of_EJB_Timers.patch
> Unstable work of the persistent EJB timers with Oracle DB. ORA-08177: can't serialize access for this transaction
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10182
> URL: https://issues.jboss.org/browse/WFLY-10182
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final, 11.0.0.Final, 12.0.0.Final
> Environment: WildFly cluster in domain mode.
> Oracle 12c DB
> Reporter: Maxim Karavaev
> Attachments: Stable_persistence_logic_of_EJB_Timers.patch
>
>
> The main signal is an exception in logs:
> {noformat}
> ORA-08177: can't serialize access for this transaction
> {noformat}
> When one cluster node is halted (the one on the witch "Timer" is actually working) then the other nodes are still can't catch up this "timer" from the DB due to the mentioned exception. Even worth scenario - when all nodes work perfectly, but occasionally all nodes start to decline, that timer is in the state IN_TIMEOUT and it really is due to the DB state, just because the last timer's invocation did not manage to commit final state after processing due to the same reason (SQL exception).
> So, why Oracle DB is so special? That's because it never manages transactions by themselves. It's full responsibility of the client.
> Looking into the code of the class
> {noformat}
> org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence
> {noformat}
> I didn't find transaction management, except one method, and even in it, I found, that it probably doesn't manage transaction as desired, due to the lack of resource participation.
> After I've made some changes to enable transactions for that functionality I have managed to stable EJB Timer logic on the server.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (WFLY-10181) Deadlock for threads executing org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.isEqual
by Flavia Rainone (JIRA)
Flavia Rainone created WFLY-10181:
-------------------------------------
Summary: Deadlock for threads executing org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.isEqual
Key: WFLY-10181
URL: https://issues.jboss.org/browse/WFLY-10181
Project: WildFly
Issue Type: Bug
Components: JCA
Affects Versions: 12.0.0.Final
Reporter: Flavia Rainone
Assignee: Flavia Rainone
Fix For: 13.0.0.Beta1
Two or more threads hold one lock on an instance of java.util.Collections$SynchronizedMap and attempt to obtain a lock on a different instance (e.g. locks on 0x00000001d0d08bd8 and 0x00000001cea22628 in the example below)
"thread-one" ...
java.lang.Thread.State: BLOCKED (on object monitor)
at java.util.Collections$SynchronizedMap.get(Collections.java:2584)
waiting to lock <0x00000001cea22628> (a java.util.Collections$SynchronizedMap)
at java.util.AbstractMap.equals(AbstractMap.java:495)
at java.util.Collections$SynchronizedMap.equals(Collections.java:2631)
locked <0x00000001d0d08bd8> (a java.util.Collections$SynchronizedMap)
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.isEqual(XAManagedConnectionFactory.java:563)
locked <0x00000001d0d08bd8> (a java.util.Collections$SynchronizedMap)
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.equals(XAManagedConnectionFactory.java:598)
at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory$SubjectActions.doCheck(BaseWrapperManagedConnectionFactory.java:1397)
at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory$SubjectActions.addMatchingProperties(BaseWrapperManagedConnectionFactory.java:1508)
at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.getConnectionProperties(BaseWrapperManagedConnectionFactory.java:1135)
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.matchManagedConnections(XAManagedConnectionFactory.java:533)
...
at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:66)
...
"thread-two" ...
java.lang.Thread.State: BLOCKED (on object monitor)
at java.util.Collections$SynchronizedMap.size(Collections.java:2572)
waiting to lock <0x00000001d0d08bd8> (a java.util.Collections$SynchronizedMap)
at java.util.AbstractMap.equals(AbstractMap.java:482)
at java.util.Collections$SynchronizedMap.equals(Collections.java:2631)
locked <0x00000001cea22628> (a java.util.Collections$SynchronizedMap)
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.isEqual(XAManagedConnectionFactory.java:563)
locked <0x00000001cea22628> (a java.util.Collections$SynchronizedMap)
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.equals(XAManagedConnectionFactory.java:598)
... [same stack as thread-one above] ...
at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:66)
...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (JBJCA-1371) Deadlock for threads executing org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.isEqual
by Flavia Rainone (JIRA)
Flavia Rainone created JBJCA-1371:
-------------------------------------
Summary: Deadlock for threads executing org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.isEqual
Key: JBJCA-1371
URL: https://issues.jboss.org/browse/JBJCA-1371
Project: IronJacamar
Issue Type: Bug
Components: Core
Reporter: Flavia Rainone
Assignee: Flavia Rainone
Two or more threads hold one lock on an instance of java.util.Collections$SynchronizedMap and attempt to obtain a lock on a different instance (e.g. locks on 0x00000001d0d08bd8 and 0x00000001cea22628 in the example below)
"thread-one" ...
java.lang.Thread.State: BLOCKED (on object monitor)
at java.util.Collections$SynchronizedMap.get(Collections.java:2584)
- waiting to lock <0x00000001cea22628> (a java.util.Collections$SynchronizedMap)
at java.util.AbstractMap.equals(AbstractMap.java:495)
at java.util.Collections$SynchronizedMap.equals(Collections.java:2631)
- locked <0x00000001d0d08bd8> (a java.util.Collections$SynchronizedMap)
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.isEqual(XAManagedConnectionFactory.java:563)
- locked <0x00000001d0d08bd8> (a java.util.Collections$SynchronizedMap)
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.equals(XAManagedConnectionFactory.java:598)
at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory$SubjectActions.doCheck(BaseWrapperManagedConnectionFactory.java:1397)
at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory$SubjectActions.addMatchingProperties(BaseWrapperManagedConnectionFactory.java:1508)
at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.getConnectionProperties(BaseWrapperManagedConnectionFactory.java:1135)
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.matchManagedConnections(XAManagedConnectionFactory.java:533)
...
at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:66)
...
"thread-two" ...
java.lang.Thread.State: BLOCKED (on object monitor)
at java.util.Collections$SynchronizedMap.size(Collections.java:2572)
- waiting to lock <0x00000001d0d08bd8> (a java.util.Collections$SynchronizedMap)
at java.util.AbstractMap.equals(AbstractMap.java:482)
at java.util.Collections$SynchronizedMap.equals(Collections.java:2631)
- locked <0x00000001cea22628> (a java.util.Collections$SynchronizedMap)
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.isEqual(XAManagedConnectionFactory.java:563)
- locked <0x00000001cea22628> (a java.util.Collections$SynchronizedMap)
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.equals(XAManagedConnectionFactory.java:598)
... [same stack as thread-one above] ...
at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:66)
...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (WFCORE-3730) Use of relative-to in path in domain mode prevents the server from starting up.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3730?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-3730:
----------------------------------------
Assignee: Brian Stansberry (was: Yeray Borges)
Hi Yeray -- sorry I didn't see you'd assigned the JBEAP to yourself until I was about to link a PR.
> Use of relative-to in path in domain mode prevents the server from starting up.
> -------------------------------------------------------------------------------
>
> Key: WFCORE-3730
> URL: https://issues.jboss.org/browse/WFCORE-3730
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Teresa Miyar
> Assignee: Brian Stansberry
>
> Server does not start on domain mode when setting relative-to in the path
> {code:java}
> <paths>
> <path name="apps.log.dir" path="/apps/logs" relative-to="jboss.domain.base.dir"/>
> </paths>
> {code}
> {code:java}
> [Host Controller] 13:28:05,730 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/path=apps.log.dir' are not available:
> [Host Controller] org.wildfly.management.path.jboss.domain.base.dir in context 'global'; Possible registration points for this capability:
> [Host Controller] /host=master/path=*
> [Host Controller] /host=master/server-config=*/path=*
> [Host Controller] /path=*
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months