db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-389) With Network Server Database hangs after some time with many connections executing prepareStatement()
Date Thu, 23 Jun 2005 23:48:12 GMT
    [ http://issues.apache.org/jira/browse/DERBY-389?page=comments#action_12314369 ] 

Kathey Marsden commented on DERBY-389:
--------------------------------------

I am in the early stages with  this very serious stress bug for 10.1. The test is a network
server test but the problem is occuring when network server prepares the statement and appears
to me to be related to the statement cache. Rajesh is trying to reproduce on embedded.   He
says he can reproduce this very quickly  with his test.  10 mintutes or so and then nothing
else can be done with the database all clients hang.  He can create other databases, run runtimeinfo
etc, so Network server seems ok.


Nothing notable about the log except a lot of expected table not found errors. First wild
guess is  somethng related to some sort of lock problem when failed statements are handled
by the  cache.

One of the traces has  removeStatement which looks interesting to me.

"DRDAConnThread_7" prio=5 tid=0x0ae97d18 nid=0x988 waiting for monitor entry [0x0bdcf000..0x0bdcf9e4]
        at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.removeStatement(GenericLanguageConnectionContext.java)
        - waiting to lock <0x02fdfcd0> (a org.apache.derby.impl.services.cache.C
lock)
        at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java)


    /**
     * This method will get called if the statement is referencing tables in SESSION schema.
     * We do not want to cache such statements because multiple connections can have
     * different definition of the same table name and hence compiled plan for one connection
     * may not make sense for some other connection. Because of this, remove the statement
from the cache
     *
     * @exception StandardException thrown if lookup goes wrong.
     */

 Were there any changes this release related to or that might affect statement caching or
does this ring a bell for anyone?



> With Network Server Database hangs after some time with many connections executing prepareStatement()
> -----------------------------------------------------------------------------------------------------
>
>          Key: DERBY-389
>          URL: http://issues.apache.org/jira/browse/DERBY-389
>      Project: Derby
>         Type: Bug
>   Components: JDBC, Network Server
>     Versions: 10.1.1.0, 10.2.0.0
>     Reporter: Kathey Marsden
>     Assignee: Kathey Marsden
>     Priority: Critical
>  Attachments: RTINFO.txt, derby.log, javacore.20050622.135027.2491.txt, javacore.20050623.150509.22394.txt
>
> Rajesh found this issue in running Network Server system tests for the 10.1 release candidate
> While running the Network Server system test with 210 clients, 
> the  Network Server and all the clients hangs after some time. 
> A Ctrl+\ on the Network Server shows that upto 180 threads 
> waiting on the PreparedStatements to compile and comes from the 
> embedded engine. The following is the stack trace from the java 
> dump.
> 3XMTHREADINFO      "DRDAConnThread_181" (TID:1007C998, 
> sys_thread_t:85C4478, state:CW, native ID:4575ABB0) prio=5
> 4XESTACKTRACE          at java.lang.Object.wait(Native Method)
> 4XESTACKTRACE          at 
> java.lang.Object.wait(Object.java(Compiled Code))
> 4XESTACKTRACE          at 
> org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericSta
> tement.java(Compiled Code))
> 4XESTACKTRACE          at 
> org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatem
> ent.java)
> 4XESTACKTRACE          at 
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.
> prepareInternalStatement(GenericLanguageConnectionContext.java)
> 4XESTACKTRACE          at 
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(Embe
> dPreparedStatement.java)
> 4XESTACKTRACE          at 
> org.apache.derby.impl.jdbc.EmbedPreparedStatement20.<init>(Em
> bedPreparedStatement20.java)
> 4XESTACKTRACE          at 
> org.apache.derby.impl.jdbc.EmbedPreparedStatement30.<init>(Em
> bedPreparedStatement30.java)
> 4XESTACKTRACE          at 
> org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(Driver3
> 0.java)
> 4XESTACKTRACE          at 
> org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Embe
> dConnection.java)
> 4XESTACKTRACE          at 
> org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Embe
> dConnection.java)
> 4XESTACKTRACE          at 
> sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> 4XESTACKTRACE          at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethod
> AccessorImpl.java(Compiled Code))
> 4XESTACKTRACE          at 
> java.lang.reflect.Method.invoke(Method.java(Compiled Code))
> 4XESTACKTRACE          at 
> org.apache.derby.impl.drda.DRDAStatement.prepareStatementJDBC3(D
> RDAStatement.java)
> 4XESTACKTRACE          at 
> org.apache.derby.impl.drda.DRDAStatement.prepare(DRDAStatement.j
> ava)
> 4XESTACKTRACE          at 
> org.apache.derby.impl.drda.DRDAStatement.explicitPrepare(DRDASta
> tement.java(Compiled Code))
> 4XESTACKTRACE          at 
> org.apache.derby.impl.drda.DRDAConnThread.parsePRPSQLSTT(DRDACon
> nThread.java(Compiled Code))
> 4XESTACKTRACE          at 
> org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDACo
> nnThread.java(Compiled Code))
> 4XESTACKTRACE          at 
> org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.jav
> a)

-- 
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