db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4200) client side OutOfMemoryError running derbnetclientmats:jdbcapi/derbyStress
Date Wed, 21 Oct 2009 20:28:59 GMT

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

Mamta A. Satoor commented on DERBY-4200:
----------------------------------------

I was able to get hold of IBM1.5 SR10 on both my windows XP laptop and on the vmware machine
and in both places, the behavior stayed the same which is no OOM problems on windows XP but
intermittent OOMs on vmware continued. Whenever we ran into OOM on vmware, it would be close
to after 900 to 1000 iterations of ResultSet rs = s.executeQuery("SELECT * from tab"); that
we would get OOM. And the number of NetStatement objects in the heapdumps consistently is
over 900+ when we run into OOM.

I will wait to hear what community thinks of these experiments. It definitely appears to be
specific to this vmware platform which has single processor.

> client side OutOfMemoryError running derbnetclientmats:jdbcapi/derbyStress
> --------------------------------------------------------------------------
>
>                 Key: DERBY-4200
>                 URL: https://issues.apache.org/jira/browse/DERBY-4200
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client
>    Affects Versions: 10.5.2.0
>         Environment: java version "1.5.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build pxi32devifx-20070806 (SR5a))
> IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20070426 (JIT enabled)
> J9VM - 20070420_12448_lHdSMR
> JIT  - 20070419_1806_r8
> GC   - 200704_19)
> JCL  - 20070725
> SUSE linux running on vmware.
>            Reporter: Kathey Marsden
>            Assignee: Mamta A. Satoor
>         Attachments: heapdump.20090428.084024.25679.phd, javacore.20090428.084024.25679.txt,
vmware10_5_SR10HeapDump.phd, vmware10_5_SR7HeapDump.phd, windows10_5_HeapDump.phd
>
>
> On the nightly run for 4/27 - 10.5.1.2 - (769232), I saw client jdbcapi/derbystress.java
 run out of heap space.   The test has not failed like this before on the same machine with
the same JVM, and the one checkin on that day DERBY-3991 could not account for this failure.
> I will attach the javacore and heapdump.  Taking a quick look at the heap dump, it seems
to have a lot of client side Statement objects, which seems to be just the leak the test is
checking for.  Note: the test runs with 64MB heap.  It would be interesting to run with other
jvms and force a gc() and a heap dump at this point in the test and see if we still have a
lot of Statement objects or if this is a specific platform/JVM issue.
> The trace at the time of failure was :
> 1XMCURTHDINFO  Current Thread Details
> NULL           ----------------------
> 3XMTHREADINFO      "main" (TID:0x0808D300, sys_thread_t:0x0805CBC8, state:R, native ID:0x0000644F)
prio=5
> 4XESTACKTRACE          at org/apache/derby/client/am/Cursor.allocateCharBuffer(Bytecode
PC:77(Compiled Code))
> 4XESTACKTRACE          at org/apache/derby/client/net/NetStatementReply.parseSQLDTARDarray(Bytecode
PC:77(Compiled Code))
> 4XESTACKTRACE          at org/apache/derby/client/net/NetStatementReply.parseQRYDSC(Bytecode
PC:10(Compiled Code))
> 4XESTACKTRACE          at org/apache/derby/client/net/NetStatementReply.parseOpenQuery(Bytecode
PC:104(Compiled Code))
> 4XESTACKTRACE          at org/apache/derby/client/net/NetStatementReply.parseOPNQRYreply(Bytecode
PC:14(Compiled Code))
> 4XESTACKTRACE          at org/apache/derby/client/net/NetStatementReply.readOpenQuery(Bytecode
PC:6(Compiled Code))
> 4XESTACKTRACE          at org/apache/derby/client/net/StatementReply.readOpenQuery(Bytecode
PC:7(Compiled Code))
> 4XESTACKTRACE          at org/apache/derby/client/net/NetStatement.readOpenQuery_(Bytecode
PC:11(Compiled Code))
> 4XESTACKTRACE          at org/apache/derby/client/am/Statement.readOpenQuery(Bytecode
PC:6(Compiled Code))
> 4XESTACKTRACE          at org/apache/derby/client/am/Statement.flowExecute(Bytecode PC:581(Compiled
Code))
> 4XESTACKTRACE          at org/apache/derby/client/am/Statement.executeQueryX(Bytecode
PC:3(Compiled Code))
> 4XESTACKTRACE          at org/apache/derby/client/am/Statement.executeQuery(Bytecode
PC:3(Compiled Code))
> 4XESTACKTRACE          at org/apache/derbyTesting/functionTests/tests/jdbcapi/derbyStress.testDerby3316(derbyStress.java:156)
> 4XESTACKTRACE          at org/apache/derbyTesting/functionTests/tests/jdbcapi/derbyStress.main(derbyStress.java:57(Compiled
Code))

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message