camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "alex hutter (JIRA)" <>
Subject [jira] [Updated] (CAMEL-5306) Support for sending ChangeMessageVisibility calls while processing SQS messages
Date Tue, 29 May 2012 12:25:22 GMT


alex hutter updated CAMEL-5306:

    Attachment: extendMessageVisibility_v2.patch

As suggested I have tidied code to use scheduleAtFixedRate(), making the code easier to read
and slightly shorter.
And feedback is appreciated.
> Support for sending ChangeMessageVisibility calls while processing SQS messages
> -------------------------------------------------------------------------------
>                 Key: CAMEL-5306
>                 URL:
>             Project: Camel
>          Issue Type: New Feature
>          Components: camel-aws
>            Reporter: alex hutter
>            Priority: Minor
>         Attachments: extendMessageVisibility.patch, extendMessageVisibility_v2.patch
> When consuming messages from SQS the visibilityTimeout property controls how long the
consumer has to call deleteMessage before the message is re-delivered to another consumer.
 When processing messages that take an unpredicatible duration, such as requests to download
large files, it is difficult to choose a good value for visibilityTimeout.
> SQS provides an API ChangeMessageVisibility that can be used to extend visbilityTimeout
if a consumer determins that it is going to need longer to process the current message (
> I would like Camel to be able to handle the calling of ChangeMessageVisibility based
on how long the message consuming code is taking to process the received message.  Since Camel
knows how long visibilityTimeout is set to it should be able to keep SQS notified that the
processor is still running until it is ready to call deleteMessage.
> I have had a first attempt at solving this and my code is in the attached patch.  This
may not be a perfect solution so please provide me with feedback if you would like it changed
before it is merged in.
> The patch was made against the 2.9.x branch and my working copy is:

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message