commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel F. Savarese" <>
Subject Re: [patch] NetComponents - threading issue
Date Thu, 19 Sep 2002 16:55:51 GMT

"Tapan Karecha" <> wrote:
>While using NetComponents library on HP-UX 11i platform, even after calling
>close() on FTPClient object, the TelnetInputStream thread does not always
>terminate; and blocks on wait() for ever. The patch below addresses this
>issue. I've tested this fix on Windows and HP-UX and found it OK. Can
>someone apply this patch? Thanks!!

The patch doesn't seem to be generated against what's in
jakarta-commons-sandbox/net so I can't apply it directly.
In the future, the telnet package should probably disappear
(unless anyone wants to make it more useful) and the telnet
conversation code needed for FTP handled in a single thread, but
that's another story.  We're stuck with my imperfect original
implementation for the time being.  

In the patch, making __hasReachedEOF and __isClosed volatile doesn't do
anything.  Those are not static variables.  Changing the notify() to
notifyAll() in run() still leaves you at the mercy of the thread
scheduler.  The real key is probably the __queue.wait(100).  Anyway,
my point is that I don't think all of your changes are necessary to
address the problem.  Nonetheless, I preserved almost all of your changes
and inserted the code by hand.  Ultimately, there's probably a problem with
setting the thread priority in _start(), which in theory you shouldn't
have to do, but it was the only way to get this approach to work with
green threads and other user-space thread implementations such as 
the one in the original MacOS 8 JDK.

Please do a checkout of the jakarta-commons-sandbox/net code and
try that out in your environment.  Also, it would be appreciated
if you submitted a unit test that would expose the problem you
ran into so we can include that as a regression test.  As Jeff
indicated, we don't want to make anything other than very small
maintenance changes to the code right now, so I think we should
avoid making any fixes that can't be verfied with a corresponding
unit test.


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

View raw message