You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by "Andreas A." <an...@gmail.com> on 2010/11/02 15:05:38 UTC
Does Camel respect another context's readLock?
Hi
I'm seeing some strange behaviour that I suspect might come from the fact
that I have two Camel-contexts in each it's own Camel Main competing over
the same files in a directory. What will actually happen when you let two
effectively seperate Camel applications loose at the same directory?
I get some nullpointer-exceptions because at some "random" point Camel reads
an empty file and tries to perform transformations on it.
I have this setup because I consume two types of files from a remote
directory. Then I have two contexts take care of each type of type. If one
context picks up an unknown type I throw an exception to roll back the file
to the remote dir. This is probably not the greatest idea either, but the
only one I could come up with.
--
View this message in context: http://camel.465427.n5.nabble.com/Does-Camel-respect-another-context-s-readLock-tp3246756p3246756.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Does Camel respect another context's readLock?
Posted by Claus Ibsen <cl...@gmail.com>.
There is a rollback in the DSL you can use (albeit its based on
exception as well)
On Fri, Nov 5, 2010 at 9:57 AM, Andreas A. <an...@gmail.com> wrote:
>
> Hi
>
> Yeah I agree, I use include/exclude in other areas but here I cannot since I
> don't have any control over the naming of the remote files. I have to look
> at their payload to determine it. Also sometimes files are not even "for me"
> so I have to roll those back too. I've been thinking about looking into
> org.apache.camel.component.file.GenericFileProcessStrategy to see if I can
> use for a cleaner way to roll back a file, instead of abusing exceptions for
> this behaviour.
>
> I discovered the real problem though, which was a matter of me sending a
> reference of the file to a seda route, then the original route ended and
> tried to rename the file to the .camel directory. Sometimes this would cause
> a race condition because an aggregator in the seda-route was using the file
> reference also.
> --
> View this message in context: http://camel.465427.n5.nabble.com/Does-Camel-respect-another-context-s-readLock-tp3246756p3251502.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: Does Camel respect another context's readLock?
Posted by "Andreas A." <an...@gmail.com>.
Hi
Yeah I agree, I use include/exclude in other areas but here I cannot since I
don't have any control over the naming of the remote files. I have to look
at their payload to determine it. Also sometimes files are not even "for me"
so I have to roll those back too. I've been thinking about looking into
org.apache.camel.component.file.GenericFileProcessStrategy to see if I can
use for a cleaner way to roll back a file, instead of abusing exceptions for
this behaviour.
I discovered the real problem though, which was a matter of me sending a
reference of the file to a seda route, then the original route ended and
tried to rename the file to the .camel directory. Sometimes this would cause
a race condition because an aggregator in the seda-route was using the file
reference also.
--
View this message in context: http://camel.465427.n5.nabble.com/Does-Camel-respect-another-context-s-readLock-tp3246756p3251502.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Does Camel respect another context's readLock?
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
You can use a include/exclude filter to ensure they dont compete for
the same files, which is IMHO much better.
Then A takes care of A files
And B takes care of B files
On Tue, Nov 2, 2010 at 3:05 PM, Andreas A. <an...@gmail.com> wrote:
>
> Hi
>
> I'm seeing some strange behaviour that I suspect might come from the fact
> that I have two Camel-contexts in each it's own Camel Main competing over
> the same files in a directory. What will actually happen when you let two
> effectively seperate Camel applications loose at the same directory?
>
> I get some nullpointer-exceptions because at some "random" point Camel reads
> an empty file and tries to perform transformations on it.
>
> I have this setup because I consume two types of files from a remote
> directory. Then I have two contexts take care of each type of type. If one
> context picks up an unknown type I throw an exception to roll back the file
> to the remote dir. This is probably not the greatest idea either, but the
> only one I could come up with.
> --
> View this message in context: http://camel.465427.n5.nabble.com/Does-Camel-respect-another-context-s-readLock-tp3246756p3246756.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/