[
https://issues.apache.org/activemq/browse/CAMEL-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=52092#action_52092
]
Claus Ibsen commented on CAMEL-1670:
------------------------------------
>From Joe:
OK. My process reads a file, does some work on it, writes it to output,
then saves the results to a database. If the same file is processed twice
there is a database error.
I used the same route and data with readLock equal to markerFile, fileLock,
and rename. In each case, all the data made it to the database as expected.
With markerFile, an OverlappingFileLockException was thrown for each file,
each file was moved, and there was a marker file left behind for each file.
With fileLock, nothing ever got moved, so my process was stuck trying and
failing to process the same files over and over again (since an error was
thrown when the same file was saved to the database twice).
With rename, everything got moved, but the second time a file was accessed a
database file was thrown and the file completely disappeared. If I let my
process continue long enough all the output files went away.
I'm pretty sure what's happening is a race condition between the one
Camel thread moving a file and another one reading it again. You need to
hold you lock until Windows is finished moving the file.
> thread() and File Components
> ----------------------------
>
> Key: CAMEL-1670
> URL: https://issues.apache.org/activemq/browse/CAMEL-1670
> Project: Apache Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 2.0-M1
> Environment: Microsoft Windows XP
> Reporter: Joe Gottman
>
> I just experimented with adding calls to thread(10) to my route to make it
> multithreaded. This definitely speeds up by route, but it keeps throwing
> java.nio.channels.OverlappingFileLockException errors and leaving lock files
> behind it. The start of my route looks like
>
> from("file:\\startDirectory?move=endDirectory")
> .threads(10)
> .bean("myBean", "myMethod")
> Afterwards, my route ran successfully but an OverlappingFileLockException was
> thrown for every file that was read and all the lock files were left in my
> source directory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
