[rabbitmq-discuss] Channel crashes after basic.cancel_ok.

[Ben Hood]

Just quickly before you start doing stuff:

Does it make a difference if you just the direct client rather than  
the TCP client?

Ben

On 7 May 2008, at 21:50, Edwin Fine wrote:

> Thanks for the response, Ben. I will try to create a standalone  
> program that reproduces  the issue. I hope I can do it. The  
> hesitation comes because the circumstances under which this occurred  
> are:
> 50 queues on one <<direct>> exchange
> A producer that is pushing 150 messages/second to the queues, evenly  
> across the queue name
> Each queue is doing a basic.deliver to one of 50 Erlang consumer  
> processes (gen_event). The consumer processes all share the same  
> channel (which may not be a good idea, because when the channel  
> crashed, so did all 50 consumers. I wonder if I should have 1  
> channel for each consumer? Too heavy?).
> Because the channel.flow command is not implemented, I am using  
> unsubscribe to try to do flow control, because I am finding that  
> RabbitMQ is dumping all the basic.deliver messages into the Erlang  
> message queue of each consumer gen_event process. This is totally  
> not what I want - I want the messages to stay persisted in Rabbit- 
> land until I can deliver them and tell Rabbit to release them.
> The reason I need flow control is because I am delivering messages  
> via HTTP/XML to a number of different Web sites. Sometimes a web  
> site may be down, often for hours, and I want to just be able to  
> pause the consumer (and producer) until messages start going through  
> again. Having the Erlang message queues filling up with thousands of  
> messages will eventually crash the VM due to OOM. I know I can poll  
> with basic.get, but the conundrum is that I want high performance  
> while the web sites are accepting input, and shut-off when they are  
> not. Any suggestions?
> So I may have to build a simulated version of the above to get the  
> problem to happen again. That's the hesitation - will it trigger the  
> error?
>
> Anyway, I am probably not doing this the right way, but I have no  
> expertise in AMQP. My knowledge is of MQSeries a few years back.
>
> Regards,
> Edwin Fine
>
> On Wed, May 7, 2008 at 4:29 PM, Ben Hood <0x6e6562 at gmail.com> wrote:
> Edwin,
>
>
> On 7 May 2008, at 18:57, Edwin Fine wrote:
>
> Using Rabbit 1.3.0, Erlang client, Ubuntu Linux Feisty, Erlang  
> R12B-2 64-bit
>
> Consumer channel crashes as follows when I do the following:
>
> 1. Subscribe (basic.consume)
> 2. Unsubscribe (basic.cancel)
>
> The channel crashes handling the basic.cancel_ok. I can't figure out
> why. The channel is under some load (about 100 - 130 messages/second).
> I haven't yet built a standalone test case to try to reproduce this,
> but it happens consistently in my code.
>
> The code to subscribe is:
>
>   #'basic.consume_ok'{consumer_tag = ConsumerTag} =
> amqp_channel:call(Channel, BasicConsume, self())
>
> and this works fine.
>
> The code to cancel is
>
>   BasicCancel = #'basic.cancel'{consumer_tag = ConsumerTag, nowait =  
> false},
>   #'basic.cancel_ok'{consumer_tag = ConsumerTag} =
> amqp_channel:call(Channel, BasicCancel).
>
> The problem seems to be
>
> ** {function_clause,
>      [{gen_server,reply,
>           [<<>>,
>            {'basic.cancel_ok',<<"XHG.DELIVERY.Q.HTTP031.HC031">>}]},
>
>
> What am I doing wrong? Any ideas?
>
> What you are seeing is a symptom of an error in the RPC handling.  
> Essentially, the channel process is receiving a notification that it  
> thinks it has already sent to the invoking process.
>
> It would be really good if you could send some code that might help  
> me reproduce this myself.
>
> In the meantime I will look into this and see if I can come up with  
> a solution.
>
> HTH,
>
> Ben
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20080507/8be5afe7/attachment.htm