Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Message-ID: <28234229.post@talk.nabble.com>
Date: Tue, 13 Apr 2010 12:28:03 -0700 (PDT)
From: PatrickVB <patrick.vanbrabant@gmail.com>
To: users@camel.apache.org
Subject: Re: Retry Processing
In-Reply-To: <u2j5380c69c1004131017tb82540bfi6c29e08c1ba06e7d@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <28219426.post@talk.nabble.com>
 <u2j5380c69c1004131017tb82540bfi6c29e08c1ba06e7d@mail.gmail.com>


Hi Claus,

Thanks a lot for the hints. I bought Camel in action and it looks very
promissing. I will give it a try. 
When encountering problems, I will probably have to come back to the forum
with more detailed questions.

Thanks again

Patrick


Claus Ibsen-2 wrote:
> 
> Hi
> 
> A JMS Broker often also have a redelivery mechanism which you can
> leverage.
> For example Apache ActiveMQ have a dead letter queue etc.
> 
> Camel error handler is also capable of redelivery and dead letter
> channel and whatnot.
> You can use it to detect that the redelivery have exhausted and then
> send an email about this failure.
> You can also stop routes using the Camel API.
> 
> But restarting it automatic after 30 min is most likely more easier
> using RoutePolicy where you can have custom code control the route at
> will.
> 
> The camel webpage have a search box where you can enter some key words
> to see if you can find any good links.
> 
> Also the Camel in Action books cover extensively Error Handling in
> chapter 5. And in chapter 13 you can read about managing routes at
> runtime, eg dynamic starting and stopping routes etc.
> 
> 
> On Tue, Apr 13, 2010 at 9:21 AM, PatrickVB <patrick.vanbrabant@gmail.com>
> wrote:
>>
>> Hi all,
>>
>> I want to implement the following functionality....
>>
>> The system received an xml message on a queue. The message contains
>> references to files for your information.
>> This message is then forwarded to a processor which is responsible for
>> performing extraction (unzipping, unrarring,...) of the references files.
>> After the processor has finished a new xml message must be put on a queue
>> again, containing the result of the extraction process.
>>
>> Now the problem I can see here, is that this extraction processing can
>> run
>> out of disk space. In that case an email message should be send to an
>> administrator and the extraction should be retried at some later time
>> (lets
>> say 30 minutes later)
>>
>> I was hoping that I could implement this kind of retry logic using camel.
>> I
>> sat that there is the dead-letter-channel stuff, where you can specify
>> number of redeliveries etc... I do however not know if this dead-letter
>> stuff is applicable to processors as well or only to endpoints.
>>
>> Any information on how I could implement this (references, pieces of code
>> etc...) would be very much appreciated, since I'm a complete newbie to
>> Camel.
>>
>> Many thanks
>>
>> Patrick
>> --
>> View this message in context:
>> http://old.nabble.com/Retry-Processing-tp28219426p28219426.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
> 
> 
> 
> -- 
> Claus Ibsen
> Apache Camel Committer
> 
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
> 
> 

-- 
View this message in context: http://old.nabble.com/Retry-Processing-tp28219426p28234229.html
Sent from the Camel - Users mailing list archive at Nabble.com.