ws-xmlrpc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Rall <>
Subject Re: cleanup in XmlRpcServer.Worker
Date Thu, 17 Jan 2002 19:21:39 GMT
Tim, would you please submit a patch to this effect?  Your suggested
changes sound good.

                             Thanks, Dan

Timothy Peierls <> 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.

View raw message