db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Øystein Grøvlen <Oystein.Grov...@Sun.COM>
Subject Re: svn commit: r634658 - /db/derby/code/trunk/java/engine/org/apache/derby/impl/services/replication/net/SocketConnection.java
Date Fri, 07 Mar 2008 13:54:07 GMT
Knut Anders Hatlen wrote:
> oysteing@apache.org writes:
>> Author: oysteing
>> Date: Fri Mar  7 05:06:08 2008
>> New Revision: 634658
>> URL: http://svn.apache.org/viewvc?rev=634658&view=rev
>> Log:
>> DERBY-3358: OOME at slave during replication
> Isn't this DERBY-3497?

Oops.  I will fix that.

>>      public void writeMessage(Object message) throws IOException {
>> +        // reset stream so that previously shipped objects can be gc'ed
>> +        objOutputStream.reset();
>>          objOutputStream.writeObject(message);
>>          //flush the stream to ensure that all the data that is part
>>          //of the message object is written and no data remains
> Wouldn't it be better to call reset after writeObject() (and before
> flush())? That would allow both the sender and the receiver to reclaim
> the memory earlier.

I guess the way this stream works, we might as well call reset right 
away.  As far as I understand, before reset is called, when writing more 
objects to the stream that have references to objects already written to 
the stream since last call to reset, it will not lead to those objects 
being serialized again.  Since each replication message will be 
independent of earlier messages, there is no need for sharing objects 
and the stream could be reset right away.

A possible alternative, if I interpret the javadoc for 
ObjectOutputStream correctly, would be to use writeUnshared instead of 
writeObject.  Since the written object will not be shared, maybe calling 
reset would not be necessary in that case.


View raw message