FAQ
<dependency>
<groupId>com.rabbitmq</groupId>
<artifactId>amqp-client</artifactId>
<version>3.0.4</version>
</dependency>


RabbitMQ 3.0.2, Erlang R16A


I have a webpage that has a start button and a stop button.
These to buttons should start and stop the consuming messages.


When the user presses start button the consuming starts... when the user
presses the stop button the consuming stops
BUT.. the user cannot start the consuming again.
While debugging the code, I see the method call channel.basicCancel
hangs... and the debugger stops...
When I stop the JBoss server where the application is deployd I see this
exception coming in the catch when doing channel.basicCancel.
com.rabbitmq.client.ShutdownSignalException: clean channel shutdown;
reason: #method<channel.close>(reply-code 0, reply-text=OK, class-id=0,
method-id=0)


And in the method handleDelivery I see ShutdownSignalException...
com.rabbitmq.client.AlreadyClosedException: clean connection shutdown;
reason: Attempt to use closed channel


The call to basicCancel only hangs when consuming is going on.. if I start
the consuming, but no messages are on the queue, I can stop it.. and start
it again.


@Override
protected final synchronized void service(final HttpServletRequest req,
final HttpServletResponse resp) throws ServletException, IOException {
String task = req.getParameter("task");
         ...
if (StringUtils.isNotBlank(task) && task.equals("stop")) {
consuming = false;
try {
channel.basicCancel("MonitorConsumer");
} catch (Exception e) {
e.printStackTrace();
}
}
} else {
if (connection == null || channel == null) {
createRabbitConnection();
}
if (!consuming) {
channel.basicConsume(Configuration.QUEUE_JSI_TO_DASHBOARD, false,
"MonitorConsumer", this);
consuming = true;
}
}
}


public synchronized void handleDelivery(String consumerTag, Envelope
envelope, BasicProperties properties, byte[] body) throws IOException {
...
         try {
channel.basicAck(deliveryTag, false);
} catch (ShutdownSignalException e) {
e.printStackTrace();
}
}












-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130521/a311f354/attachment.htm>

