You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlrpc-dev@ws.apache.org by Alan Burlison <Al...@sun.com> on 2009/04/28 17:10:59 UTC
Do we care about Java 1.4 compatibility?
I've been diagnosing the cause of
https://issues.apache.org/jira/browse/XMLRPC-168, and I'm rapidly coming
to the conclusion that the XML-RPC thread pool class
(org.apache.xmlrpc.util.ThreadPool) is fundamentally flawed. ThreadPool
uses a nonstatic member class (Poolable) that calls synchronized methods
on the enclosing class, and the enclosing class in turn calls
synchronized methods on the enclosed class. That's a recipe for deadlocks.
I'm tempted so suggest we should just rip it out entirely and replace it
with one of the thread pools from java.util.concurrent. However those
classes didn't appear until JDK 1.5, so we'd lose JDK 1.4 compatibility.
On the other hand, JDK 1.4 went EOSL in 2008 [1], so that *shouldn't*
be a problem.
Is anyone still using JDK 1.4?
[1] http://java.sun.com/products/archive/eol.policy.html
--
Alan Burlison
--
Re: Do we care about Java 1.4 compatibility?
Posted by Alan Burlison <Al...@sun.com>.
Jochen Wiedmann wrote:
> Not so fast, Alan. An issue, which is not even one day old, is no
> sufficient reasons for heavyweight replies like introducing new
> dependencies or switching the JDK version.
and from the bug report:
> Right. The problem of cross locking should be addressed by my updated
> version,
Nope, that fails too. I'll get some diagnostics & test scripts attached
to the bug in a bit. I haven't bottomed it out yet, but I'm reasonably
sure it is an architectural flaw, and no amount of lock-jiggling is
going to fix it.
There are a number of other things that probably need looking at - the
use of private methods defined in the enclosing ThreadPool class by the
Poolable nonstatic member class is the reason for those 'accessor'
methods that appear in the stack trace - make them protected and the
accessors aren't needed.
Also the use of ThreadPool.startTask is problematic because it means
that under heavy transient load the server starts throwing requests away
rather than queuing them. The (now deprecated?) ThreadPool.addTask
method seems much preferable.
I really think that it would be better and quicker to just rip this out
entirely and replace it with something from java.util.concurrent, but
I'd be very interested to hear what you think.
--
Alan Burlison
--
Re: Do we care about Java 1.4 compatibility?
Posted by Jochen Wiedmann <jo...@gmail.com>.
Not so fast, Alan. An issue, which is not even one day old, is no
sufficient reasons for heavyweight replies like introducing new
dependencies or switching the JDK version.
Jochen
On Tue, Apr 28, 2009 at 5:10 PM, Alan Burlison <Al...@sun.com> wrote:
> I've been diagnosing the cause of
> https://issues.apache.org/jira/browse/XMLRPC-168, and I'm rapidly coming to
> the conclusion that the XML-RPC thread pool class
> (org.apache.xmlrpc.util.ThreadPool) is fundamentally flawed. ThreadPool
> uses a nonstatic member class (Poolable) that calls synchronized methods on
> the enclosing class, and the enclosing class in turn calls synchronized
> methods on the enclosed class. That's a recipe for deadlocks.
>
> I'm tempted so suggest we should just rip it out entirely and replace it
> with one of the thread pools from java.util.concurrent. However those
> classes didn't appear until JDK 1.5, so we'd lose JDK 1.4 compatibility. On
> the other hand, JDK 1.4 went EOSL in 2008 [1], so that *shouldn't* be a
> problem.
>
> Is anyone still using JDK 1.4?
>
>
> [1] http://java.sun.com/products/archive/eol.policy.html
>
> --
> Alan Burlison
> --
>
--
Don't trust a government that doesn't trust you.
Re: Do we care about Java 1.4 compatibility?
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Tue, Apr 28, 2009 at 7:29 PM, Alan Burlison <Al...@sun.com> wrote:
> Don Albertson wrote:
>
>>> [1] http://java.sun.com/products/archive/eol.policy.html
>>>
>> I have a few applications that are still running in 1.4 but they only use
>> the client functions
>
> Good point, this would just affect the server - but the current code is in
> the common lib so I'm not sure how that would play out.
No it wouldn't. The ThreadPool isn't in the common package by change.
The client uses it for load limitation too.
Jochen
--
Don't trust a government that doesn't trust you.
Re: Do we care about Java 1.4 compatibility?
Posted by Don Albertson <dg...@psu.edu>.
Alan Burlison said (on or about) 04/28/2009 13:29:
> Don Albertson wrote:
>
>>> [1] http://java.sun.com/products/archive/eol.policy.html
>>>
>> I have a few applications that are still running in 1.4 but they only
>> use the client functions
>
> Good point, this would just affect the server - but the current code
> is in the common lib so I'm not sure how that would play out.
>
I'm doing my best to manage the threads on the client side, so I _think_
I've got that handled before it gets to making the request from someone
else's server.
dga
--
Science is the process that takes us from confusion to understanding in
a manner that's precise, predictive and reliable.
Re: Do we care about Java 1.4 compatibility?
Posted by Alan Burlison <Al...@sun.com>.
Don Albertson wrote:
>> [1] http://java.sun.com/products/archive/eol.policy.html
>>
> I have a few applications that are still running in 1.4 but they only
> use the client functions
Good point, this would just affect the server - but the current code is
in the common lib so I'm not sure how that would play out.
--
Alan Burlison
--
Re: Do we care about Java 1.4 compatibility?
Posted by Don Albertson <dg...@psu.edu>.
Alan Burlison said (on or about) 04/28/2009 11:10:
> I've been diagnosing the cause of
> https://issues.apache.org/jira/browse/XMLRPC-168, and I'm rapidly
> coming to the conclusion that the XML-RPC thread pool class
> (org.apache.xmlrpc.util.ThreadPool) is fundamentally flawed.
> ThreadPool uses a nonstatic member class (Poolable) that calls
> synchronized methods on the enclosing class, and the enclosing class
> in turn calls synchronized methods on the enclosed class. That's a
> recipe for deadlocks.
>
> I'm tempted so suggest we should just rip it out entirely and replace
> it with one of the thread pools from java.util.concurrent. However
> those classes didn't appear until JDK 1.5, so we'd lose JDK 1.4
> compatibility. On the other hand, JDK 1.4 went EOSL in 2008 [1], so
> that *shouldn't* be a problem.
>
> Is anyone still using JDK 1.4?
>
>
> [1] http://java.sun.com/products/archive/eol.policy.html
>
I have a few applications that are still running in 1.4 but they only
use the client functions
dga
Re: Do we care about Java 1.4 compatibility?
Posted by Alan Burlison <Al...@sun.com>.
Craig Kelley wrote:
>> Is anyone still using JDK 1.4?
>
> As a user of XMLRPC, I must still support 1.4 -- but I do not think
> that it would be outrageous to ask users like myself to stick to older
> versions of XMLRPC. Spring and Hibernate are abandoning 1.4.
>
> Personally, I would vote "go for it". There are too many compelling
> reasons, and those who must still live in the past are probably happy
> with older XMLRPC releases anyway.
There's also a backport of the 1.5 functionality:
http://backport-jsr166.sourceforge.net/
--
Alan Burlison
--
Re: Do we care about Java 1.4 compatibility?
Posted by Craig Kelley <na...@gmail.com>.
On Tue, Apr 28, 2009 at 9:10 AM, Alan Burlison <Al...@sun.com> wrote:
> Is anyone still using JDK 1.4?
As a user of XMLRPC, I must still support 1.4 -- but I do not think
that it would be outrageous to ask users like myself to stick to older
versions of XMLRPC. Spring and Hibernate are abandoning 1.4.
Personally, I would vote "go for it". There are too many compelling
reasons, and those who must still live in the past are probably happy
with older XMLRPC releases anyway.
--
http://inconnu.islug.org/~ink finger ink@inconnu.islug.org for PGP block