[ http://issues.apache.org/jira/browse/DERBY-443?page=comments#action_12369212 ]
John H. Embretsen commented on DERBY-443: ----------------------------------------- Daniel John Debrunner commented on DERBY-443: ---------------------------------------------- > As the above paper notes OutOfMemoryErrors do not have any stack > traces, thus it's harder to see where the exception was being thrown > so as to investigate or to code recovery code. Yet another improvement with Java SE 6 (jdk1.6/Mustang): The HotSpot VM will attempt to include a stack trace on OutOfMemoryErrors... See http://blogs.sun.com/roller/page/alanb?entry=outofmemoryerror_looks_a_bit_better For example, here is a derby network server console stack trace from running my repro for DERBY-210, http://issues.apache.org/jira/secure/attachment/12323684/StatementStress.java, with Mustang (build 1.6.0-beta2-b73): Exception in thread "DRDAConnThread_3" java.lang.OutOfMemoryError: PermGen space at org.apache.derby.impl.drda.DRDAConnThread.markCommunicationsFailure(DRDAConnThread.java:409) at org.apache.derby.impl.drda.DDMReader.fill(DDMReader.java:1749) at org.apache.derby.impl.drda.DDMReader.ensureALayerDataInBuffer(DDMReader.java:1473) at org.apache.derby.impl.drda.DDMReader.readDssHeader(DDMReader.java:315) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:591) at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:236) Other OOME stack traces were written to derby.log. > Make Derby engine robust in case of OutOfMemoryError exceptions > --------------------------------------------------------------- > > Key: DERBY-443 > URL: http://issues.apache.org/jira/browse/DERBY-443 > Project: Derby > Type: Task > Components: Services > Reporter: Daniel John Debrunner > Priority: Minor > > Derby currently treats an OutOfMemoryError as a virtual machine exception, > terminal failure and shuts down. > However in many cases Derby could (possibly) recover gracefully by just > disallowing the requested operation. > Examples are > - reject a connection request > - throw an exception on a new compilation (e.g. prepareStatement or > executeQuery) > - not increase the size of a cache > - don't boot the database > I think the only case where recovery is not possible is an exception during a > rollback, in this case the database needs to be shutdown and recovery will > correctly handle the situation. > In addition a system wide facility could be added that is called upon low > memory and tries to reduce memory usage by Derby, e.g. reduce the size of > various caches. An initial version of this could be very simple, just calling > System.gc(). > I was thinking this could be the high level task, and sub tasks could be > added for individual pieces of work, e.g. connection handling, statement > handling etc. as people wanted to address items. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
