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
