camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Hammack <chamm...@fadedsky.com>
Subject Concerns about File endpoint
Date Tue, 02 Dec 2008 22:51:07 GMT

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 java.io.File 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
java.io.File 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: http://www.nabble.com/Concerns-about-File-endpoint-tp20802855s22882p20802855.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Mime
View raw message