Sorry for the poor English - I know about the timeout option now - I saw it immediately AFTER I found the reason. I obviously saw the option before, among others, but did not pay enough attention to realize I should not use the default.
And I did have the camel DEBUG level enabled - was the first thing I have done to debug the problem - and it did not help me at all - there were no relevant messages at all - and the DEBUG logging did work - I get a log of all routes on camel start etc. Claus, I'm not trying to blame or rant or something. I still think the framework is awesome. I apologize if I somehow made you think I'm feeling different. I just truly believe that infinite waits by default should be ruthlessly eliminated, and doing this will benefit the Camel and its users a great deal. Claus Ibsen-2 wrote: > > On Mon, Oct 12, 2009 at 10:15 AM, Vladimir Okhotnikov > <vokhotni...@gmail.com> wrote: >> >> 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. > > You did not mention that you knew this option and why have you not > tried using it? > > Camel does TRACE / DEBUG logging which you could have enabled. > > Which is also written on the file component wiki page > http://camel.apache.org/file2.html > > Debug logging > This component has log level TRACE that can be helpful if you have > problems. > > So if you have done that you would NOT have been in the dark for 2 days. > > > > The file consumer is NOT concurrent. So yes it will wait. > > If you want concurrency then define multiple routes with a file > consumer. Which btw is not fun as file system is not transactional and > having multiple consumers racing for the same files is not fun. > > > Good idea about the default timeout which I have created a ticket for > https://issues.apache.org/activemq/browse/CAMEL-2062 > > > >> >> 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. >> >> > > > > -- > 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-tp25803233p25853488.html Sent from the Camel - Users mailing list archive at Nabble.com.
