Return-Path: Delivered-To: apmail-camel-users-archive@www.apache.org Received: (qmail 13377 invoked from network); 12 Oct 2009 08:15:47 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 12 Oct 2009 08:15:47 -0000 Received: (qmail 88247 invoked by uid 500); 12 Oct 2009 08:15:47 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 88192 invoked by uid 500); 12 Oct 2009 08:15:47 -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 88182 invoked by uid 99); 12 Oct 2009 08:15:47 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Oct 2009 08:15:47 +0000 X-ASF-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates 216.139.236.158 as permitted sender) Received: from [216.139.236.158] (HELO kuber.nabble.com) (216.139.236.158) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Oct 2009 08:15:44 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1MxG3v-0001il-Ln for users@camel.apache.org; Mon, 12 Oct 2009 01:15:23 -0700 Message-ID: <25851978.post@talk.nabble.com> Date: Mon, 12 Oct 2009 01:15:23 -0700 (PDT) From: Vladimir Okhotnikov To: users@camel.apache.org Subject: Re: File component blocked by existing files In-Reply-To: <5380c69c0910112323k494fee65na2be74595f44a73f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: vokhotnikov@gmail.com References: <25803233.post@talk.nabble.com> <5380c69c0910080801ga07e1bdmd5098cc3e0239ec0@mail.gmail.com> <25806158.post@talk.nabble.com> <5380c69c0910082314l6cfb211q8424d4a7e1ada2e9@mail.gmail.com> <25833119.post@talk.nabble.com> <5380c69c0910112323k494fee65na2be74595f44a73f@mail.gmail.com> Yes, I known about the readLockTimeout option. The problem with this option is that by a) default it waits forever and b) while it waits for one file it does not process others. That's what made me spend 2 days wondering about the behavior described in the thread almost without clues, and it will made others. As is pretty well explained in the "Release It" book, infinite waits are bad. Infinite waits by default are very bad, especially in integration software - it virtually guarantees that at least one will slip into your live system, then it's just a matter of time until it blocks critical function or critical amount of resources - and you're waken in the middle of the night to deal with it. What do you think? Claus Ibsen-2 wrote: > > > You can already do this by the readLockTimeout option. See more details > here: > http://camel.apache.org/file2.html > > For example you can set it to 10000 as 10 seconds and if Camel cannot > acquire the lock within that period it will skip this file and try the > next one. > > -- > Claus Ibsen > Apache Camel Committer > > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > Twitter: http://twitter.com/davsclaus > > -- View this message in context: http://www.nabble.com/File-component-blocked-by-existing-files-tp25803233p25851978.html Sent from the Camel - Users mailing list archive at Nabble.com.