|
I'm getting the same problem (but not as consistent) on a different environment:
Windows Vista SR1 The error occurs sporadically, and as a result the ftp fetcher will stop to transfer files until a restart of Mule. I can make the error go away by modifying FtpConnector.getFtp() such that it always returns a new FTPClient. This is not an acceptable solution, however, since it is pretty heavy on resources. However, this indicates that the problem might have to do with FTPClient objects being returned to the pool in an inconsistent state.
I'm getting the same problem with mule 2.0.2 and 2.0.0 on Mac OS 10.4.11
java -version java version "1.5.0_13" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241) Java HotSpot(TM) Client VM (build 1.5.0_13-121, mixed mode, sharing) I'm also getting the same problem with mule 2.0.2 (Unknown parser type: CWD command successful).
java 1.6.0_06 My ftp server is vsftp on fedora core 9 We need to take a closer look at this one see if there is a specific bug causing this and fix it in 2.1.n maintenance if there is.
Step to reproduce this error with 100% certainty:
It will always fetch the first file successfully and then fail with 250 on all the subsequent files. Same problem here using WSFTP server on XP.
15:44:49,200 | ERROR | org.mule.DefaultExceptionStrategy | 395 | Caught exception in Exception Strategy: Unknown parser type: CWD successful. "/incoming" is current directory. Running the latest 2.1.1 community release I think I've located the error.
Actually, by studying the diff between 1.4 and 2.x, I found out that 1.4 provided either a streamed version or a non streamed version. Could someone test this with Mule 1.4 when activation the streaming mode? "Patch": Raising to critical based on number of votes.
There's been some recent discussion on this specific issue over at http://www.manning-sandbox.com/thread.jspa?threadID=27715&tstart=0
 This issue is still present in 2.2 (SNAPSHOT), in both the CE and EE transport.
http://fisheye.codehaus.org/changelog/mule/?cs=13957
This is more of a workaround than a fix, what I have done is introduce a "streaming" flag to the FTP transport which defaults to false. If streaming = false, the receiver uses the old code from 1.x, as Jerome Bernard suggests, above. Created MULE-4142 for continuing work on the real issue when streaming = true Backported to 2.1.x:
http://fisheye.codehaus.org/changelog/mule/?cs=13959 I just built https://svn.codehaus.org/mule/branches/mule-2.1.x/transports/ftp
and copied target/mule-transport-ftp-2.1.3-SNAPSHOT.jar into $MULE_HOME/lib/mule/ replacing mule-transport-ftp-2.1.2.jar.
I used the following config (mule 2.1.2): <?xml version="1.0" encoding="UTF-8"?> <mule xmlns="http://www.mulesource.org/schema/mule/core/2.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:spring="http://www.springframework.org/schema/beans" xmlns:ftp="http://www.mulesource.org/schema/mule/ftp/2.1" xmlns:file="http://www.mulesource.org/schema/mule/file/2.1" xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd http://www.mulesource.org/schema/mule/core/2.1 http://www.mulesource.org/schema/mule/core/2.1/mule.xsd http://www.mulesource.org/schema/mule/file/2.1 http://www.mulesource.org/schema/mule/file/2.1/mule-file.xsd http://www.mulesource.org/schema/mule/ftp/2.1 http://www.mulesource.org/schema/mule/ftp/2.1/mule-ftp.xsd"> <description>reads from ftp and stores to disk</description> <ftp:connector binary="true" name="ftpConnector" validateConnections="true" /> <model name="ftpSample"> <service name="Fetcher"> <inbound> <ftp:inbound-endpoint host="localhost" path="/tmp/outgoing" port="21" user="username" passive="true" password="secret"/> </inbound> <echo-component/> <outbound> <pass-through-router> <file:outbound-endpoint path="/tmp/incoming" /> </pass-through-router> </outbound> </service> </model> </mule> Preliminary tests show that this works now. Thanks, Travis! |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Critical
Ftp connector in mule 2.0 fails with ParserInitializationException
Start an ftp server on localhost
$ mkdir /tmp/incoming
$ mkdir /tmp/outgoing
start mule
$ cd /tmp/outgoing
$ echo hello > a
$ echo world > b
$ echo foo > c
Mule will then get the file 'a', but ignore the file 'b'. No matter how many files you create, Mule will ignore them.
$ ls
b c
stop mule
start mule
Mule will then get 'b' and 'c', but will then start to emit the above error message (Unknown parser type: CWD command successful).
This behavior has been confirmed with mule Version: 2.0.2 Build: 12377
$ java -version
java version "1.5.0_15"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
Java HotSpot(TM) Client VM (build 1.5.0_15-b04, mixed mode, sharing)