Hi, Kathey, some responses below...
Kathey Marsden wrote:
> David Van Couvering wrote:
>
[snip]
>
>
>>So I have been motivated to do this "right." I suspect using the
>>default toString would have been satisfactory, but the effort required
>>to do it "right" has been minimal once we figured out what "right" was.
>
>
> Did we figure that out yet?
>
> Could you give a brief summary of what your UUID means to the user
> when they see it?
> Connection.toString() is a pretty quick and dirty debugging technique.
> If you call toString() to debug your connections it would be nice if
> the output made it obvious what it meant without going to a manual.
>
The output is pretty straightforward, it tells you it is a connection
and then prints out the UUID. Here is an example:
Connection c013800d-0103-d219-2006-ffffe2f84f9d
I *did* notice that for a given run (I guess for the same VM instance),
all but the first part of the UUID sequence are identical, for example,
here is another connection in the same run
Connection 862e0071-0103-d219-2006-ffffe2f84f9d
This should make it easier to quickly identify a given connection when
reading output.
> For more advanced debugging folks tend to use the derby.log and the
> ErrorLogVTI, so if this effort is to assist with advanced debugging,
> these may be worth considering before connection toString() so that
> they can be hooked up in a meaningful way.
Yes, this was what Dan was talking about, that the VTIs should include a
column with the connection string that allows you to quickly correlate
more detailed information with a connection string you observed in your
debug output. I had proposed to make this a separate JIRA item.
>
> I wanted to also mention that currently in the derby.log for network
> server, we currently log a DRDAID which is the correlation token that I
> mentioned in my earlier mail. This id is a combination of the network
> address and the time in milliseconds and is something that is currently
> generated by the client but really should be generated by the server
> (DERBY-17). Just wanted to make sure that was considered in your
> connection identification solution. Not unique but certainly useful in
> debugging as you can see where the connection is coming from. And as
> you mentioned it would be nice to have that correlation between client
> and server, but it is not a UUID. Something to consider when you
> evaluate the id's we already have, as well as the new one, and how they
> all fit into the debugging picture.
I think it would be great to allow you to correlate a client and
server-side connection.
I am suggesting we log this as a separate JIRA item, to avoid piling too
much into DERBY-243, which only asks that connection toString() be unique.
One approach would be that the toString() of an embedded connection
created for a network session includes the DRDAID. However, I think
that makes the string output too complicated. An alternate approach is
to create a Connection VTI which includes this information.
The same thing can be said for PooledConnections -- they have a
relationship to an underlying physical connection. But rather than clog
up the toString() of PooledConnection with the id of the underlying
physical connection, I would rather see the Connection VTI provide this
information.
>
> I know I said hashcodes, counters, UUID's or whatever, but I am
> beginning to reconsider that position. If we are looking at the big
> connection identification picture, I would like to understand what we
> have, what the overall goals are and how what you are doing fits in
> with the existing id's. Too many id's can be as bad as not enough.
>
I am not fully sure I know what you mean by "what we have", but in terms
of connections, IMHO what we have currently is not sufficient -- a
mishmash of the default toString() output, "" (returned by
BrokeredConnection) and "EmbedConnection" for embedded connections.
To me the overall goal is to support debugging in critical situations,
which means to me providing a toString() representation that is unique
across any supported or envisioned usage models. Given that this
includes running in multiple classloaders (and I think this not going to
be uncommon), and after much discussion about unique identifiers, I am
convinced the righth approach is to use UUID.
In terms of how this fits with existing ids, I think the main thing that
needs to be addressed is what we discussed above: that relevant VTIs
include a correlation back to the owning connection so useful queries
can be run, and that we make it possible correlate an embedded
connection with its matching client-side connection. I think both of
these are beyond the scope of DERBY-243 but are worth working on as
separate items.
So, once we have a unique connection identifier as a basis, I think
there is a lot of opportunity here to provide some very useful detailed
debugging information.
>
>
>>I think there's value in a simple fix bringing up a larger issue for
>>discussion. I agree that you don't want to try and *fix* these larger
>>issues as part of the initial bug, rather they should be added as new
>>feature requests or bugs. But I think they are healthy discussions to
>>have and can improve the overall design and quality of the product.
>
>
> Yes, I agree, but I do think that it is good to start a new thread for
> new issues. Someone interested in a proposal on changing the jar files
> we distribute might not think to look under the connection toString
> thread. A new thread also provides more clear separation between the
> original issue and the larger issue it raised. There is a lot of mail
> ! You might be interested in the Jakarta project mail guidelines and
> associated links at: http://jakarta.apache.org/site/mail.html.
>
OK, thanks, that's valuable feedback. I will definitely keep that in
mind in the future.
What I can do in this instance is when I create separate JIRA items for
the things beyond the scope of DERBY-243, I will include in the comments
a link to this thread as well as a summary of what we discussed in this
thread.
David
> Kathey
>
>
|