camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bilgin Ibryam <>
Subject Re: Unit of Work Scope and direct/SEDA/vm components
Date Mon, 05 Aug 2013 18:45:37 GMT
The file component uses onCompletion for moving files after the exchange
has completed. As long as the completions are passed with the exchange the
files wont move. The VM component passes the completions to the next camel
context so the files are not moved... You have to use a queue or something
like wiretap to stop completions.


Sent from mobile
On 5 Aug 2013 18:07, "Scott Parkerson" <> wrote:

> Hi, fellow Camel riders.
> I was wondering where Camel's notion of UnitOfWork begins and ends with
> respect to processing a route or set of routes.
> For example, I have a route that starts with a SFTP poller that consumes
> files off of a server. The contents of these files are then handed to
> another route via the direct component, which is responsible for filtering
> and routing the data to other processors that are on multiple camel
> contexts. As such, I have been using the vm component to pass that data to
> the appropriate processing route.
> What's strange is that it seems like the files are not marked as processed
> (i.e. the original SFTP component does not move the files to the processed
> directory until the message is completely handled by the second route. This
> is a problem because the second route actually splits and aggregates data
> in the file, and, as such, the data may not be released from the aggregator
> until later. Furthermore, the SFTP connection in the body may not be valid
> anymore, and even if it is, it seems like splitting the data also splits
> the notion that that data came from a SFTP consumer, which makes lots of
> stack traces.
> What I want to know is: how can I make sure that the file on the SFTP
> server is marked processed before it goes off to the handling route? Do I
> need to send the data to a file or an JMS/ActiveMQ queue first?
> Thanks,
> Scott Parkerson

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message