activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kai Hudalla (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (AMQ-1779) RA does not reconnect correctly to a failed broker
Date Fri, 06 Jun 2008 14:18:01 GMT

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

hudalla edited comment on AMQ-1779 at 6/6/08 7:16 AM:
----------------------------------------------------------

The work done by David Jencks on the 4.x branch in AMQ-1632 still has some issues regarding
synchronization:

- When the RA tries to connect to the broker, it does so by subsequently scheduling the connectWork
using the WorkManager. However, the monitor on connectWork may be lost when the connectWork
is re-scheduled after an unsuccessful attempt, making it possible that the getConnection()
method gets the monitor and returns null instead of the re-established connection.
- The code for registering a ConnectionConsumer on the ActiveMQConnection leads to a deadlock
if there are some messages left to be delivered from before the broker has failed. In that
case, the ServerSessionPoolImpl.createServerSessionImpl() method will be triggered by the
next message delivery. However, the createServerSessionImpl() method needs to wait for the
EndpointWorker.getConnection() method to return which is also synchronized on the connectWork
that is trying to register the ConnectionConsumer. The problem here is that the constructor
of the ActiveMQConnectionConsumer uses syncSendPacket() instead of asyncSendPacket() in order
to register the consumer with the broker. Thus the instantiation of the ActiveMQConnectionConsumer
blocks until the first message has been delivered, leading to the deadlock.

Kai

      was (Author: hudalla):
    The work done by David Jencks still has some issues regarding synchronization:

- When the RA tries to connect to the broker, it does so by subsequently scheduling the connectWork
using the WorkManager. However, the monitor on connectWork may be lost when the connectWork
is re-scheduled after an unsuccessful attempt, making it possible that the getConnection()
method gets the monitor and returns null instead of the re-established connection.
- The code for registering a ConnectionConsumer on the ActiveMQConnection leads to a deadlock
if there are some messages left to be delivered from before the broker has failed. In that
case, the ServerSessionPoolImpl.createServerSessionImpl() method will be triggered by the
next message delivery. However, the createServerSessionImpl() method needs to wait for the
EndpointWorker.getConnection() method to return which is also synchronized on the connectWork
that is trying to register the ConnectionConsumer. The problem here is that the constructor
of the ActiveMQConnectionConsumer uses syncSendPacket() instead of asyncSendPacket() in order
to register the consumer with the broker. Thus the instantiation of the ActiveMQConnectionConsumer
blocks until the first message has been delivered, leading to the deadlock.

Kai
  
> RA does not reconnect correctly to a failed broker
> --------------------------------------------------
>
>                 Key: AMQ-1779
>                 URL: https://issues.apache.org/activemq/browse/AMQ-1779
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Connector
>    Affects Versions: 5.0.0, 5.1.0
>            Reporter: Kai Hudalla
>
> The Resource Adapter does not cleanly reconnect to a failed broker:
> - it uses stale sessions to deliver messages to an Endpoint resulting in messages not
being delivered at all anymore after the connection has been re-established
> - the code for connecting/reconnecting to the broker is not synchronized properly leading
to race conditions/deadlocks in some situations
> Kai

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message