db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Solberg <Ole.Solb...@Sun.COM>
Subject Re: Another kind of stress.multi failiure
Date Sun, 02 Mar 2008 13:14:27 GMT
Re: Sun stress.multi failures. Are they really DERBY-1750?
----------------------------------------------------------

Kathey Marsden wrote:
 > The latest regression test failures analysis for the sun reports show
 > DERBY-1750
 > for the stress.multi failures.
 > 
http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/632391_bySig.html 

 >
 >
 > I am wondering  if it is really  DERBY-1750 or
 > perhaps is a NullPointerException in the derby.log (DERBY-3362?).

This one I have not seen in the cases I have looked at so far.

 >
 > The reason I ask is I saw two instances of this on Windows XP IBM 1.5
 > with the regular stress.multi run and on Linux  IBM 1.6 with the
 > encryption stress.multi run.  I am wondering if something changed
 > recently to make DERBY-3362 show up in the stress.multi runs.
 >


Re: Another kind of stress.multi failiure
-----------------------------------------
Kathey Marsden wrote:
> I am looking at another type of stress.multi failure that doesn't have 
> an immediate cause apparent in
> the derby.log that I can see.
> 
> The diff is:
> 7 del
> < ...running last checks via final.sql
> 7 add
>  > ...timed out trying to kill all testers,
>  >    skipping last scripts (if any).  NOTE: the
>  >    likely cause of the problem killing testers is
>  >    probably not enough VM memory OR test cases that
>  >    run for very long periods of time (so testers do not
>  >    have a chance to notice stop() requests
> Test Failed.
> 
> The testers that are stuck are stuck on the same statement e.g.
> -- 
> update main2 set y = 'zzz' where x = 5;
> ERROR 08000: Connection closed by unknown interrupt.
> ERROR XJ001: Java exception: ': java.lang.InterruptedException'.
> 
> The interupt exception shows:
> java.lang.InterruptedException
>        at java.lang.Object.wait(Native Method)
>        at java.lang.Object.wait(Object.java:199)
>        at 
> org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:195) 
> 
>        at 
> org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:88) 
> 
>        at 
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConn

> 
> ctionContext.java:768)
>        at 
> org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:606)
>        at 
> org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:555)
>        at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:329)
>        at 
> org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:508)
>        at 
> org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:350)
> 
> 
> The code at line 195 of GenericStatement shows:
>          ....
>                try {
>                    preparedStmt.wait();
>                } catch (InterruptedException ie) {
>                    throw StandardException.interrupt(ie);
>                }
> 
> My first guess is that this is perhaps some type of Statement cache 
> concurrency bug, but perhaps
> I am reading it wrong.  My question is: Is this enough information to 
> file a bug or am I likely
> missing something else important in the derby.log?
> 
> 
> Thanks
> 
> Kathey
> 
> 
> 
> 
> 

I had a look at a few of (all) these failures we are seeing now. There 
are some cases with a signature like the one below, but most seems to be 
the original 1750 as far as I can see.


The similar signature is:
update main2 set y = 'zzz' where x = 5 :End prepared statement
2008-03-01 21:34:48.598 GMT Thread[Thread-4,5,workers] (XID = 927008), 
(SESSIONID = 5045), (DATABASE = mydb), (DRDAID = null), Committing
2008-03-01 21:34:48.599 GMT Thread[Thread-4,5,workers] (XID = 927008), 
(SESSIONID = 5045), (DATABASE = mydb), (DRDAID = null), Rolling back
2008-03-01 21:34:48.600 GMT Thread[Thread-4,5,workers] (XID = 927236), 
(SESSIONID = 5046), (DATABASE = mydb), (DRDAID = null), Committing
2008-03-01 21:47:11.438 GMT Thread[Thread-4,5,workers] (XID = 927236), 
(SESSIONID = 5046), (DATABASE = mydb), (DRDAID = null), Cleanup action 
starting
ERROR 08000: Connection closed by unknown interrupt.
	at org.apache.derby.iapi.error.StandardException.newException(Unknown 
Source)
	at org.apache.derby.iapi.error.StandardException.interrupt(Unknown Source)
	at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
	at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source)
	at 
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown

Source)
	at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
	at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
	at org.apache.derby.impl.tools.ij.ij.executeImmediate(Unknown Source)
	at org.apache.derby.impl.tools.ij.utilMain.doCatch(Unknown Source)
	at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(Unknown Source)
	at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source)
	at org.apache.derby.impl.tools.ij.mtTestCase.runMe(Unknown Source)
	at org.apache.derby.impl.tools.ij.mtTester.run(Unknown Source)
	at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.InterruptedException
	at java.lang.Object.wait(Native Method)
	at java.lang.Object.wait(Object.java:485)
	... 12 more


I will upload the logs from some of these cases to 
http://dbtg.thresher.com/derby/test/debug/stress.multi/



-- 
Ole Solberg, Database Technology Group,
Sun Microsystems, Trondheim, Norway

Mime
View raw message