Results with 3.1 . Flow is SEDA. I had to remove workManager property from my file Poller.
VFS => VFS : I transferred 100+ files which is far better but again, it stopped processing the file (I had 200+ in my FTP server). There is no error. The flow is FTP => Router => Transform => FTP and it just stops at the process at the Transform component after a while. I really don't understand this random behavior andit is quite a pain to test all version/components/flows/case to isolate a possible problem. LW in 3.0, LW in 3.1 and JBI FTP in 3.1 I have some java.io.IOException: No output stream available for output name: hello.txt. Maybe the file already exists? -it doesn't. I have double checked I removed my fileName wrong code. To be even more sure I used the provided BinaryFileMarshaler and a simple FTP => directly to FTP flow without any other steps. Same thing. Please check by your side, it seems there is a bug in there, before I raise a JIRA. mart wrote: > > Ok I just tested even with the 3.0 version I was wrong with the fileName > stuff, unfortunately as I thought it is not the source of my problem. In > 3.0 I tested all possibilities with VFS and LW FTP component (VFS => LW, > LW=> LW, etc.) and none is giving me a good result. Either it stops > processing files without any errors (file which are processed are ok) or > it throws an IO Exception on some files, not everyone, the result is a > bunch of files which are correctly transfered (few), lot of empty files, > and some which aren't processed at all, then it stops processing. first > case happen when writing with VFS and second one, worse, with LW. Polling > with VFS or LW doesn't seem to change anything. > > I also tried to force a JMS Flow instead of SEDA and if there is a > difference. there is, SEDA stops earlier than JMS... > > Now I'll go back to the 3.1 version doing same kinds of test plus JBI FTP > Component... > > > > gnodet wrote: >> >> On 11/14/06, mart <[EMAIL PROTECTED]> wrote: >>> >>> This code retrieve the file name (String) in the message -which is set >>> as a >>> property when it is created: message.getProperty(FILE_NAME_PROPERTY) >>> >>> The fileName property of the Marshaler is an Expression and not a >>> String, so >>> I create an Expression from this String. This seems to work well before. >>> This is a ConstantExpression but the name in this scope is constant (the >>> string) and I create a new one each time the writeMessage is executed. I >>> don't really see the problem in this. >> >> The problem is that the output stream is created before the writeMessage >> is called. The file name is determined by the call to getOutputName. >> So changing the file name in the writeMessage will not work for this >> reason. >> The other reason is that the Marshaler must be thread-safe, and your >> code is not: the expression must not change during the lifetime of >> the Marshaler. >> Note that the default expression value is set to >> new PropertyExpression(FILE_NAME_PROPERTY) >> which exactly do what you want. ConstantExpression, as the name >> indicates, should remain constant ;) >> >>> >>> Anyway as you say this is not needed but in 3.0, I think it was. It >>> didn't >>> set the fileName automatically. I use the same marshaler with lw FTP and >>> vfs >>> without problem with file names. >>> >>> I tested without it. this doesn't solve my problem...so...Weird. >>> >>> Concerning lw in 3.1 and vfs it works really well if I have 1, 2, 5, or >>> max. >>> 10 files in my FTP repository but more files will make smix act crazy... >>> >> >> If crazy means that all the files are processed concurrently, you should >> be able to tune that. See >> http://servicemix.goopen.org/site/thread-pools.html >> >>> >>> >>> >>> >>> >>> gnodet wrote: >>> > >>> > On 11/14/06, mart <[EMAIL PROTECTED]> wrote: >>> >> >>> >> I set the output name file from the message's FILE_NAME_PROPERTY: >>> >> >>> >> this.setFileName(new >>> >> ConstantExpression(message.getProperty(FILE_NAME_PROPERTY))); >>> > >>> > I don''t really understand this code. >>> > The ConstantExpression will always return the same value, so this >>> > may be related to your problem. >>> > The default expression will already retrieve the file name from >>> > the FILE_NAME_PROPERTY property on the exchange. >>> > >>> > Also, the writeMessage is given an OutputStream, so the name has >>> > to be chosen before by (eventually) overriding the getOutputName >>> > method. >>> > >>> > -- >>> > Cheers, >>> > Guillaume Nodet >>> > >>> > >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/Problem-using-VFS-with-FTP-tf2602487s12049.html#a7339221 >>> Sent from the ServiceMix - User mailing list archive at Nabble.com. >>> >>> >> >> >> -- >> Cheers, >> Guillaume Nodet >> >> > > -- View this message in context: http://www.nabble.com/Problem-using-VFS-with-FTP-tf2602487s12049.html#a7355779 Sent from the ServiceMix - User mailing list archive at Nabble.com.
