> And the other Camel is picking up that file. Eg it get processed?
> So the failed to rename is a race condition because the other Camel
> grabbed the same file, but was faster to do the rename?
We believe this is what is happening. Even with readLock option two
instances pick the same file an
On Wed, Mar 6, 2013 at 6:40 AM, vss123 wrote:
> Sorry. The Camel version we use is 2.10.3.
>
> We have a drop-zone in a file system where the other systems drop xml files.
>
> With this project we use camel to pickup these files and do processing to
> communicate with few other systems. We want to
Sorry. The Camel version we use is 2.10.3.
We have a drop-zone in a file system where the other systems drop xml files.
With this project we use camel to pickup these files and do processing to
communicate with few other systems. We want to run multiple instances of our
project, so that we can pr
On Tue, Mar 5, 2013 at 11:16 AM, vss123 wrote:
> Hi,
>
> We also tried using preMove to avoid multiple instances of Camel picking the
> same file. But that does not seem to work. When we run with more than one
> instance, We get following error.
>
> cannot begin processing file: GenericFile[sample
Hi,
We also tried using preMove to avoid multiple instances of Camel picking the
same file. But that does not seem to work. When we run with more than one
instance, We get following error.
cannot begin processing file: GenericFile[sample1.xml] due to: Cannot rename
file: GenericFile[sample1.xml]
Cool - thanks a lot. Yes, seems like preMove is a bit special indeed - it
addresses technical issue of concurrency as opposed to functional
requirements of file placement after processing...
Pavel
On Wed, Jul 28, 2010 at 12:31 PM, Claus Ibsen wrote:
> I created a ticket to track this
> https://i
I created a ticket to track this
https://issues.apache.org/activemq/browse/CAMEL-3003
And you can now use preMove together with noop|delete.
On Tue, Jul 27, 2010 at 2:50 PM, Claus Ibsen wrote:
> Hi
>
> What if preMove is a bit special. So you can do
> preMove=moveMe&noop=true. Which then tells
Hi
What if preMove is a bit special. So you can do
preMove=moveMe&noop=true. Which then tells Camel to pre move the file.
But on commit it should just leave the file as is.
On Fri, Jul 23, 2010 at 12:05 PM, Pavel wrote:
> That doesn't work, since by the time route completes, file is moved
> el
Hi
Yeah the file component is starting to be overloaded with
move/delete/noop options :)
Maybe the noop should have been an action option, so you could specify
what you want to do
action=preMove
action=preMove,move
action=preMove,delete
action=noop
action=delete
action=move (* default)
Let's t
That doesn't work, since by the time route completes, file is moved
elsewhere.
Do you think preMove-only could be useful extension? I know it is useful for
me, but not sure how typical such requirement is.
If so, I could e.g. add ${null} simple expressions, or "noMove=true" to file
component.
Th
Hi
Have you tried with move=. to indicate current folder?
But no its, not a feature of camel to only pre move and then noop.
On Fri, Jul 23, 2010 at 9:03 AM, Pavel wrote:
> Hi,
>
> Is it possible to pre-move files, but not move them once processing
> complete? I use "preMove" to ensure camel
11 matches
Mail list logo
