You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Gary Tully (JIRA)" <ji...@apache.org> on 2016/07/20 21:15:20 UTC

[jira] [Commented] (AMQ-6370) JDBC message store - jdbc connection pool - potential deadlock with cleanup task when pool exhausted

    [ https://issues.apache.org/jira/browse/AMQ-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15386641#comment-15386641 ] 

Gary Tully commented on AMQ-6370:
---------------------------------

The fix for AMQ-2551 is the root cause.
Moving the locking to the transaction context, essentially up a level, will ensure that the datasource connection handling is always done with the appropriate lock.

> JDBC message store - jdbc connection pool - potential deadlock with cleanup task when pool exhausted
> ----------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-6370
>                 URL: https://issues.apache.org/jira/browse/AMQ-6370
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: JDBC, Message Store, XA
>    Affects Versions: 5.13.0
>            Reporter: Gary Tully
>            Assignee: Gary Tully
>             Fix For: 5.14.0
>
>
> There is an read/write lock guarding the cleanup task and other jdbc ops in the jdbc message store.
> Typically the read lock is obtained before the connection from the jdbc connection pool.
> In the case of xa transactions, the connection is obtained before the read lock, in transactioncontext.begin, leaving a window between which readlock holders can be blocked pending the connection release.
> If there is a cleanup (and write lock) request before release, the xa transaction cannot obtain a read lock and we are stuck.
> Disabling the cleanup task avoids this issue, but that is only an option if there are no durable subs or if the durable sub cleanup task can be tackled through db admin.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)