camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen" <>
Subject Re: Concerns about File endpoint
Date Wed, 03 Dec 2008 07:00:55 GMT

The move is executed *AFTER* the routing.
The idea is that you process the file while it's in the target folder
(where its dropped) and after processing you can move it to a backup

Ah I speculate that the JMS consumer is faster than the file consumer
so when you drop a JMS message with the filename pointing at the move
folder then the JMS consumer in some circumstances be ahead of the
file consumer and trying to get the file before it's actually moved
there. Hence #1

You could to fix
b) use camel to route and move the file using pipes and filters
Note: However this will read the file content and save it as a new
file, it's not a native File IO move operation

a) move the file yourself and then afterwards send the JMS message.

Using a POJO bean you can move the file yourself using File rename.

/Claus Ibsen
Apache Camel Committer

On Tue, Dec 2, 2008 at 11:51 PM, Christopher Hammack
<> wrote:
> In addition to the memory leak issue in Camel 1.5.0, I have a few other
> concerns about the file consumer endpoint--some of which could be a
> misunderstanding on my part:
> 1.  When using the default move capability (moving a file to .camel) after
> it has been picked up, the object refers to the path BEFORE the
> move, not after.  So in order to actually read the file, my processing code
> must have knowledge of which path the file was moved to.  Is this
> intentional?
> 2.  Occasionally, especially when the system is under considerable load, the
> object that I get is not available in the moved location, which
> generates a FileNotFoundException.  When I check that location later on, the
> file is in the correct location.  Looking at the code, it seems like the
> message should not be being propogated back to me prior to the rename
> occurring, but it is apparently happening.  Any thoughts?
> The use case for this is a very large number of small files is being dropped
> into a directory.  This directory is then being scanned by camel's file
> endpoint.  The files as they are discovered are then moved to the .camel
> directory, and the filename is put onto a jms endpoint.  A clustered set of
> camel processors then pull the filename off the endpoint and process the
> file, and then delete it.
> Any suggestions would be appreciated as right now I'm "stranding" about one
> out of every 1000 files because the processing checks for the file prior to
> the file actually being in the moved location.
> Thanks.
> --
> View this message in context:
> Sent from the Camel - Users mailing list archive at

View raw message