db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-243) connection toString should uniquely identify the connection
Date Fri, 03 Jun 2005 23:30:54 GMT
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
> 
> 

Mime
View raw message