[
https://issues.apache.org/jira/browse/DERBY-3497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jørgen Løland updated DERBY-3497:
---------------------------------
Attachment: derby-3497-1a.diff
derby-3497-1a.stat
It turns out that ObjectOutputStreams / ObjectInputStreams are supposed to keep
references to all sent objects.
In patch 1a I added objOutputStream.reset in
ReplicationMessageTransmit#writeObject before sending the new object. This
removes the old object references both on the transmitter and the receiver
side. I inserted 1,000,000 records with ~220 characters each and profiled the
memory usage on the slave:
Without reset: byte[] took up 380 MB (98.2% of the heap)
With reset: byte[] took up 6MB (54% of the heap)
Seems like the memoryleak has been identified. I'm running tests on the patch
now.
> OOME at slave during replication
> --------------------------------
>
> Key: DERBY-3497
> URL: https://issues.apache.org/jira/browse/DERBY-3497
> Project: Derby
> Issue Type: Bug
> Components: Replication
> Affects Versions: 10.4.0.0
> Environment: trunk at revision 633807
> Reporter: Øystein Grøvlen
> Assignee: Jørgen Løland
> Attachments: derby-3497-1a.diff, derby-3497-1a.stat
>
>
> After deleting and inserting more than 1 million records during replication,
> I got
> java.lang.OutOfMemoryError: Java heap space.
> The heap dump shows that almost the entire heap is byte arrays, and it seems
> most of them are referred to by ReplicationMessage objects. An inspection of
> the heap dump in VisualVM it seems that it is references rooted in
> SocketConnection#objInputStream that keeps them from being garbage collected.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
