Ftp connector in mule 2.0 fails with ParserInitializationException

The behaviour is quite consistent if you follow these steps:

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)

I'm getting the same problem (but not as consistent) on a different environment:

Windows Vista SR1
Cerberus FTP Server
Mule 2.0.2
jdk-6u10-rc

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
windows xp sp3

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:

• Force the receiver to run singlethreaded with a threading profile.
• Put 2 or more files in the polled folder on the Ftp and start mule.

It will always fetch the first file successfully and then fail with 250 on all the subsequent files.
( And as someone else mentioned get stuck and not fetch any more files until restart.)

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.
org.apache.commons.net.ftp.parser.ParserInitializationException: 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.
So, in FtpMessageReceiver, in method processFile(), if you use the code available underneath, it will work.
What I suppose is that there is an issue with the streams. They are probably not closed properly (I don't have enough in-depth knowledge of Mule 2): as said on the Commons-NET JavaDoc for retreiveFileStream (http://commons.apache.org/net/apidocs/org/apache/commons/net/ftp/FTPClient.html#retrieveFileStream(java.lang.String)), we should make sure the stream is closed and call client.completePendingCommands().

Could someone test this with Mule 1.4 when activation the streaming mode?
The same issue should occur if I got that right...

"Patch":
/*
InputStream stream = client.retrieveFileStream(file.getName());
if (stream == null)
{
throw new IOException(MessageFormat.format("Failed to retrieve file {0}. Ftp error: {1}",
new Object[]{file.getName(), new Integer(client.getReplyCode())}));
}
message = new DefaultMuleMessage(connector.getMessageAdapter(stream));
*/

ByteArrayOutputStream baos = new ByteArrayOutputStream();
if (!client.retrieveFile(file.getName(), baos))
{
throw new IOException(MessageFormat.format("Failed to retrieve file {0}. Ftp error: {1}",
new Object[] {file.getName(), new Integer(client.getReplyCode())}));
}
message = new DefaultMuleMessage(connector.getMessageAdapter(baos.toByteArray()));

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!