Re: servicemix-ftp: FtpPollingEndpoint?
Currently, the same pattern as for lightweight components can be used. You can define a BinaryFileMarshaler implementation on the endpoint: The DefaultFileMarshaler and BinaryFileMarshaler only send streams (on top of the file or underlying ftp connection), so there should be no memory problems. What are you referring to ? One enhancement would be to use an asynchronous send instead of a sendSync to avoid blocking threads, but it's another problem. On 10/30/06, abrighton <[EMAIL PROTECTED]> wrote: What is the best way to deal with files that are not XML in the ftp and file polling components? Send them as attachments? Are you working on anything in that direction? I suppose it could be a property of the endpoint class, configured in xbean.xml: wrapFiles="true"... The other issue is how to deal with large files that you don't want to have multiple times in memory, but that is another issue. Maybe that could be another property setting, indicating to use some kind of reference to the file instead of the file itself? -- Allan -- View this message in context: http://www.nabble.com/servicemix-ftp%3A-FtpPollingEndpoint--tf2540539.html#a7083459 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet
Re: servicemix-ftp: FtpPollingEndpoint?
Thanks for the tip about the binaryFileMarshaler. I didn't realize you could do it that way. As for the memory usage: I was assuming that at some point the entire file would be read into memory. If this is not the case, it should not be a problem. -- Allan gnodet wrote: > > Currently, the same pattern as for lightweight components can be > used. You can define a BinaryFileMarshaler implementation > on the endpoint: > > > > > > > The DefaultFileMarshaler and BinaryFileMarshaler only send streams > (on top of the file or underlying ftp connection), so there should be > no memory problems. What are you referring to ? > > One enhancement would be to use an asynchronous send instead of > a sendSync to avoid blocking threads, but it's another problem. > > On 10/30/06, abrighton <[EMAIL PROTECTED]> wrote: >> >> What is the best way to deal with files that are not XML in the ftp and >> file >> polling components? >> Send them as attachments? Are you working on anything in that direction? >> I >> suppose it could >> be a property of the endpoint class, configured in xbean.xml: >> wrapFiles="true"... >> >> The other issue is how to deal with large files that you don't want to >> have >> multiple times in memory, >> but that is another issue. Maybe that could be another property setting, >> indicating to use some kind >> of reference to the file instead of the file itself? >> >> -- >> Allan >> >> -- >> View this message in context: >> http://www.nabble.com/servicemix-ftp%3A-FtpPollingEndpoint--tf2540539.html#a7083459 >> Sent from the ServiceMix - Dev mailing list archive at Nabble.com. >> >> > > > -- > Cheers, > Guillaume Nodet > > -- View this message in context: http://www.nabble.com/servicemix-ftp%3A-FtpPollingEndpoint--tf2540539.html#a7084079 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
Re: servicemix-ftp: FtpPollingEndpoint?
On 10/30/06, abrighton <[EMAIL PROTECTED]> wrote: Thanks for the tip about the binaryFileMarshaler. I didn't realize you could do it that way. The marshaler is the easiest way to customize the behavior of endpoints. As for the memory usage: I was assuming that at some point the entire file would be read into memory. If this is not the case, it should not be a problem. It can be, usually if the target component need that to process the incoming exchange, but the BC themselves won't. -- Allan gnodet wrote: > > Currently, the same pattern as for lightweight components can be > used. You can define a BinaryFileMarshaler implementation > on the endpoint: > > > > > > > The DefaultFileMarshaler and BinaryFileMarshaler only send streams > (on top of the file or underlying ftp connection), so there should be > no memory problems. What are you referring to ? > > One enhancement would be to use an asynchronous send instead of > a sendSync to avoid blocking threads, but it's another problem. > > On 10/30/06, abrighton <[EMAIL PROTECTED]> wrote: >> >> What is the best way to deal with files that are not XML in the ftp and >> file >> polling components? >> Send them as attachments? Are you working on anything in that direction? >> I >> suppose it could >> be a property of the endpoint class, configured in xbean.xml: >> wrapFiles="true"... >> >> The other issue is how to deal with large files that you don't want to >> have >> multiple times in memory, >> but that is another issue. Maybe that could be another property setting, >> indicating to use some kind >> of reference to the file instead of the file itself? >> >> -- >> Allan >> >> -- >> View this message in context: >> http://www.nabble.com/servicemix-ftp%3A-FtpPollingEndpoint--tf2540539.html#a7083459 >> Sent from the ServiceMix - Dev mailing list archive at Nabble.com. >> >> > > > -- > Cheers, > Guillaume Nodet > > -- View this message in context: http://www.nabble.com/servicemix-ftp%3A-FtpPollingEndpoint--tf2540539.html#a7084079 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet
[jira] Created: (SM-726) Upgrade to backport-util-concurrent 2.2
Upgrade to backport-util-concurrent 2.2 --- Key: SM-726 URL: https://issues.apache.org/activemq/browse/SM-726 Project: ServiceMix Issue Type: Improvement Reporter: Guillaume Nodet Fix For: 3.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SM-726) Upgrade to backport-util-concurrent 2.2
[ https://issues.apache.org/activemq/browse/SM-726?page=all ] Guillaume Nodet resolved SM-726. Resolution: Fixed Assignee: Guillaume Nodet Author: gnodet Date: Mon Oct 30 14:43:29 2006 New Revision: 469310 URL: http://svn.apache.org/viewvc?view=rev&rev=469310 Log: SM-726: Upgrade to backport-util-concurrent 2.2 Modified: incubator/servicemix/trunk/pom.xml > Upgrade to backport-util-concurrent 2.2 > --- > > Key: SM-726 > URL: https://issues.apache.org/activemq/browse/SM-726 > Project: ServiceMix > Issue Type: Improvement >Reporter: Guillaume Nodet > Assigned To: Guillaume Nodet > Fix For: 3.1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