Search Discussions

  • Kristian Lind at May 21, 2013 at 11:52 pm
    Updated to amqp-client 3.1.0 but still same problem.


    Tried to close channel instead od basicCancel.. same problem.





    On Tuesday, May 21, 2013 4:02:59 PM UTC-7, Kristian Lind wrote:

    <dependency>
    <groupId>com.rabbitmq</groupId>
    <artifactId>amqp-client</artifactId>
    <version>3.0.4</version>
    </dependency>

    RabbitMQ 3.0.2, Erlang R16A

    I have a webpage that has a start button and a stop button.
    These to buttons should start and stop the consuming messages.

    When the user presses start button the consuming starts... when the user
    presses the stop button the consuming stops
    BUT.. the user cannot start the consuming again.
    While debugging the code, I see the method call channel.basicCancel
    hangs... and the debugger stops...
    When I stop the JBoss server where the application is deployd I see this
    exception coming in the catch when doing channel.basicCancel.
    com.rabbitmq.client.ShutdownSignalException: clean channel shutdown;
    reason: #method<channel.close>(reply-code 0, reply-text=OK, class-id=0,
    method-id=0)

    And in the method handleDelivery I see ShutdownSignalException...
    com.rabbitmq.client.AlreadyClosedException: clean connection shutdown;
    reason: Attempt to use closed channel

    The call to basicCancel only hangs when consuming is going on.. if I
    start the consuming, but no messages are on the queue, I can stop it.. and
    start it again.

    @Override
    protected final synchronized void service(final HttpServletRequest req,
    final HttpServletResponse resp) throws ServletException, IOException {
    String task = req.getParameter("task");
    ...
    if (StringUtils.isNotBlank(task) && task.equals("stop")) {
    consuming = false;
    try {
    channel.basicCancel("MonitorConsumer");
    } catch (Exception e) {
    e.printStackTrace();
    }
    }
    } else {
    if (connection == null || channel == null) {
    createRabbitConnection();
    }
    if (!consuming) {
    channel.basicConsume(Configuration.QUEUE_JSI_TO_DASHBOARD, false,
    "MonitorConsumer", this);
    consuming = true;
    }
    }
    }

    public synchronized void handleDelivery(String consumerTag, Envelope
    envelope, BasicProperties properties, byte[] body) throws IOException {
    ...
    try {
    channel.basicAck(deliveryTag, false);
    } catch (ShutdownSignalException e) {
    e.printStackTrace();
    }
    }





    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130521/35fa6643/attachment.htm>
  • Kristian Lind at May 22, 2013 at 1:19 am
    I found the problem... I had a message that was not ack.. so now before
    closing the channel I ack the msg.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130521/291eaadb/attachment.htm>
  • Steve Powell at May 22, 2013 at 2:42 pm
    Hi Kristian,


    This behaviour seems incorrect: you should not block forever waiting for
    the Basic.CancelOk reply to come back. There could be a number of
    reasons for this but you *shouldn't* have to acknowledge all messages
    before being able to cancel a consumer.


    I wonder if the consumer is executing other channel methods in its
    callbacks? Possibly Ack, which should be ok; possibly other methods.


    It is entirely possible for consumer callbacks
    (handleDelivery/handleCancel/handleCancelOK etc.) to be called *after*
    you have called the basicCancel() method.


    There are two reasons for this -- one is that the communications with the
    server are asynchronous: deliveries might continue to be made after
    sending the Cancel frame and before getting the CancelOk reply.


    The other reason is that requests to call the callbacks are queued, and
    executed on their own thread in sequence for each channel. A number of
    callbacks may be queued when the basicCancel() method is called. They
    may not have finished executing even when the reply to the basic.cancel
    is received (Basic.CancelOk). Only when the reply is received is the
    call to handleCancelOk() put on the queue for execution, so that it is
    the last callback to be executed.


    For these reasons, you shouldn't consider the Consumer to be stopped
    properly until the last callback (handleCancelOk() or handleCancel())
    has been called.


    If one of the callbacks being processed makes a blocking call, even this
    shouldn't block the reply unless it blocks the channel somehow. So what
    could? I don't know, unless you are issuing a channel.close() or
    something in your consumer callback methods. There could be a bug here
    we ought to know about.


    If you have a stack dump at the point of the hang (jstack is probably
    the easiest way to get this) we should be able to tell what the other
    threads are doing, and then get a clue as to why you are blocked. The
    main thread that is hung is likely to be uninteresting -- it is probably
    waiting for the Basic.CancelOk frame to be received (on a getReply()
    call).


    So please could you tell us a little more about your application? In
    particular, what is your Consumer like? Are the handleDelivery()
    callbacks doing some unusual work with the channel, for instance?
    Anything that would help us get to the bottom of this would be useful.


    Steve Powell [Cell: +44-7815-838-558]
    Links: Pivotal, SpringSource, VMware, Virgo, RabbitMQ.
    -----------------------------------------------------------------------
    Good design:
        is innovative, useful, aesthetic;
        is understandable, unobtrusive, honest;
        is long-lasting, thorough, environmentally friendly;
        and is as little design as possible.
    Copyright Dieter Rams, amended March 2003; October 2009; and August 2012


    On 22 May 2013, at 02:19, Kristian Lind wrote:

    I found the problem... I had a message that was not ack.. so now before closing the channel I ack the msg._______________________________________________
    rabbitmq-discuss mailing list
    rabbitmq-discuss at lists.rabbitmq.com
    https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130522/0e66de5e/attachment.htm>

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedMay 21, '13 at 11:02p
activeMay 22, '13 at 2:42p
posts4
users2
websiterabbitmq.com
irc#rabbitmq

2 users in discussion

Kristian Lind: 3 posts Steve Powell: 1 post

People

Translate

site design / logo © 2017 Grokbase