Client stops consuming

[DOBRO]

Hi,

I've run into the issue of consuming messages from a queue.

I wrote a daemon which forks several child processes. Each child process is a Net::RabbitMQ client which connects to RabbitMQ server, binds to a queue with its own routing key and starts to consume messages. So, all the clients (processes) are bound to the same queue with different routing keys. When the message is received, the client processes it and publish another message to another exchange.

Each process has its life cycle: while (1) { my $frame = $mq->recv();

processing frame...

.......

publish the confirmation

$mq->publish($channel, $another_routing_key, $some_data, {exchange => $another_exchange}); };

After a while one of the clients (not all of them) stops consuming messages until I restart the daemon. The problem appeared in version 0.1.9 which I installed from CPAN. After upgrading to 0.2.x this happens more often (every day). I had to downgrade Net::RabbitMQ to 0.1.9 because it's more stable. The issue happens once a week :)

I see no errors in the log file.

Any ideas?

Thanks.

[MattiL]

Hi!

I reported a similar bug in CPAN: https://rt.cpan.org/Public/Bug/Display.html?id=76206

A Perl program running Net::RabbitMQ seems to have gotten stuck in subroutine recv after I ran the script and does not respond to RabbitMQ messages being published. I set a breakpoint at XS_Net__RabbitMQ_recv, but gdb does not stop there. I copy here the output of the bt command after I pressed Control-C:

(gdb) bt

0 0x00007ff491ef7560 in __read_nocancel () from /lib64/libpthread.so.0

1 0x00007ff490b3bf2b in read (__nbytes=,

__buf=<value optimized out>, __fd=<value optimized out>)
at /usr/include/bits/unistd.h:45

2 wait_frame_inner (__nbytes=,

__buf=<value optimized out>, __fd=<value optimized out>)
at amqp_socket.c:179

3 0x00007ff490b23449 in internal_recv (RETVAL=0xbf4de8, conn=0xc29c50,

piggyback=0) at RabbitMQ.xs:102

4 0x00007ff490b240f6 in XS_Net__RabbitMQ_recv (

my_perl=<value optimized out>, cv=<value optimized out>) at RabbitMQ.xs:457

5 0x000000000047e115 in Perl_pp_entersub ()

6 0x0000000000455ad3 in Perl_runops_debug ()

7 0x000000000047a1af in perl_run ()

8 0x000000000042172c in main ()

(gdb) continue Continuing.

regards, Matti Linnanvuori

[MattiL]

If the RabbitMQ Server closes the channel, the client might get stuck: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2012-April/019572.html

[MattiL]

I have implemented channel close callback that can help in client getting stuck. My pull request now includes that feature.