[kaffe] Apache Jakarta Commons Net does not work on Linux

[Guilhem Lavaux]

Hi Ito,

Two things:
* Commons-Net is flawed.
* Kaffe is flawed.
:)

First kaffe: I know that from the transvirtual times we have inherited a
synchronized access to native socket operations. That way we are sure
two threads are not accessing the same socket at the same time. However
it is not compatible with what is done by commons-net (and I think the
JDK)

Second commons-net: It should not access the same socket with two
threads. Looking at the code, the reader thread hangs in read() and then
can call write() from another thread. I am not sure it is really allowed
from the OS point of view and generally I would not advise it.

So now, what to do ? I will check whether the IO operations are
reentrant and then will move the mutexes.

Btw, I haven't got the assert error you mentioned. It should be a
problem in the libc itself as I am not tweaking the mutexes but on the
contrary raising protections around them. (What is Linux
2.6.7-co-0.6.2 ?)

Regards,

Guilhem.

On Wed, 2005-08-03 at 23:46 +0900, Ito Kazumitsu wrote:
> From: Ito Kazumitsu <kaz at maczuka.gcd.org>
> Subject: [kaffe] Apache Jakarta Commons Net does not work on Linux 
> Date: Tue, 02 Aug 2005 00:10:49 +0900 (JST)
> 
> > I have found that apache Jakarta Commons Net does not work
> > with current Kaffe on Linux.
> 
> I slightly changed the test program to find the following.
> 
> (1) Telnet client including FTP client of Apache Commons Net
>     performs its socket input operation in a different thread
>     called reader thread.
> 
> (2) When run on Kaffe on Linux, there seems to occur a deadlock
>     between the reader thread and the current thread.  The writing
>     operation of the current thread cannot be finished until some
>     state of the reader thread changes.  But the reading thread is
>     waiting for a response from the server, which will never come
>     until the writing operation of the current thread is finished.
> 
> (3) Such deadlock does not occur when run on Sun's JDK
>     or on Kaffe on FreeBSD.
> 
> (4) By setting some socket timeout value, the deadlock of (2)
>     can be releasd.  But such timeout means the death of the reading
>     thread and this cannot be a solusion of the problem.
> 
>     And on Linux 2.6.7-co-0.6.2, setting a timeout causes another
>     error like
> 
> $ java TestCommonsNet somehost foo bar 5000 true
> 220
> kaffe-bin: pthread_mutex_lock.c:78: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
> Aborted
> 
> (5) Telnet client including FTP client of Apache Commons Net has
>     an option of disabling the use of reader thread.  This helps
>     to avoid the deadlock of (2).
> 
> Application system users can be satisfied with (5),  but the problem
> (2) seen only on Kaffe on Linux indicates some bugs in Kaffe.
> 
> My test program follows.
> 
> import org.apache.commons.net.ftp.*;
> 
> public class TestCommonsNet {
>   public static void main(String[] args) throws Exception {
>     String hostName = args[0];
>     int port = 21;
>     String userName = args[1];
>     String password = args[2];
>     int timeout = Integer.parseInt(args[3]);
>     boolean readerThread = (args[4].equals("true"));
> 
>     FTPClient _ftpClient = new FTPClient();
>     _ftpClient.setDefaultTimeout(timeout);
>     _ftpClient.setReaderThread(readerThread);
>     _ftpClient.connect(hostName, port);
>     System.err.println(_ftpClient.getReplyCode());
>     _ftpClient.login(userName, password);
>     System.err.flush();
>     System.err.println(_ftpClient.getReplyCode());
>     _ftpClient.logout();
>     System.err.println(_ftpClient.getReplyCode());
> 
>   }
> }
> 
> _______________________________________________
> kaffe mailing list
> kaffe at kaffe.org
> http://kaffe.org/cgi-bin/mailman/listinfo/kaffe