db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6114) OOME in XAMemTest.testDerby4137_TransactionTimeoutSpecifiedNotExceeded
Date Thu, 06 Jun 2013 07:44:22 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13676814#comment-13676814
] 

Knut Anders Hatlen commented on DERBY-6114:
-------------------------------------------

I think this has only been seen in the Jenkins jobs on builds.apache.org, so it's more likely
that there is something special about that environment than an actual regression. I see that
the test takes very long in my environment when running it standalone with -Xmx16M (same setting
as the junit-lowmem Ant target), doing lots of GC, and there may be some property of the test
server that makes the JVM give up with "GC overhead limit exceeded" earlier on that machine.

I monitored the heap usage while running the test, and it is the queue of the cancellation
timer that grows very big during this test. It ends up with 120000 entries, all entries representing
canceled tasks. The fix for DERBY-4137 reduced the size of the entries after they have been
canceled, but it didn't remove them from the queue. They canceled tasks stay in the queue
until the time they're scheduled to run, but they've been made no-ops.

There was some discussion in DERBY-4137 about using the Java 5 method TimerTask.purge() to
remove canceled tasks from the queue. That was not implemented because reducing the size of
the canceled tasks in the queue appeared to be sufficient to solve the problem at hand. I
think we should reconsider it, given that we have seen problems with resources not being freed
in time because of it both in this issue and in DERBY-5394.

On trunk I think it would make sense at some point in time to move from java.util.Timer to
java.util.concurrent.ScheduledThreadPoolExecutor, as the latter better supports fast (and
from Java 7 even automatic) removal of canceled tasks. However, since such a solution would
depend on Java 5, it could not be easily back-ported to the branches on which we see the test
failures. (Side note: We've only seen it on 10.9 and 10.10. Not yet on trunk, but that's most
likely just because we don't run JUnit tests against trunk on builds.apache.org.)

I therefore plan to create a fix that uses the purge() method and that can be back-ported,
and leave it as a possible improvement on trunk to replace java.util.Timer with java.util.concurrent.ScheduledThreadPoolExecutor.
                
> OOME in XAMemTest.testDerby4137_TransactionTimeoutSpecifiedNotExceeded
> ----------------------------------------------------------------------
>
>                 Key: DERBY-6114
>                 URL: https://issues.apache.org/jira/browse/DERBY-6114
>             Project: Derby
>          Issue Type: Bug
>          Components: Test
>    Affects Versions: 10.9.2.2, 10.10.1.1
>         Environment: Derby head of 10.10 branch. ubuntu3 slave on builds.apache.org.
Java SE 7u4, 64-bit.
> java.vendor=Oracle Corporation
> java.runtime.version=1.7.0_04-b20
> os.name=Linux
> os.arch=amd64
> os.version=3.2.0-38-generic
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: derby.log, error-stacktrace.out
>
>
> Seen twice in a row in https://builds.apache.org/job/Derby-10.10-suites.All/ :
> junit-lowmem:
>     [junit] Running org.apache.derbyTesting.functionTests.tests.memory._Suite
>     [junit] Exception in thread "DRDAConnThread_11" java.lang.OutOfMemoryError: GC overhead
limit exceeded
>     [junit] 	at java.util.Properties$LineReader.<init>(Properties.java:405)
>     [junit] 	at java.util.Properties.load(Properties.java:341)
>     [junit] 	at java.util.PropertyResourceBundle.<init>(PropertyResourceBundle.java:130)
>     [junit] 	at java.util.ResourceBundle$Control.newBundle(ResourceBundle.java:2610)
>     [junit] 	at java.util.ResourceBundle.loadBundle(ResourceBundle.java:1436)
>     [junit] 	at java.util.ResourceBundle.findBundle(ResourceBundle.java:1400)
>     [junit] 	at java.util.ResourceBundle.findBundle(ResourceBundle.java:1354)
>     [junit] 	at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1296)
>     [junit] 	at java.util.ResourceBundle.getBundle(ResourceBundle.java:796)
>     [junit] 	at org.apache.derby.iapi.services.i18n.MessageService.getBundleWithEnDefault(MessageService.java:318)
>     [junit] 	at org.apache.derby.iapi.services.i18n.MessageService.getBundleForLocale(MessageService.java:53)
>     [junit] 	at org.apache.derby.iapi.services.i18n.MessageService.getBundle(MessageService.java:302)
>     [junit] 	at org.apache.derby.iapi.services.i18n.MessageService.getCompleteMessage(MessageService.java:97)
>     [junit] 	at org.apache.derby.iapi.error.SQLWarningFactory.newSQLWarning(SQLWarningFactory.java:97)
>     [junit] 	at org.apache.derby.iapi.error.SQLWarningFactory.newSQLWarning(SQLWarningFactory.java:50)
>     [junit] 	at org.apache.derby.iapi.jdbc.BrokeredConnection.statementHoldabilityCheck(BrokeredConnection.java:736)
>     [junit] 	at org.apache.derby.iapi.jdbc.BrokeredConnection.prepareStatement(BrokeredConnection.java:690)
>     [junit] 	at org.apache.derby.impl.drda.DRDAStatement.prepare(DRDAStatement.java:669)
>     [junit] 	at org.apache.derby.impl.drda.DRDAStatement.explicitPrepare(DRDAStatement.java:630)
>     [junit] 	at org.apache.derby.impl.drda.DRDAConnThread.parsePRPSQLSTT(DRDAConnThread.java:3912)
>     [junit] 	at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:811)
>     [junit] 	at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:295)
>     [junit] Tests run: 67, Failures: 0, Errors: 1, Time elapsed: 1,571.059 sec
>     [junit] Test org.apache.derbyTesting.functionTests.tests.memory._Suite FAILED

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message