ws-xmlrpc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Rall <...@finemaltcoding.com>
Subject Re: cleanup in XmlRpcServer.Worker
Date Fri, 25 Jan 2002 23:05:17 GMT
Hi Tim.  I've committed code implementing the general idea behind your
patch to CVS.  Thanks much!

Dan


Timothy Peierls <tim@peierls.net> writes:

> The XmlRpcServer.Worker fields inParams, outParam, result, and
> strbuf are not being cleared on exit from the execute() method, and
> I believe they should be. All it takes is to wrap the execute() body
> with
>
>     try {
>         ...
>     }
>     finally {
>         inParams = null;
>         outParam = null;
>         result = null;
>         strBuf.setLength(0);
>     }
>
> and remove the existing else clause that has "strBuf.setLength(0)".
>
> Even better, if outParam and result were made local variables
> instead of fields of Worker, you could remove the second and third
> lines of the finally clause.
>
> Why does this matter? Because there is no guarantee that the
> execute() method will be called again any time soon, or ever. Since
> there is no size restriction on arguments and results in the XML-RPC
> spec, you can have arbitrarily large objects hanging around for
> arbitrarily long intervals, a classic Java memory leak.
>
> I saw this happen in practice: The service defined a method to
> return the state of the entire system (as XML-RPC structs and
> arrays). Huge chunks of memory that could have been freed up on
> return were left dangling uselessly until the Worker was next used.
> Performance noticeably improved when we made a local fix to the
> Worker class.
>
> I asked about this over a year ago, but I think it got lost in the
> cracks.
>
> Tim Peierls <mailto:tim@peierls.net>

Mime
View raw message