You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Timothy Bish (JIRA)" <ji...@apache.org> on 2012/12/12 16:51:21 UTC

[jira] [Resolved] (AMQCPP-445) Prefetch_size = 0 and failover: consumer blocked in receive() when broker restarts

     [ https://issues.apache.org/jira/browse/AMQCPP-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Timothy Bish resolved AMQCPP-445.
---------------------------------

       Resolution: Fixed
    Fix Version/s: 3.5.0

This is fixed on trunk and will be in v3.5.0
                
> Prefetch_size = 0 and failover: consumer blocked in receive() when broker restarts
> ----------------------------------------------------------------------------------
>
>                 Key: AMQCPP-445
>                 URL: https://issues.apache.org/jira/browse/AMQCPP-445
>             Project: ActiveMQ C++ Client
>          Issue Type: Bug
>          Components: CMS Impl
>    Affects Versions: 3.4.4
>         Environment: Ubuntu 10.04/12.04 x86_64, ActiveMQ 5.5.0/5.7.0
>            Reporter: Thomas Riccardi
>            Assignee: Timothy Bish
>              Labels: blocked, consumer, dequeue, failover, prefetch_size, receive
>             Fix For: 3.5.0
>
>
> With prefetch_size=0, the consumer.receive() sends a pull request to the broker, and then waits on dequeue() for a new message.
> With failover, if the broker is restarted after having received the pull request, then the consumer is blocked indefinitely in receive(), and the broker never sends messages to it.
> Here is the stack of the blocked consumer. It never returned from the first call to receive().
> {quote}
> #0  pthread_cond_wait@@GLIBC_2.3.2 ()
> at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
> #1  0x00007f2528c8fdd7 in decaf::internal::util::concurrent::ConditionImpl::wait (condition=0x118a024)
> at decaf/internal/util/concurrent/unix/ConditionImpl.cpp:101
> #2  0x00007f2528b23075 in activemq::core::SimplePriorityMessageDispatchChannel::dequeue (this=0x1181b40, timeout=-1)
> at activemq/core/SimplePriorityMessageDispatchChannel.cpp:77
> #3  0x00007f2528ad6d78 in activemq::core::ActiveMQConsumer::dequeue (this=0x11892d0, timeout=-1) at activemq/core/ActiveMQConsumer.cpp:553
> #4  0x00007f2528adbef1 in activemq::core::ActiveMQConsumer::receive (this=0x11892d0) at activemq/core/ActiveMQConsumer.cpp:601
> {quote}
> It seems the failover mechanism never notifies the consumer->internal->unconsumedMessages fifo, so the consumer stays blocked on dequeue(), while the new broker doesn't know the consumer has sent a pull request.
> I haven't found any use of the callback transportResumed() from the failover transport.
> A solution would be to use this callback to notifyAll() on all consumers internal queues.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira