Just to add to this for posterity and those that come after me :
The LockFile processing fires with a different exchange than the one that
gets propagated out of the camel ftp from() handler; hence
properties/headers set within the lock are not carried out of it.
The bam, after looking into it more, seems to not be applicable to this
situation due to the processing of the lock file all being done within the
context of the "from" frame. If I handle the locking as part of the route -
eg: from().when( header("lockFound" ) ) etc bam, I think would work.
My approach to this now, is to have the lock send a message to another
endpoint which will maintain a list of files processed and name/value pairs.
The first step in the route will then be to augment the properties based
upon the list.
On Sat, Mar 12, 2011 at 1:09 PM, Craig Taylor <ctalk...@ctalkobt.net> wrote:
> In looking at the bam I'm not sure I understand how I could use it.
>
> My current routes are generated dynamically and equate to something of the
> following form:
>
> from("ftp://"; ) - set GenericFileExclusiveReadLockStrategy for done file
> handling
> .to( stepA )
>
> .to( .... )
>
> If I create an ActivityBuilder on the route, at what step would I tell the
> bam to fire? THe GenericFileExclusiveReadLockStrategy will prevent the file
> from appearing until the file is available so the bam won't have a message /
> instance to trigger on.
>
>
>
>
> On Sat, Mar 12, 2011 at 7:56 AM, Claus Ibsen <claus.ib...@gmail.com>wrote:
>
>> On Fri, Mar 11, 2011 at 9:22 PM, Craig Taylor <ctalk...@ctalkobt.net>
>> wrote:
>> > Before I reinvent the wheel, for Camel 2.4 I'm attempting to check for
>> the
>> > following error conditions for done file handling:
>> >
>> > 1) Done file w/o corresponding regular file
>> > 2) Regular file w/o done file after period of time (say 5 minutes).
>> >
>> > I'm currently using a GenericFileExclusiveReadLockStrategy to check for
>> the
>> > done file and returns true in the acquireExclusiveReadLock if found.
>> >
>> > My current thinking for #1 is to treat it as a special case of #2 (I use
>> no
>> > pattern matching on the endpoints).
>> >
>> > I'd create a property on the exchange to define "LOCKFAIL" property for
>> > files that have failed to obtain a lock. My routes would then be
>> configured
>> > to check the exchange property and deal with it. (The LOCKFAIL would be
>> set
>> > based upon a filename, timer map w/in my current
>> > GenericFileExclusiveReadLockStrategy instance).
>> >
>> > Suggestions? This feels wrong based upon having to change all the
>> dependent
>> > routes..
>> >
>>
>> In terms of #2 you are maybe a bit into the world of BAM. eg to setup
>> some rules that a "done" file is expected, no later than X time after
>> that a new file arrived in the folder.
>> http://camel.apache.org/bam
>>
>> If you have some sort of BAM to do this, then you will not have to
>> adjust your routes to cater for LOCKFAIL.
>>
>>
>> In Camel you can also use an interceptFrom to detect that LOCKFAIL and
>> detour the message (and use skipSendToOriginalEndpoint). Then you dont
>> have to adjust your routes.
>> http://camel.apache.org/intercept
>>
>>
>>
>>
>>
>> > --
>> > -------------------------------------------
>> > Craig Taylor
>> > ctalk...@ctalkobt.net
>> >
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> FuseSource
>> Email: cib...@fusesource.com
>> Web: http://fusesource.com
>> Twitter: davsclaus
>> Blog: http://davsclaus.blogspot.com/
>> Author of Camel in Action: http://www.manning.com/ibsen/
>>
>
>
>
> --
> -------------------------------------------
>
> Craig Taylor
> ctalk...@ctalkobt.net
>
>
--
-------------------------------------------
Craig Taylor
ctalk...@ctalkobt.net
