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

Wed May 7 23:05:54 BST 2008

Ben,

Umm, I haven't used the direct client at all because I have a whole complex
application set up and it would have to run on the same Erlang node as
RabbitMQ, if I understand how the direct client works. I would have to
attach to the Rabbit node, set up all the right paths, and then start my
application. I'll try that and if there are not too many complications (e.g.
something silly like something in my application might expect a specific
node name), I will let you know what happens.

Thanks for your attention!

Regards,
Edwin

On Wed, May 7, 2008 at 5:03 PM, Ben Hood <0x6e6562 at gmail.com> wrote:

> 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/f9763aca/attachment.htm 