camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben O'Day (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CAMEL-3211) Enrich and PollEnrich - Option to let it poll multiple messages
Date Sun, 08 Jul 2012 17:03:34 GMT

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

Ben O'Day commented on CAMEL-3211:
----------------------------------

Thanks for the feedback Claus...I agree that a comprehensive solution is preferable.  I only
took a stab at a restricted approach because I often see a need to drain low volume JMS errors
queues to periodically retry messages and it seems a logical option for the pollEnrich pattern.
 This is the use case I targeted to avoid complicating it with other options (max messages,
aggregator, etc).  That said, it may be too specific/limiting as it stands.

Either way, I'd like to see some basic form of this in a 2.X release if possible.  Another
thought is to avoid doing this with a DSL/API change and just provide a helper class that
implements this batch polling consumer pattern based on constructor args (timeout, source,
target, aggregator, etc.).  This might bridge the gap a bit...





                
> Enrich and PollEnrich - Option to let it poll multiple messages
> ---------------------------------------------------------------
>
>                 Key: CAMEL-3211
>                 URL: https://issues.apache.org/jira/browse/CAMEL-3211
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-core
>    Affects Versions: 2.4.0
>            Reporter: Claus Ibsen
>            Assignee: Ben O'Day
>            Priority: Minor
>             Fix For: 2.11
>
>
> Think about if we can enhance enrich and/or pollEnrich to be able to poll multiple messages.
> For example to drain a JMS queue, or a FTP site etc. Currently it polls only 1 message,
and the continues.
> With some option to tell it to continue we can have it drain the queue until no more
messages.
> Or maybe some expression to tell when to stop. Or have some option in the custom aggregator
the end user can set/control if it should continue or poll more.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message