db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <derby-...@db.apache.org>
Subject [jira] Assigned: (DERBY-1693) Out of Memory Error with derby.language.logStatementText=true
Date Tue, 17 Oct 2006 18:40:36 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1693?page=all ]

Kristian Waagan reassigned DERBY-1693:

    Assignee: Kristian Waagan

Having looked a little bit at this, I suggest adding (yet) another method to the DataValueDescriptor
interface, say getTraceString().

The reason for this, is that today the method getString() is used to obtain the text logged
to derby.log when derby.language.logStatementText is set to true. At the same time, this call
is also used for getting the values of data types to do other operations. If getString() is
changed to return a representation of the data that is only suitable for tracing, Derby will
stop working. NetBeans counted 207 usages of the method.

I tried changing getString(), and when executing a simple insert with a prepared statement,
Derby went down miserably with a stack overflow error.
I also tried adding the suggested getTraceString(), and things seemd to work (no LOB contents
in derby.log and the test succeded).

I think we can get away with a general implementation of getTraceString() that forwards to
getString() in DataType and then write specific implementations for the types that require
this (Clob and Blob).

Have I overlooked something, or will this approach cause trouble?
If I don't get pushback, I will create a patch for the suggested approach.

> Out of Memory Error with derby.language.logStatementText=true
> -------------------------------------------------------------
>                 Key: DERBY-1693
>                 URL: http://issues.apache.org/jira/browse/DERBY-1693
>             Project: Derby
>          Issue Type: Bug
>    Affects Versions:
>         Environment: JVM INFO :
> java version "1.5.0_02"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-b09)
> Java HotSpot(TM) Client VM (build 1.5.0_02-b09, mixed mode)
> OS : Windows XP Professional
>            Reporter: Manjula Kutty
>         Assigned To: Kristian Waagan
>            Priority: Minor
> While running a test with blobs and clobs of random size but not exceeding more than
5MB , with derby.language.logStatementText=true , The inserts are faling with out of memory
error. Once that error occurs then the test loses all connections to the database. If I take
off the derby.language.logStatementText=true property from derby.properties, the test runs
fine. Here is the stack Trace
> java.lang.OutOfMemoryError: Java heap space
> ---SQLException Caught---
> SQLState:   XJ001
> Severity: 0
> Message:  Java exception: 'Java heap space: java.lang.OutOfMemoryError'.
> java.lang.OutOfMemoryError: Java heap space
> java.sql.SQLException: No current connection.
>         at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExc
> eptionFactory.java:45)
>         at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:89)
>         at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:105)
>         at org.apache.derby.impl.jdbc.Util.noCurrentConnection(Util.java:209)
>         at org.apache.derby.impl.jdbc.EmbedConnection.checkIfClosed(EmbedConnect
> ion.java:1351)
>         at org.apache.derby.impl.jdbc.EmbedConnection.setupContextStack(EmbedCon
> nection.java:1529)
>         at org.apache.derby.impl.jdbc.EmbedConnection.rollback(EmbedConnection.j
> ava:946)
>         at com.ibm.db2j.tests.scenario.utils.DbTasks.insertMail(DbTasks.java:400
> )
>         at com.ibm.db2j.tests.scenario.tasks.Refresh.insertMail(Refresh.java:62)
>         at com.ibm.db2j.tests.scenario.tasks.Refresh.doWork(Refresh.java:43)
>         at com.ibm.db2j.tests.scenario.tasks.Refresh.run(Refresh.java:21)

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


View raw message