Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of claus.ibsen@gmail.com
 designates 209.85.212.169 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=pV9x02QCTJD4AOIqyIsH6NTdOZkkhmd4te5Gz9MaDlY9u8UOgm27l2VX0YJmlxH2nm
         MHnTFYviRTSEXTXB4reYydCIljnkYZl+iwIPJKwTKInxc+L+kCqtDHmothSWsIVXHY7O
         HLwJ9wBxWRnH7c221A/8qO1JsEpwBn+8irjA4=
MIME-Version: 1.0
In-Reply-To: <1304539507928-4370930.post@n5.nabble.com>
References: <1304523741531-4370197.post@n5.nabble.com>
 <1304539507928-4370930.post@n5.nabble.com>
From: Claus Ibsen <claus.ibsen@gmail.com>
Date: Thu, 5 May 2011 08:13:33 +0200
Message-ID: <BANLkTi=KxoTcYs8EeD9nvN0oeuo8hTX3AQ@mail.gmail.com>
Subject: Re: Error recovery
To: users@camel.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi

A good approach could be to design your applications to detect
duplicate messages.
See the idempotent consumer.
http://camel.apache.org/idempotent-consumer.html


That is much easier than trying to have a high QoS of delivering a
message exactly once.
That is frankly very hard as you need tight bookkeeping to keep state
of delivery and ack of messages.

You can detect the duplicates in the Camel application or on the
receiver side of the message broker.
Or in both for the matter.

An alternative is to split the file into 1 message per file. And then
consume those files.
That is possible since a file is persistent. And Camel only
delete/moves the file if it could successfully process it.

big file -> N files -> JMS


On Wed, May 4, 2011 at 10:05 PM, boday <ben.oday@initekconsulting.com> wrot=
e:
> It won't resume where it left off by default. =A0Camel will only delete t=
he
> file if it was successfully processed and when it fails, the portion alre=
ady
> send to AMQ will not be rolled back. =A0When the process resumes, it will
> process the entire file again. =A0One option is to use the file's moveFai=
led
> option to move the file if it failed for special processing (if already
> queued, ignore, etc)...
>
>
> shailesh wrote:
>>
>> Hi,
>> =A0 =A0I have camel in the web container. And I am processing the xml fi=
le and
>> spliting it and posting the split message to JMS queue.
>> =A0 =A0The question I have that if the server was the crash in the middl=
e of
>> the processing of the file.
>> =A0 =A0I would like the recovery from the failure to begin the processin=
g from
>> where the file was left off.
>>
>> =A0 <route>
>> =A0<from uri=3D"file://c:/target/infile"/>
>> =A0 =A0 =A0<split>
>> =A0 =A0 =A0 =A0 =A0 =A0 <xpath>/foo/bar</xpath>
>> =A0 =A0 =A0 =A0 =A0 =A0 <to uri=3D"jms:testQ1"/>
>> =A0 =A0 =A0 =A0</split>
>> =A0 </route>
>>
>> =A0 =A0Thanks for suggestion.
>>
>
>
> -----
> Ben O'Day
> IT Consultant -http://benoday.blogspot.com
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Error-rec=
overy-tp4370197p4370930.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>


--=20
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
CamelOne 2011: http://fusesource.com/camelone2011/
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/