Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (nike.apache.org: domain of kristian.waagan@oracle.com
 designates 148.87.113.117 as permitted sender)
Message-ID: <4FEB1686.6040305@oracle.com>
Date: Wed, 27 Jun 2012 16:19:50 +0200
From: Kristian Waagan <kristian.waagan@oracle.com>
User-Agent: Mozilla/5.0 (X11; SunOS i86pc;
 rv:10.0.3) Gecko/20120424 Thunderbird/10.0.3
MIME-Version: 1.0
To: derby-user@db.apache.org
Subject: Re: Strange OutOfMemory in unittest
References: <34080334.post@talk.nabble.com>
In-Reply-To: <34080334.post@talk.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 27.06.12 15:15, mogoye wrote:
>
> Hello,
>
> I'm currently working on a some junit tests to validate My DB using Derby
> 1.8.1.2.
> My code is using JPA annotations and Eclipselink implementation.
>
> The purpose of this test is to evaluate the performances of my requests.
> My test is doing the following things :
> - Create an empty DB.
> - Fill DB with 200 000 entries
> - Performs some requests.
> - Check answers are Ok and measure time to proccess them.
>
> The thing I don't understant is why my test can be executed 50% of the time
> with no problem, and the other 50% I have OutOfMemory that occurs at various
> tests execution.
>
> I don't understand why the same code executed few seconds later can sometime
> be a success or failure.
>
>
> For example here is one of the request that is executed.
> In that case the request is a native querry and a very basic request:
> SELECT * FROM TICKET ORDER BY EXPECTED_DATE ASC OFFSET 33000 ROWS FETCH
> FIRST 20 ROWS ONLY
>
>
> My DB (measured on the file system) is only 100Mb so not very big one
> See bellow the stack trace.
>
> I have no idea how I can go further as I'm not very familliar with derby
> tools or logs to help debugging.
>
> Does any one have some idea ?

As already mentioned, you should check what your maximum heap size is 
set to. If Derby is run with the default page cache size, it normally 
shouldn't occupy much more than 4 MB of heap.

If your VM supports it, you could dump the heap when the OOME occurs 
[1], or use something like VisualVM (maybe with the visualgc plugin) to 
observe the memory usage. If you obtain a dump, you have to extract 
information from it afterwards, for instance with jhat. If you search 
the web, you'll probably find other tools doing similar things.
Note that you can always obtain heap dumps with VisualVM, and 
information like the max heap size.

You could also sample the heap manually by using a tool like jmap to get 
a heap histogram.

In many cases the thread stack trace is a red herring, at least in 
multi-threaded applications, since the OOME can happen at any place 
where memory is needed/allocated.


Regards,
-- 
Kristian

[1] For the Sun/Oracle JVMs that would be -XX:+HeapDumpOnOutOfMemoryError

>
> Thanks a lot.
> Sylvain
>
>
>
>
> Here is the complete Stack trace I can get (sometimes I do not have any
> stack info):
>
> java.lang.OutOfMemoryError: Java heap space
> 	at
> sun.text.resources.DateFormatZoneData.getContents(DateFormatZoneData.java:299)
> 	at
> sun.text.resources.DateFormatZoneData.loadLookup(DateFormatZoneData.java:144)
> 	at
> sun.text.resources.DateFormatZoneData.getKeys(DateFormatZoneData.java:100)
> 	at
> sun.text.resources.DateFormatZoneData.getKeys(DateFormatZoneData.java:105)
> 	at java.text.DateFormatSymbols.loadZoneStrings(DateFormatSymbols.java:449)
> 	at java.text.DateFormatSymbols.initializeData(DateFormatSymbols.java:489)
> 	at java.text.DateFormatSymbols.<init>(DateFormatSymbols.java:103)
> 	at java.util.TimeZone.retrieveDisplayNames(TimeZone.java:412)
> 	at java.util.TimeZone.getDisplayNames(TimeZone.java:401)
> 	at java.util.TimeZone.getDisplayName(TimeZone.java:352)
> 	at java.util.Date.toString(Date.java:1024)
> 	at java.lang.String.valueOf(String.java:2615)
> 	at java.lang.StringBuffer.append(StringBuffer.java:220)
> 	at
> org.apache.derby.impl.services.stream.BasicGetLogHeader.getHeader(Unknown
> Source)
> 	at org.apache.derby.iapi.error.ErrorStringBuilder.appendln(Unknown Source)
> 	at
> org.apache.derby.iapi.services.context.ContextManager.cleanupOnError(Unknown
> Source)
> 	at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
> Source)
> 	at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown
> Source)
> 	at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown
> Source)
> 	at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
> Source)
> 	at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
> Source)
> 	at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeQuery(Unknown
> Source)
> 	at
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
> 	at
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
> 	at
> org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeSelect(DatabaseAccessor.java:931)
> 	at
> org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:607)
> 	at
> org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeCall(DatabaseAccessor.java:535)
> 	at
> org.eclipse.persistence.internal.sessions.AbstractSession.basicExecuteCall(AbstractSession.java:1702)
> 	at
> org.eclipse.persistence.sessions.server.ServerSession.executeCall(ServerSession.java:566)
> 	at
> org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:207)
> 	at
> org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeCall(DatasourceCallQueryMechanism.java:193)
> 	at
> org.eclipse.persistence.internal.queries.DatasourceCallQueryMechanism.executeSelectCall(DatasourceCallQueryMechanism.java:264)
>
>
>
>
>
>