Net--RabbitMQ icon indicating copy to clipboard operation
Net--RabbitMQ copied to clipboard

Client stops consuming

Open DOBRO opened this issue 13 years ago • 3 comments

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.

DOBRO avatar Sep 20 '11 10:09 DOBRO

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=, __fd=) at /usr/include/bits/unistd.h:45 #2 wait_frame_inner (__nbytes=, __buf=, __fd=) 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=, cv=) 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 avatar Apr 02 '12 07:04 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 avatar Apr 18 '12 11:04 MattiL

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

MattiL avatar Apr 20 '12 13:04 MattiL