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.
