db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John H. Embretsen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-443) Make Derby engine robust in case of OutOfMemoryError exceptions
Date Tue, 07 Mar 2006 11:46:39 GMT
    [ 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


Mime
View raw message