db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [jira] Updated: (DERBY-243) connection toString should uniquely identify the connection
Date Fri, 03 Jun 2005 23:46:52 GMT
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.


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

View raw message