You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by fidoedidoe <ga...@sagepub.co.uk> on 2014/11/25 13:40:53 UTC
FTP2 consumer (SFTP), using "localWorkDirectory" option - local
file not deleted
Hi
I'm using a FTP2 consumer for SFTP on a linux OS implementation. Due the the
size of the source file (gigabytes), I'm using the option
"localWorkDirectory". According to the camel documentation
<http://camel.apache.org/ftp2.html> the local local file should be deleted
on Exchange completion. Excerpt from documentation:
Using Local Work Directory
/Camel supports consuming from remote FTP servers and downloading the files
directly into a local work directory. This avoids reading the entire remote
file content into memory as it is streamed directly into the local file
using FileOutputStream.
Camel will store to a local file with the same name as the remote file,
though with .inprogress as extension while the file is being downloaded.
Afterwards, the file is renamed to remove the .inprogress suffix. And
finally, when the Exchange is complete the local file is deleted./
What I'm finding is the (local) file persists (in my case in the folder:
/tmp/) after the route processing has completed. Does anyone know whether my
interpretation of the documentation is correct and the local file created
should be deleted - or will I have to create my own process to remove the
local file (either in bash / with camel)?
I have included a (pseudo) representation of the XML DSL I'm using is below.
Any insight on best practice for the localWorkDirectory option would be most
welcomed.
Many thanks!
--
View this message in context: http://camel.465427.n5.nabble.com/FTP2-consumer-SFTP-using-localWorkDirectory-option-local-file-not-deleted-tp5759581.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: FTP2 consumer (SFTP), using "localWorkDirectory" option - local
file not deleted
Posted by fidoedidoe <ga...@sagepub.co.uk>.
Hi Claus
Just to confirm the failure to remove the file from the /tmp/ folder *was*
related to the removal of the file name headers (<removeHeaders
pattern="CamelFile*" />). To work around this I change my pseudo
configuration that shown below. In summary I just encapsulated the
<removeheaders/>, smtp, etc into an <onCompletion onCompleteOnly="true">
block within the multicast route definition. I now get a completion email
(without header metadata), while still maintaining the tmp file
(localWorkDirectory=/tmp) is removed when the route / exchange has
completed.
Many thanks for taking the time and guiding me back onto the right path.
--
View this message in context: http://camel.465427.n5.nabble.com/FTP2-consumer-SFTP-using-localWorkDirectory-option-local-file-not-deleted-tp5759581p5759643.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: FTP2 consumer (SFTP), using "localWorkDirectory" option - local
file not deleted
Posted by Claus Ibsen <cl...@gmail.com>.
It could be because you remove the file name headers, try not doing that.
On Tue, Nov 25, 2014 at 4:01 PM, fidoedidoe <ga...@sagepub.co.uk> wrote:
> Hi Claus
>
> Many thanks for your reply. After a small series of tests, I'm concluding
> that my desire to send a single "on completion" email when the muticast
> completes is the the direct / indirect cause for the local file delete to
> fail.
>
> The modified XML DSL below reflects my real world scenario more closely.
> You'll see that within the MultiCast near the end I (a) set a new message
> body (b) remove headers using a pattern camel*. before (c) sending a smtp
> email confirmation.
>
> Item (b) was a late addition to my configuration to remove unwanted route
> information from the body of the email notification. I'm pretty confident
> that the inclusion of that the line: <removeHeaders pattern="CamelFile*" />
> if the cause for the local file deletion to fail (because i've destroyed the
> metadata needed to remove the file?)
>
> I'm now wondering how to achieve my desired scenario: send a single email
> indicating the multicast has finished successfully (not an email for each
> route), with an email body that doesn't have unwanted route metadata -while
> still allowing the clean up of my local file?!
>
> any suggestions?
>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/FTP2-consumer-SFTP-using-localWorkDirectory-option-local-file-not-deleted-tp5759581p5759591.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/
Re: FTP2 consumer (SFTP), using "localWorkDirectory" option - local
file not deleted
Posted by fidoedidoe <ga...@sagepub.co.uk>.
Hi Claus
Many thanks for your reply. After a small series of tests, I'm concluding
that my desire to send a single "on completion" email when the muticast
completes is the the direct / indirect cause for the local file delete to
fail.
The modified XML DSL below reflects my real world scenario more closely.
You'll see that within the MultiCast near the end I (a) set a new message
body (b) remove headers using a pattern camel*. before (c) sending a smtp
email confirmation.
Item (b) was a late addition to my configuration to remove unwanted route
information from the body of the email notification. I'm pretty confident
that the inclusion of that the line: <removeHeaders pattern="CamelFile*" />
if the cause for the local file deletion to fail (because i've destroyed the
metadata needed to remove the file?)
I'm now wondering how to achieve my desired scenario: send a single email
indicating the multicast has finished successfully (not an email for each
route), with an email body that doesn't have unwanted route metadata -while
still allowing the clean up of my local file?!
any suggestions?
--
View this message in context: http://camel.465427.n5.nabble.com/FTP2-consumer-SFTP-using-localWorkDirectory-option-local-file-not-deleted-tp5759581p5759591.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: FTP2 consumer (SFTP), using "localWorkDirectory" option - local
file not deleted
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Try without multicast and to make the route as simple to see if the
file gets deleted.
On Tue, Nov 25, 2014 at 1:40 PM, fidoedidoe <ga...@sagepub.co.uk> wrote:
> Hi
>
> I'm using a FTP2 consumer for SFTP on a linux OS implementation. Due the the
> size of the source file (gigabytes), I'm using the option
> "localWorkDirectory". According to the camel documentation
> <http://camel.apache.org/ftp2.html> the local local file should be deleted
> on Exchange completion. Excerpt from documentation:
>
> Using Local Work Directory
>
> /Camel supports consuming from remote FTP servers and downloading the files
> directly into a local work directory. This avoids reading the entire remote
> file content into memory as it is streamed directly into the local file
> using FileOutputStream.
> Camel will store to a local file with the same name as the remote file,
> though with .inprogress as extension while the file is being downloaded.
> Afterwards, the file is renamed to remove the .inprogress suffix. And
> finally, when the Exchange is complete the local file is deleted./
>
> What I'm finding is the (local) file persists (in my case in the folder:
> /tmp/) after the route processing has completed. Does anyone know whether my
> interpretation of the documentation is correct and the local file created
> should be deleted - or will I have to create my own process to remove the
> local file (either in bash / with camel)?
>
> I have included a (pseudo) representation of the XML DSL I'm using is below.
>
> Any insight on best practice for the localWorkDirectory option would be most
> welcomed.
>
> Many thanks!
>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/FTP2-consumer-SFTP-using-localWorkDirectory-option-local-file-not-deleted-tp5759581.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
hawtio: http://hawt.io/
fabric8: http://fabric8.io/