[kaffe] org.apache.commons.net.ftp.FTPClient: disconnect() hangs

[Ito Kazumitsu]

In message "[kaffe] org.apache.commons.net.ftp.FTPClient: disconnect() hangs"
    on 04/10/11, Ito Kazumitsu <kaz at maczuka.gcd.org> writes:

> While testing openadaptor, I found a case where the package
> org.apache.commons.net.ftp from Jakarta Commons http://jakarta.apache.org/
> does not work properly.
> 
> The attached program, which ends normally with Sun's JDK,
> will not stop with kaffe.  Does it go into a deadlock?

Whether or not this problem occurs depends mainly on
whether the system property line.separator is equal to
"\r\n".

If line.separator is "\r\n",  it is OK, which is the case
I had with Sun's JDK on Windows.  If line.separator is not
"\r\n",  the problem may occur,  which is the case I had with
Kaffe on Linux.  Setting line.separator to "\r\n",  I got
a good result on Linux, too.

But even if the line.separator is set to "\n",  Sun's JDK
on Windows gives a good result.

And here is the cause of the problem on kaffe.

When disconnect() on a FTP client is called, close() on its
org.apache.commons.net.io.FromNetASCIIInputStream is called.
FromNetASCIIInputStream is a subclass of java.io.PushbackInputStream
and close() is inherited.  PushbackInputStream's close() is
synchronized, so close() tries to lock the input stream object.

Unfortunately,  another thread is still reading from the input
stream.  PushbackInputStream's read() is also synchronized.
So close() cannot get a lock until the read() ends.  The reading
thread seems to be waiting for some data from the FTP server,
which will never come.  So both read() and close() will never
finish.

If Kaffe's (that is GNU Classpath's) java.io.PushbackInputStream
is correct,  this problem may be directed to Jakarta Commons.
But the misterious thing is that Sun's JDK does not show the
problem.  If Kaffe's java.io.PushbackInputStream is correct,
Sun's JDK may be neglecting some necessary synchronization
or uses some magic to avoid the problematic situation.