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 magnus.palmer.work@gmail.com
 designates 209.85.214.45 as permitted sender)
Subject: Re: From http4 via md5checksum to FTP: file cache or streaming ?
References: 
 <CAP4S5JyC4AXVrihDBUwdtsXqgxO8pDOvmd2RRUk7unRMVSXW9w@mail.gmail.com>
From: =?utf-8?Q?Magnus_Palm=C3=A9r?= <magnus.palmer.work@gmail.com>
Content-Type: text/plain;
	charset=utf-8
In-Reply-To: 
 <CAP4S5JyC4AXVrihDBUwdtsXqgxO8pDOvmd2RRUk7unRMVSXW9w@mail.gmail.com>
Message-Id: <DE360EC3-E4D4-4A41-9105-81446C51F951@gmail.com>
Date: Fri, 12 Aug 2011 17:10:07 +0200
To: "users@camel.apache.org" <users@camel.apache.org>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (iPhone Mail 8G4)

I would make your md5bean return a file.=20
Not sure if the current Jira issue of not cleaning (deleting) the file until=
 JVM stops will apply for you then or not.

Don't have the link to it right now.

--=20
Magnus Palm=C3=A9r
+46 736 845680

12 aug 2011 kl. 16:51 skrev wing-tung Leung <wingtung.leung@gmail.com>:

> Hello,
>=20
> one of our routes pulls binary data from from a HTTP service using
> http4, and then uploads the binary to a remote FTP directory. It also
> uses temporary files on the local filesystem behind the scenes , which
> makes sense because the binary image data can grow up till 10MB.
>=20
> Now I want to add one extra step: MD5 checksum verification just after
> the download. Because of the size, I prefer not to load all the data
> into a byte array to calculate a simple checksum, and use a
> InputStream instead. At first sight this seems to work. In the
> debugger, I can see this input stream is a wrapper around the locally
> cached file, and at the end of the function I return the original
> input stream.
>=20
> This is how the route currently looks like:
>    <to uri=3D"http4:/" />
>    <to uri=3D"bean:md5sum" />
>    <to uri=3D"ftp://{{attachment.ftp.location}}/?username=3D{{attachment.f=
tp.user}}&amp;password=3D{{attachment.ftp.password}}&amp;binary=3Dtrue"/>
>=20
> The processing bean method's signature:
>    InputStream process(InputStream buffer,
> @Header("mgws_file_md5sum") String expectedChecksum)
>=20
>=20
> But now the route seems to hang. I assume returning the "used" input
> stream is wrong, since the FTP component can't do anything useful with
> this anymore. I basically see options to fix this:
> 1 - use fancy stream interception with a custom HttpBinder for http4,
> integrating MD5 checksum calculation on the fly
> 2 - redirect to temporary file explicitly, start a new route for the
> checksum, reuse same file for FTP upload and cleanup manually
>=20
>=20
>=20
> Any other recommendations? I think this is a quite common use case, so
> I guess more experienced Camel user may want to give some useful
> advice to a novice like me ..
>=20
> Some pages I have been looking at:
> http://camel.apache.org/http4.html
> http://camel.apache.org/file2.html
> http://camel.apache.org/stream-caching.html
>=20
> (using Camel 2.6)
>=20
> Thanks!
>=20
> Tung