On 19.04.11 23:51, Dave Brosius wrote:
On 04/19/2011 02:39 PM, Kathey Marsden wrote:
On 4/19/2011 8:37 AM, Lily Wei wrote:
Hi David:
I tried with an empty directory for the same test with your fix.
It also failed for me with the patch.
So it sounds specifically related to the patch. I wonder if at
whatever point these objects are supposed to be dropped, there are
open result sets so it doesn't actually get dropped. Is there
anything in the derby.log about maybe not being able to drop the
Phase table because of open result sets?
Only thing of interest is this, nothing related to the Phase table:
Sun Apr 17 04:57:15 EST 2011 : Execution failed because of Permanent
Agent Error: SVRCOD = 40; RDBNAM = srvdscreateshutdowndb1;create=true;
diagnostic msg = ASSERT FAILED pbsd is not expected to be null
org.apache.derby.impl.drda.DRDAProtocolException: Execution failed
because of Permanent Agent Error: SVRCOD = 40; RDBNAM =
srvdscreateshutdowndb1;create=true; diagnostic msg = ASSERT FAILED
pbsd is not expected to be null
at
org.apache.derby.impl.drda.DRDAProtocolException.newAgentError(DRDAProtocolException.java:339)
at
org.apache.derby.impl.drda.DRDAConnThread.sendUnexpectedException(DRDAConnThread.java:8378)
at
org.apache.derby.impl.drda.DRDAConnThread.handleException(DRDAConnThread.java:8329)
at
org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:319)
Sun Apr 17 04:57:15 EST 2011 : ASSERT FAILED pbsd is not expected to
be null
org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED
pbsd is not expected to be null
at
org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120)
at
org.apache.derby.impl.drda.DRDAConnThread.writePBSD(DRDAConnThread.java:2726)
at
org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:1044)
at
org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:294)
Looking at the stack trace, the assert is related to the piggy-backing
of session state data. This was added as DERBY-3192, and I also made
minor some changes as part of DERBY-3596.
I haven't looked at your patch, so I have no idea what causes the assert
to trigger. Things start looking at may be whether protocol flows have
been changed, or if a deferred reset is taking place.
Out of curiosity, do all the tests pass when you run with an insane
build? [*]
Regards,
--
Kristian
* Even if they pass, a performance regression for the client driver may
have been introduced (typically one extra round-trip to get the session
data).
