commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel F. Savarese" <>
Subject Re: [NET] TelnetClient without reader thread for FTPClient
Date Thu, 24 Apr 2003 00:47:09 GMT

In message <HDT3JR$>, "=?iso-8859-1?Q
?" writes:
>One of the tasks reported in the TODO list for commons net is: 
>"Divorce FTPClient from TelnetClient, getting rid of the TelnetClient
>threads which cause problems on some platforms (e.g., MacOS)."

I believe that comment was made before J2SE 1.4 was released.  My
bias would be to discontinue pre-1.4 support and just get rid of
the threads altogther (the threads were forced upon the implementation
for lack of a Java select() in JDK 1.1 days).  Unfortunately, I've
encountered enough inconsistencies with java.nio selectable channels
on different operating systems to make make that as problematic as
the original threading problems.  The problem with the thread behavior
was a green threads vs. native thread issue as well as differing native
threads behavior.  I believe the TelnetClient implementation was
theoretically correct, but not everyone dealt with wait() and notifyAll() the
same way.  But that problem dates back to JDK 1.1, and I believe
all is fine with J2SE 1.3 implementations.

Anyway, I think we really want to move away from threads, so any
enhancements based around threads may be wasted work.  On the other hand,
until java.nio is fixed, we're stuck with threads.  How's that for sitting
on the fence? :)  In the end, I don't think what you suggest will hurt
anything.  As far as reproducing the problem goes, I've never been
able to reproduce it on Win32 or Linux and I've never been able to
compel someone who alleged a problem on another OS to submit a test
case.  I think that closest we ever came was after moving the code
into the Commons, someone had a problem with a JVM on AIX or HP-UX
and submitted an overly involved patch to work around the problem 
that I reduced to just changing a wait() to a wait(100).  It wasn't
theoretically necessary, but it didn't hurt anything on other platforms
and worked around the problem on the JVM in question.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message