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 Sat, 26 Jan 2002 07:55:41 GMT
Timothy Peierls <tim@peierls.net> writes:

> Daniel Rall wrote:
> > Hi Tim.  I've committed code implementing the general idea behind your
>> patch to CVS.  Thanks much!
>
> You're welcome. 
>
> I notice you left the byte[] result as a field rather than make it a
> local variable. Though it won't make any difference for small responses,
> it is still a potential memory leak if the responses get very large. Is
> there some other reason to use a field here?

Just to reuse the pointer.  You're right that what it's pointing at
should be cleared -- probably better to just make it local as you
suggested.  Done.

> Come to think of it, the use of setLength(0) to clear the StringBuffer
> is a bit risky. There is no guarantee that setLength releases any
> memory. Maybe it would be better simply to allocate a new StringBuffer
> for each execute?
>
> Same reasoning applies to the argument Vector, in theory, but in this
> case the "leak" is proportional to the number of arguments, which is
> unlikely to be significant, unlike the StringBuffer and byte array. So
> what you did with removeAllElements() seems like the right choice to me.

I didn't expect there to be enough input arguments to make a
difference for the Vector (if there are, the technology is probably
just not being used right in the first place).  For the StringBuffer,
I also wanted to hold on to the buffer to prevent having to go back to
the heap for more.  Perhaps it makes sense to release the StringBuffer
and/or byte[] only if they surpass a given size (say, 2kb?).
Thoughts?


Mime
View raw message