camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Neugebauer (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CAMEL-8308) RabbitMQEndpoint: setting prefetchEnabled=false or prefetchCount=0 (default values) locks all messages on RabbitMQ
Date Thu, 12 Mar 2015 10:09:38 GMT

    [ https://issues.apache.org/jira/browse/CAMEL-8308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14358430#comment-14358430
] 

Daniel Neugebauer edited comment on CAMEL-8308 at 3/12/15 10:09 AM:
--------------------------------------------------------------------

Sorry, of course I meant the properties. :)

Here it's RabbitMQ 3.2.4, Erlang R15B03-1, Camel 2.14.1, amqp-client 3.3.4. The message is
generated via [php-amqplib|https://github.com/videlalvaro/php-amqplib] 2.4.1 (which shouldn't
matter):
{code:none}
$msg = new AMQPMessage($msg_body, array(
    'content_type' => 'text/plain',
    'delivery_mode' => 2,
    'expiration' => $timeoutSeconds * 1000,
    //'reply_to' => 'amq.rabbitmq.reply-to'
    'reply_to' => $replyQueueName
));
$ch->basic_publish($msg, $exchangeName);
{code}

It's not in production yet, so I may get an opportunity to try an update next week (I'm currently
on vacation). Both RabbitMQ 3.1.4 and 3.2.4 (latest "stable" on the Linux distribution we
use) are fairly old but since I get that issue on a later version, there might have been some
new feature introduced between 3.1 and 3.2 which causes that message locking. The news regarding
3.2.0 says it "features enhanced policies for aspects of the broker which previously required
AMQP arguments" - maybe that's the culprit unless it's just some bug in RabbitMQ (but then
still the client appears to be to eager when querying for messages).


was (Author: dneuge):
Sorry, of course I meant the properties. :)

Here it's RabbitMQ 3.2.4, Erlang R15B03-1, Camel 2.14.1, amqp-client 3.3.4. The message is
generated via [php-amqplib|https://github.com/videlalvaro/php-amqplib] 2.4.1 (which shouldn't
matter):
{code:php}
$msg = new AMQPMessage($msg_body, array(
    'content_type' => 'text/plain',
    'delivery_mode' => 2,
    'expiration' => $timeoutSeconds * 1000,
    //'reply_to' => 'amq.rabbitmq.reply-to'
    'reply_to' => $replyQueueName
));
$ch->basic_publish($msg, $exchangeName);
{code}

It's not in production yet, so I may get an opportunity to try an update next week (I'm currently
on vacation). Both RabbitMQ 3.1.4 and 3.2.4 (latest "stable" on the Linux distribution we
use) are fairly old but since I get that issue on a later version, there might have been some
new feature introduced between 3.1 and 3.2 which causes that message locking. The news regarding
3.2.0 says it "features enhanced policies for aspects of the broker which previously required
AMQP arguments" - maybe that's the culprit unless it's just some bug in RabbitMQ (but then
still the client appears to be to eager when querying for messages).

> RabbitMQEndpoint: setting prefetchEnabled=false or prefetchCount=0 (default values) locks
all messages on RabbitMQ
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-8308
>                 URL: https://issues.apache.org/jira/browse/CAMEL-8308
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-rabbitmq
>    Affects Versions: 2.14.1
>            Reporter: Daniel Neugebauer
>
> If RabbitMQEndpoint is configured with either prefetchEnabled=false or prefetchCount=0
(both are default values), then messages appear to be locked on server-side (getting prefetched
with high/no limit?).
> To reproduce:
> # add multiple messages to a RabbitMQ queue which define an expiration header (after
expiration, RabbitMQ will remove those message from queue without delivering them to consumers)
> # watch RabbitMQ admin panel, you should see n messages are "Ready", 0 messages are "Unacknowledged"
> # configure & run one concurrent RabbitMQEndpoint from Camel with above settings
+ autoAck=false and delay/block processing of messages (e.g. by running Thread.wait(10000)
in a Processor)
> # watch the admin panel again: 0 messages are "Ready", n messages are "Unacknowledged"
- so Camel appears to have prefetched all messages?
> # wait until messages should have expired
> # admin panel still shows all unprocessed messages as unacknowledged although they should
have been removed from queue
> # Camel still processes those messages after expiration
> # stop Camel (returns all unacknowledged messages to ready state)
> # admin panel shows that all messages now have been purged from queue (much later than
they should have)
> Workaround: Repeating with prefetchEnabled=true and prefetchCount=1 shows only 1 message
"unacknowledged" while queue is being processed by Camel, all other messages remain "ready"
and expire in time (thus skipping the Camel queue as expected).
> Expected behaviour: If the prefetcher is disabled, no messages should get locked on server-side,
so messages can be expired by RabbitMQ as intended by the message sender.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message