camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Marcus (JIRA)" <>
Subject [jira] [Commented] (CAMEL-8221) No backpressure in aws-sqs Consumer
Date Mon, 16 Feb 2015 02:52:11 GMT


Steven Marcus commented on CAMEL-8221:

I think blocking exchanges is Camel's implementation of back-pressure for polling consumers.

Have you tried using a seda component to block additional polls until in-flight exchanges
I only have experience doing this with the swf component:


SQS is a ScheduledBatchPollingConsumer so you will need to set maxMessagesPerPoll.
A value of 1 is probably right if you have "slow" consumers.

I don't know if there are any other implications of ScheduledBatchPollingConsumer vs. a simple
PollingConsumer so what I say here may not be effective with SQS. ymmv... GL!

> No backpressure in aws-sqs Consumer
> -----------------------------------
>                 Key: CAMEL-8221
>                 URL:
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-aws
>    Affects Versions: 2.14.1
>            Reporter: Dan Brown
>             Fix For: Future
> We're using a camel Consumer with an aws-sqs endpoint and running into issues with large
queues and slow consumers. The consumer jvm downloads messages very fast from sqs, onto the
jvm heap, even though the camel receive method processes each message very slowly (and Ack's
when done, with autoAck = false). The result of this is that the consumer jvm continually
fills its heap with an unbounded queue of incoming messages and eventually throws OOME.
> To avoid this failure, we're looking for a way to enable backpressure when using aws-sqs—e.g.
an on-heap bounded queue between the component fetching from sqs and the user-defined actor
processing the messages—but I don't see anything relevant in the config:
> -
> Looking at the code, I see that SqsConsumer subtypes ScheduledBatchPollingConsumer, which
subtypes ScheduledPollConsumer. To get backpressure, should it use something like EventDrivenPollingConsumer
somewhere, which uses a blocking queue to avoid the heap blowup above?
> -
> -
> -
> -

This message was sent by Atlassian JIRA

View raw message