Return-Path: 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 9F26A10BA6 for ; Mon, 5 Aug 2013 18:46:05 +0000 (UTC) Received: (qmail 1153 invoked by uid 500); 5 Aug 2013 18:46:05 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 822 invoked by uid 500); 5 Aug 2013 18:46:04 -0000 Mailing-List: contact users-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@camel.apache.org Delivered-To: mailing list users@camel.apache.org Received: (qmail 811 invoked by uid 99); 5 Aug 2013 18:46:03 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Aug 2013 18:46:03 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of bibryam@gmail.com designates 209.85.212.178 as permitted sender) Received: from [209.85.212.178] (HELO mail-wi0-f178.google.com) (209.85.212.178) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Aug 2013 18:45:59 +0000 Received: by mail-wi0-f178.google.com with SMTP id j17so1882313wiw.5 for ; Mon, 05 Aug 2013 11:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=yt8tyE3FBt0P3VFK+OmF03nXVZj40WIUUmHofkxASUg=; b=e/0ox7a3eUQeBCdPWNicN8jhVZlIDiyYBoclrhFFinLXTJE/i8jgGlFIP7N5pHjv9F qIxdYYpqP+mmARAvOXu9QFT9b0kuYCWfvY2ff+yBriV3p/i0igSMM8y0xceLnXg1w8lP efuNsHdpDtF6t8AlVpjUFBe5CdZ4BTnYqENz57CvM1wsL1z4G3TXwM7DlS2dv0zrU/4n zZks8QJoHgKyz8VNlhU0n8TF9wgKywQjBNasHS/vQz9b5fE1u9vSmCN2jGQLniPplAiJ eLsEaQ+C1cN6CmwwAnKwINI9KUWmDhRlT3INdd5gIz9N/G+O3tNbfvkCz9/FnCto4yMC PfeQ== MIME-Version: 1.0 X-Received: by 10.180.206.97 with SMTP id ln1mr7699551wic.39.1375728338033; Mon, 05 Aug 2013 11:45:38 -0700 (PDT) Received: by 10.216.202.134 with HTTP; Mon, 5 Aug 2013 11:45:37 -0700 (PDT) Received: by 10.216.202.134 with HTTP; Mon, 5 Aug 2013 11:45:37 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Aug 2013 19:45:37 +0100 Message-ID: Subject: Re: Unit of Work Scope and direct/SEDA/vm components From: Bilgin Ibryam To: users@camel.apache.org Content-Type: multipart/alternative; boundary=001a11c25cc2e5657d04e337b6a1 X-Virus-Checked: Checked by ClamAV on apache.org --001a11c25cc2e5657d04e337b6a1 Content-Type: text/plain; charset=ISO-8859-1 Hi, The file component uses onCompletion for moving files after the exchange has completed. As long as the completions are passed with the exchange the files wont move. The VM component passes the completions to the next camel context so the files are not moved... You have to use a queue or something like wiretap to stop completions. HTH Bilgin Sent from mobile On 5 Aug 2013 18:07, "Scott Parkerson" wrote: > Hi, fellow Camel riders. > > I was wondering where Camel's notion of UnitOfWork begins and ends with > respect to processing a route or set of routes. > > For example, I have a route that starts with a SFTP poller that consumes > files off of a server. The contents of these files are then handed to > another route via the direct component, which is responsible for filtering > and routing the data to other processors that are on multiple camel > contexts. As such, I have been using the vm component to pass that data to > the appropriate processing route. > > What's strange is that it seems like the files are not marked as processed > (i.e. the original SFTP component does not move the files to the processed > directory until the message is completely handled by the second route. This > is a problem because the second route actually splits and aggregates data > in the file, and, as such, the data may not be released from the aggregator > until later. Furthermore, the SFTP connection in the body may not be valid > anymore, and even if it is, it seems like splitting the data also splits > the notion that that data came from a SFTP consumer, which makes lots of > stack traces. > > What I want to know is: how can I make sure that the file on the SFTP > server is marked processed before it goes off to the handling route? Do I > need to send the data to a file or an JMS/ActiveMQ queue first? > > Thanks, > Scott Parkerson > --001a11c25cc2e5657d04e337b6a1--