[
https://issues.apache.org/jira/browse/CAMEL-3789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maria Iracheta updated CAMEL-3789:
----------------------------------
Attachment: MarkerFileExclusiveReadLockStrategyTest.java
Junit class to test the MarkerFileExclusiveReadLockStrategy in a multithreaded
scenario
> org.apache.camel.component.file.strategy.MarkerFileExclusiveReadLockStrategy
> is not thread-safe
> -----------------------------------------------------------------------------------------------
>
> Key: CAMEL-3789
> URL: https://issues.apache.org/jira/browse/CAMEL-3789
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 2.6.0
> Reporter: Maria Iracheta
> Attachments: FileOperations.java.patch,
> GenericFileDeleteProcessStrategy.java.patch,
> GenericFileRenameProcessStrategy.java.patch,
> MarkerFileExclusiveReadLockStrategy.java.patch,
> MarkerFileExclusiveReadLockStrategyTest.java
>
>
> MarkerFileExclusiveReadLockStrategy is not thread-safe. When I run a File
> endpoint with more than one thread the MarkerFileExclusiveReadLockStrategy
> only deletes the last file to start being processed.
> The MarkerFileExclusiveReadLockStrategy uses global variables:
> private File lock;
> private String lockFileName;
> and gives them values on the acquireExclusiveReadLock method. When another
> thread calls the releaseExclusiveReadLock method it uses the global variables
> to delete the locked file. That means that if another thread came and called
> the acquireExclusiveReadLock it would have changed the values on the global
> variables.
> If lock and lockFileName are not global variables the problem seems to
> disappear and I can a multithreaded File endpoint and not locked file is left
> undeleted.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
