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
