Hi Christian,
if you're not going to read from the body of the message multiple
times you can disable stream caching. I think that the memory increase
you see is due to message history, try disabling that[1]. If that
fails to help perhaps you could provide an example that we can
reproduce this?

zoran

[1] https://camel.apache.org/message-history.html

On Mon, Nov 20, 2017 at 7:21 PM,  <[email protected]> wrote:
> Hi there,
>
> I have to download pretty large files (> 200 MB) from a remote server via 
> http and process them with a very specific library. This library relies on 
> using files and not streams, so I have a route looking like
>
> from (...)
> .toD("${body}")
> .to("file:" + tempDirectoryName)
>
> In the body, I had constructed the URI to the file to be downloaded. I 
> quickly ran into memory leaks, so I changed the code to
> from(...=
> .toD("${body}")
> .streamCaching()
> .to("file:" + tempDirectoryName)
>
> This helped with the memory leak because now the data are written twice on my 
> disk: one to the temporary directory name that I had intended and one in the 
> java.io.tempdir directory. The documentation on Camel Stream-caching states 
> "Camel itself will handle deleting the temporary file once the cached stream 
> is no longer necessary." But I can't see that happen. The large files remain 
> where they are. Any ideas what went wrong?
>
> Kind regards,
> Christian Jacob
>
> Innogy SE
> Retail IT
> Integration and Digital Solutions (AFS-IGI)
> Rellinghauser Str. 37
> 45128 Essen
> T intern: 70-20581
> T extern: +49 (0)201 12 20582
> T mobil: +49 (0)1622843981
> Fax: +49 (0)201 12 24796
> mailto: [email protected]
>
> ----------------------------------------------------------------
> innogy SE Vorsitzender des Aufsichtsrates: Dr. Werner Brandt
> Vorstand: Peter Terium (Vorsitzender), Dr. Hans Buenting,
> Dr. Bernhard Guenther, Martin Herrmann, Hildegard Mueller, Uwe Tigges
> Sitz der Gesellschaft: Essen, Eingetragen beim Amtsgericht Essen,
> Handelsregister-Nr. HRB 27091, USt-IdNr. DE304171711



-- 
Zoran Regvart

Reply via email to