Return-Path: 
 <users-return-44398-apmail-camel-users-archive=camel.apache.org@camel.apache.org>
X-Original-To: apmail-camel-users-archive@www.apache.org
Delivered-To: apmail-camel-users-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 79E7C100C9
	for <apmail-camel-users-archive@www.apache.org>;
 Mon,  4 Nov 2013 22:06:21 +0000 (UTC)
Received: (qmail 37108 invoked by uid 500); 4 Nov 2013 22:06:20 -0000
Delivered-To: apmail-camel-users-archive@camel.apache.org
Received: (qmail 37075 invoked by uid 500); 4 Nov 2013 22:06:20 -0000
Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@camel.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@camel.apache.org>
List-Post: <mailto:users@camel.apache.org>
List-Id: <users.camel.apache.org>
Reply-To: users@camel.apache.org
Delivered-To: mailing list users@camel.apache.org
Received: (qmail 37067 invoked by uid 99); 4 Nov 2013 22:06:20 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Nov 2013 22:06:20 +0000
X-ASF-Spam-Status: No, hits=2.3 required=5.0
	tests=SPF_SOFTFAIL,URI_HEX
X-Spam-Check-By: apache.org
Received-SPF: softfail (nike.apache.org: transitioning domain of
 kelly.sethp@gmail.com does not designate 216.139.236.26 as permitted sender)
Received: from [216.139.236.26] (HELO sam.nabble.com) (216.139.236.26)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Nov 2013 22:06:14 +0000
Received: from [192.168.236.26] (helo=sam.nabble.com)
	by sam.nabble.com with esmtp (Exim 4.72)
	(envelope-from <kelly.sethp@gmail.com>)
	id 1VdSHS-0000kg-5V
	for users@camel.apache.org; Mon, 04 Nov 2013 14:05:54 -0800
Date: Mon, 4 Nov 2013 14:05:54 -0800 (PST)
From: skelly <kelly.sethp@gmail.com>
To: users@camel.apache.org
Message-ID: <1383602754083-5742613.post@n5.nabble.com>
Subject: inProgressRepository Not clearing for items in idempotentRepository
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

I'm attempting to consume messages from an FTP server using an idempotent
repository to ensure that I do not re-download a file unless it has been
modified.

Here is my (quite simple) camel configuration:
	<beans:bean id="downloadRepo"
class="org.apache.camel.processor.idempotent.FileIdempotentRepository" >
		<beans:property name="fileStore" value="/tmp/.repo.txt"/>
		<beans:property name="cacheSize" value="25000"/>
		<beans:property name="maxFileStoreSize" value="1000000"/>
	</beans:bean>

	<camelContext trace="true" xmlns="http://camel.apache.org/schema/spring">
		<endpoint id="myFtpEndpoint"
uri="ftp://me@localhost?password=****&binary=true&recursive=true&consumer.delay=15000&readLock=changed&passiveMode=true&noop=true&idempotentRepository=#downloadRepo&idempotentKey=$simple{file:name}-$simple{file:modified}"
/>
		<endpoint id="myFileEndpoint" uri="file:///tmp/files"/>

        <route>
            <from uri="ref:myFtpEndpoint" />
            <to uri="ref:myFileEndpoint" />
        </route>

When I start my application for the first time, all files are correctly
downloaded from the FTP server and stored in the target directory, as well
as recorded in the idempotent repo.

When I restart my application, all files are correctly detected as being in
the idempotent repo already on the first poll of the FTP server, and are not
re-downloaded:
13-11-04 16:52:10,811 TRACE [Camel (camel-1) thread #0 - ftp://me@localhost]
org.apache.camel.component.file.remote.FtpConsumer: FtpFile[name=test1.txt,
dir=false, file=true]
2013-11-04 16:52:10,811 TRACE [Camel (camel-1) thread #0 -
ftp://me@localhost] org.apache.camel.component.file.remote.FtpConsumer: This
consumer is idempotent and the file has been consumed before. Will skip this
file: RemoteFile[test1.txt]

However, on all subsequent polls to the FTP server the idempotent check is
short-circuited because the file is "in-progress":
2013-11-04 16:53:10,886 TRACE [Camel (camel-1) thread #0 -
ftp://me@localhost] org.apache.camel.component.file.remote.FtpConsumer:
FtpFile[name=test1.txt, dir=false, file=true]
2013-11-04 16:53:10,886 TRACE [Camel (camel-1) thread #0 -
ftp://me@localhost] org.apache.camel.component.file.remote.FtpConsumer:
Skipping as file is already in progress: test1.txt

I am using camel-ftp:2.11.1 (also observing same behavior with 2.12.1)  When
I inspect the source code I notice two interesting things.
First, the GenericFileConsumer check that determines whether a file is
already inProgress which is called from isValidFile() always adds the file
to the inProgressRepository:
    protected boolean isInProgress(GenericFile<T> file) {
        String key = file.getAbsoluteFilePath();
        return !endpoint.getInProgressRepository().add(key);
    }

Second, if a file is determined to match an entry already present in the
idempotent repository it is discarded (GenericFileConsumer.isValidFile()
returns false).  This means it is never published to an exchange, and thus
never reaches the code which would remove it from the inProgressRepository.

Since the inProgress check happens before the Idempotent Check, we will
always short circuit after we get into the inprogress state, and the file
will never actually be checked again.

Am I reading this code correctly?  Am I missing something here?  This seems
like a bug in the implementation of the isInProgress(GenericFile<T> file)
method to me.



--
View this message in context: http://camel.465427.n5.nabble.com/inProgressRepository-Not-clearing-for-items-in-idempotentRepository-tp5742613.html
Sent from the Camel - Users mailing list archive at Nabble.com.