Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Date: Fri, 03 Jun 2005 17:47:54 -0700
From: David Van Couvering <David.Vancouvering@Sun.COM>
Subject: Re: [jira] Updated: (DERBY-243) connection toString should uniquely
 identify the connection
In-reply-to: <42A0EBEC.7020001@sbcglobal.net>
To: Derby Development <derby-dev@db.apache.org>
Message-id: <42A0FA3A.7070702@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6)
 Gecko/20040113
References: <1301494969.1117065898591.JavaMail.jira@ajax.apache.org>
 <429CAAFF.80109@sbcglobal.net> <429CAC31.5080904@sun.com>
 <429CC768.30500@sbcglobal.net> <429CE6A5.3090904@sun.com>
 <42A0B693.6040306@sbcglobal.net> <42A0C854.7070803@gmail.com>
 <42A0D871.7020509@sbcglobal.net> <42A0E82E.10801@sun.com>
 <42A0EBEC.7020001@sbcglobal.net>

I found the problem, and it is an easy fix -- I missed a couple of 
places where the log code used "instanceNumber" instead of 
"getInstanceNumber()".  Thanks Sunitha for catching this; I didn't know 
about logStatementText and only checked by causing an error to occur and 
looking at the error output in derby.log, which didn't reveal this 
problem.

This seems like an important issue, so I will look into writing a new 
test that runs some statements with logStatementText turned on and then 
query the ErrorLog VTI, and make sure that the session id is the same 
for all output.

David

Mike Matrigali wrote:

> Just to make sure, the issue sunitha found with the commit and abort
> output is very important.  Tracking down store issues almost always
> comes down to matching up commmits/aborts with the session that
> executed them.
> 
> I agree that reading the UUID is a pain, but can adapt with careful
> post processing of derby.log files.  I would not hold up the change
> for that, but don't want to see it until the above is resolved.
> 
> Maybe someone can be inspired
> to finally write a better tool than (vi, vim, emacs), to read the
> derby.log statement text.  The hope was that by making the output
> easily parsible and having a vti
> would make it much easier for some sort of tool to be built:
>     o click a button see all statements in order for a given session
>     o click a button highlight aborted statements
>     o click a button see all queries on a given table
>     o click a button pull out real time taken by statements, ...
>     o ...
> 
> I don't know what is going on there.  Off hand I don't know how those
> were getting sesion id's originally, but could probably figure it out
> if you can't.
> 
> /mikem
> 
> David Van Couvering wrote:
> 
>> I agree that the UUID is a pain to read.  It definitely changes the 
>> game if we have a separate log for each system, I didn't know about this.
>>
>> My only concern is if for some reason the user decides to combine all 
>> the error logs, or if in the future we allow the user to use syslog or 
>> some other centralized log framework.  But I think I am being too 
>> paranoid.  We'll probably be fine with a simple integer if each system 
>> has its own separate log file.  IMHO we shouldn't try to solve the 
>> "combined error logs" problem until we see that it actually is a 
>> problem.  It seems like a real edge case and we shouldn't make 
>> everyone suffer reading UUIDs for something that may or may not ever 
>> be a problem.  It's easy enough to fix in the future.
>>
>> I do want to bring up what we want to do for network client 
>> connections.  DRDA generates a correlation token to uniquely identify 
>> each session.  This is the DRDAID that's printed out in the 
>> traces/logs.  It would be great for debugging if the network client 
>> Connection.toString() matched the DRDAID/correlation token (we have a 
>> JIRA item open for this that I am starting to look at).  However, the 
>> DRDA correlation token is actually fairly long and complex.  So this 
>> means we will have  a simple integer like "1" for embedded connections 
>> and something like "NF000001.A6C3-4327113699128910688" for network 
>> client connections.  A little odd, but I guess it's OK.  Does anyone 
>> else have concerns or thoughts about this?
>>
>> I can make the adjustment to this patch if all are OK with this. 
>> Sigh... :)  I'll get started on it and get the tests going so if we 
>> decide to go with it we can have a better chance of getting it into 10.1
>>
>> David
>>
>> Kathey Marsden wrote:
>>
>>> Sunitha Kambhampati wrote:
>>>
>>>
>>>> Although I havent looked at the diffs yet, but I applied the patch in
>>>> Derby-243 to see how the derby.log would look with
>>>> derby.language.logStatementText=true
>>>>
>>>> I notice now the output is a little hard to read with all the numbers
>>>> and letters to look at, but I guess thats OK since thats what we
>>>> decided on.
>>>>
>>>
>>> Well we should do the right thing.  I was willing to concede to UUID's
>>> but I really don't have to look at those logs all the time.
>>> I really hate to bring this up now, but after thinking about the error
>>> stream stuff and reviewing Dag's new test  I have some new thoughts on
>>> this issue myself and these are as follows.
>>>      * The switch to UUID's was to guarantee uniqueness in  the case
>>> where we have multiple
>>>          class loaders running multiple Derby systems in the same jvm.
>>>
>>>     *  If you do have multiple Derby systems in the same JVM,  you need
>>> to use the
>>>         derby.stream.error.*  properties to get your error log output
>>> separated.         (the default derby.log will just get clobbered by 
>>> the multiple
>>> systems.)
>>>         *  If we stick with integers  I think we get a unique id in each
>>> stream so have clear separation of connection id's.
>>>
>>> David can you convince me again that we need UUID's?  Sorry to bring
>>> this all up again #:(
>>>
>>>
>>> Kathey
>>>
>>>
>>
>>
>