Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4DAE0037.9060304@apache.org>
Date: Tue, 19 Apr 2011 23:35:51 +0200
From: Kristian Waagan <kristwaa@apache.org>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US;
 rv:1.9.2.15) Gecko/20110313 Thunderbird/3.1.9
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: junit failures
References: <20110414155540.24777.qmail@njord-qa>
	<4DAB0ACD.9000802@apache.org>	<x6ipubzryv.fsf@oracle.com>
 <BANLkTinnXG2exqDiUxZOFrF3QaAxK7whaw@mail.gmail.com>
 <4DADD6FF.8050004@sbcglobal.net> <4DAE03C5.3050106@mebigfatguy.com>
In-Reply-To: <4DAE03C5.3050106@mebigfatguy.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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