[jira] Issue Comment Edited: (AMQ-1779) RA does not reconnect correctly to a failed broker

["Kai Hudalla (JIRA)" <ji...@apache.org>]

    [ 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.