[
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
