On 5/19/2015 11:00 AM, Bergquist, Brett wrote:
I found how to export to a text file. So here is one of the areas that the
leak detection pointed out:
'- buf, lock java.io.StringWriter @ 0xfffffffd86693928 | 48 |
706,545,952
'- stringWriter org.apache.derby.iapi.error.ErrorStringBuilder @
0xfffffffd86693900
'- errorStringBuilder
org.apache.derby.iapi.services.context.ContextManager @ 0xfffffffd86637d80
I'm not totally sure how to read this, but I think it's saying that the
errorStringBuilder field in the ContextManager has 706 meg of string data in it.
From what I can tell by looking at ContextManager.java, the
errorStringBuilder field is only supposed to contain data if
a fairly severe error has occurred, and Derby is trying to
write that error to derby.log:
/**
* clean up error and print it to derby.log. Extended diagnosis including
* thread dump to derby.log and javaDump if available, will print if the
* database is active and severity is greater than or equals to
* SESSTION_SEVERITY or as configured by
* derby.stream.error.extendedDiagSeverityLevel property
*
* @param error the error we want to clean up
* @param diagActive
* true if extended diagnostics should be considered,
* false not interested of extended diagnostic information
* @return true if the context manager is shutdown, false otherwise.
*/
public boolean cleanupOnError(Throwable error, boolean diagActive)
Now, 706 meg is a LOT of string data, but it's still a long ways from 8GB.
Did you end up getting any information in your derby.log?
I'm totally speculating, but it's possible that the ContextManager heap usage
is a secondary problem, that the real problem is:
what caused Derby to invoke ContextManager.cleanupOnError() in the
first place?
Hope this is of some help and gives you some things to pursue.
thanks,
bryan
