Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Date: Tue, 22 Mar 2011 12:47:05 +0000 (UTC)
From: "Maria Iracheta (JIRA)" <jira@apache.org>
To: dev@camel.apache.org
Message-ID: 
 <717082660.3647.1300798025749.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1472133264.11661.1300457429499.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (CAMEL-3789)
 org.apache.camel.component.file.strategy.MarkerFileExclusiveReadLockStrategy
 is not thread-safe
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CAMEL-3789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Maria Iracheta updated CAMEL-3789:
----------------------------------

    Attachment: MarkerFileExclusiveReadLockStrategy.java.patch

This readLockStrategy was not thread-safe. It was unlocking the last File that had been locked. Now each of the methods recreates the lock file based on the input attributes

> 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: MarkerFileExclusiveReadLockStrategy.java.patch
>
>
> 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