Return-Path: X-Original-To: apmail-camel-issues-archive@minotaur.apache.org Delivered-To: apmail-camel-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E144A18624 for ; Sun, 12 Jul 2015 14:06:04 +0000 (UTC) Received: (qmail 35707 invoked by uid 500); 12 Jul 2015 14:06:04 -0000 Delivered-To: apmail-camel-issues-archive@camel.apache.org Received: (qmail 35662 invoked by uid 500); 12 Jul 2015 14:06:04 -0000 Mailing-List: contact issues-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@camel.apache.org Delivered-To: mailing list issues@camel.apache.org Received: (qmail 35653 invoked by uid 99); 12 Jul 2015 14:06:04 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 12 Jul 2015 14:06:04 +0000 Date: Sun, 12 Jul 2015 14:06:04 +0000 (UTC) From: "Claus Ibsen (JIRA)" To: issues@camel.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (CAMEL-8954) Lock information is not handovered together with Exchange on-completion synchronizations MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CAMEL-8954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14623820#comment-14623820 ] Claus Ibsen commented on CAMEL-8954: ------------------------------------ This is not really intended to do such use-case. > Lock information is not handovered together with Exchange on-completion synchronizations > ---------------------------------------------------------------------------------------- > > Key: CAMEL-8954 > URL: https://issues.apache.org/jira/browse/CAMEL-8954 > Project: Camel > Issue Type: Bug > Components: camel-core > Affects Versions: 2.14.3 > Reporter: Andy Fedotov > Priority: Minor > Attachments: MarkerFileExclusiveReadLockStrategyUnlockTest.java > > > This applies to the file components when using common read-lock strategies: > - *markerFile* - org.apache.camel.component.file.strategy.MarkerFileExclusiveReadLockStrategy > - *fileLock* - org.apache.camel.component.file.strategy.FileLockExclusiveReadLockStrategy > This strategies stores lock information in the Exchange properties: > - *Exchange.FILE_LOCK_FILE_ACQUIRED* == "CamelFileLockFileAcquired" > - *Exchange.FILE_LOCK_FILE_NAME* == "CamelFileLockFileName" > - *Exchange.FILE_LOCK_EXCLUSIVE_LOCK* == "CamelFileLockExclusiveLock" > - *Exchange.FILE_LOCK_RANDOM_ACCESS_FILE* == "CamelFileLockRandomAccessFile" > Lock information is stored as scalar values and can hold information about _only one single lock_. > When there are two Exchanges participates in the route, share UoW, and synchronizations are handovered from one Exchange to another, information about both locks can't be stored in the Exchange properties and lost. Consequently when on-completion synchronizations are performed, read-lock strategies can't access information about all the locks and they are not released. > For example, after completing this route lock for file1.dat is not released: > {code:java} > from("file:data/input-a?fileName=file1.dat&readLock=markerFile") > .pollEnrich("file:data/input-b?fileName=file2.dat&readLock=markerFile") > .to("mock:result"); > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)