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