activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Bish (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMQCPP-445) Prefetch_size = 0 and failover: consumer blocked in receive() when broker restarts
Date Tue, 11 Dec 2012 19:19:21 GMT

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

Timothy Bish commented on AMQCPP-445:
-------------------------------------

I believe that this as well as other scenarios like it are all fixed in the v3.5 code on trunk.
 You can download the latest SNAPSHOT src bundle here and try it out.  
http://people.apache.org/~tabish/cms-3.5.x/

This isn't fixable on v3.4.x baseline code as it requires changes that break ABI 
                
> 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
>
> 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

Mime
View raw message