You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Tim Reilly <ti...@consultant.com> on 2004/01/20 11:07:19 UTC
[id] UUID sending more code and a question or two
I'd decided to test my time (clock) values against the example code in the
uuid draft. The problem was (a: I'm 10yrs rusty in C/C++) and b) I'd get
about a 34.07xx year difference in my return values versus what the C code
in the draft is giving. Eventually, I figured out to upcast the time
struct's return values to unsigned long long before multiplying and that
gave much better results. ... anyone see anything not ok, I think I'm ok
with this?
int main() {
struct timeval tp;
gettimeofday(&tp, (struct timezone *)0);
/* Offset between UUID formatted times and Unix formatted times.
UUID UTC base time is October 15, 1582.
Unix base time is January 1, 1970.*/
unsigned long long offset = 0x01B21DD213814000;
printf ("\nUUID w/o upcast: %llu", (tp.tv_sec * 10000000) +
(tp.tv_usec * 10) + offset);
printf ("\nUUID: %llu", ((unsigned long long)tp.tv_sec * 10000000)
+ ((unsigned long long)tp.tv_usec * 10) + offset);
return 0;
}
With that I'll create a bugzilla enhancement to add the UUIDClock and
UUIDSystemClock code for review. UUIDClock has changed to an interface,
UUIDSystemClock uses the System class to get the time, without the thread
and other code to compensate for time resolution issues. The code that was
in UUIDClock I now have in a class called UUIDThreadClock (having some
issues with the unit tests seeming to hang, I'll send when I can get that
resolved).
It would be difficult for me to use the C code in the unit tests (but not
impossible I suppose.) I guess the question is .. should the unit tests have
this / JNI code? I felt it was important to test against the C reference
code in the UUID draft appendix, since any errors in implementation for this
code can't be fixed easily (the unique contract depends on correctly
implementing the spec.)
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [id] UUID sending more code and a question or two
Posted by Tim Reilly <ti...@consultant.com>.
> What exactly is this showing that could not be tested in Java or by
running
> a Java test using a pre-generated file of GUIDs made with the C code?
What
> I meant in my earlier response was that the pain of maintaining and
> distributing C code with the unit tests did not seem justified by the
> value. Maybe I am missing something?
No not missing anything. I see your point effort != value. My feeling at
this point is that the time test using native code was really an oracle*
test (I was overly confident my formatting code was correct; so I looked for
the problem to be in the time value.) The time calculating is straight
forward so I'd agree doesn't need to be part of a unit test.
*oracle: "Independent generation of expected results", not oracle the
vendor.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [id] UUID sending more code and a question or two
Posted by Phil Steitz <st...@yahoo.com>.
--- Tim Reilly <ti...@consultant.com> wrote:
<snip/>
> > I agree the JNI will be a PITA for me, especially since I'm re-learning
> C. I
> have a simple program working on Win2K and RH8. I'm not sure if the code
> would need to be recompiled for each target platform (at least making it
> an
> optional test might be good)? Perhaps running the test initially was
> sufficient? I'm not sure if Phil is minus on the JNI testing or for
> native
> code in the range test realizing what I'd proposed wouldn't work anyhow?
> Regardless, both points above are valid. The sample output (run2) below
> shows the interleaving calls not working which is logical without some
> delay
> in the calls, and as Noel suggests "capture the output and compare" would
> probably be the approach. I don't mind doing the jni (learn something
> new)
> but Phil are you minus on the jni range testing (past my own sanity tests
> here) or jni in the unit tests generally speaking?
The problem is that I don't see what this is really buying us. If I
understand the spec correctly, there are three things to test: format,
clock agreement and correct handling of the situation where requests arrive
at a rate faster than the clock resolution. The first two we should be
able to test in Java. Exact behavior in the third case will likely be
machine- and language-dependent, but again should be testable in Java.
>
>
> Sample output from my tests; right now I call an .exe using
> Runtime.exec...
> //Run 1
> From C reference code
> 132940402931250000
> From java
> 132940402931250000
> From C reference code
> 132940402931562500
>
> //Run 2
> From C reference code
> 132940403477187500
> From java
> 132940403477180000
> From C reference code
> 132940403477343750
>
What exactly is this showing that could not be tested in Java or by running
a Java test using a pre-generated file of GUIDs made with the C code? What
I meant in my earlier response was that the pain of maintaining and
distributing C code with the unit tests did not seem justified by the
value. Maybe I am missing something?
Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [id] UUID sending more code and a question or two
Posted by Tim Reilly <ti...@consultant.com>.
> > That sounds like a PITA and I wonder if we are really thinking
> about this
> > correctly. Interleaving JNI calls and comparing timestamps will be hard
> > and ultimately inconclusive, IIUC. What exactly did you have in mind
> here?
>
> Why not run the native code, capture the output, and compare?
Let me start from what brought me to testing the time against the C code. I
was working on UUIDGenerator.java and once far enough along I felt I should
compare the string output from a ms-guid to the values I generated.
Reversing the time fields should have given me approximate values. It
didn't. My next step was to add a test to tell me if the time I was
generating was close to the time from someone else's uuid implementation.
Going back to the ietf-draft was an easy choice since the appendix contains
reference C code. After banging my head against the wall due to the time
differences I'd get (which turned out to be an overflow in my C code.) The
java time generation was fine, so I need to look elsewhere.
I agree the JNI will be a PITA for me, especially since I'm re-learning C. I
have a simple program working on Win2K and RH8. I'm not sure if the code
would need to be recompiled for each target platform (at least making it an
optional test might be good)? Perhaps running the test initially was
sufficient? I'm not sure if Phil is minus on the JNI testing or for native
code in the range test realizing what I'd proposed wouldn't work anyhow?
Regardless, both points above are valid. The sample output (run2) below
shows the interleaving calls not working which is logical without some delay
in the calls, and as Noel suggests "capture the output and compare" would
probably be the approach. I don't mind doing the jni (learn something new)
but Phil are you minus on the jni range testing (past my own sanity tests
here) or jni in the unit tests generally speaking?
Sample output from my tests; right now I call an .exe using Runtime.exec...
//Run 1
>From C reference code
132940402931250000
>From java
132940402931250000
>From C reference code
132940402931562500
//Run 2
>From C reference code
132940403477187500
>From java
132940403477180000
>From C reference code
132940403477343750
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [id] UUID sending more code and a question or two
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > should the unit tests have [native] / JNI code?
> > I felt it was important to test against the C
> > reference code in the UUID draft appendix
> That sounds like a PITA and I wonder if we are really thinking about this
> correctly. Interleaving JNI calls and comparing timestamps will be hard
> and ultimately inconclusive, IIUC. What exactly did you have in mind
here?
Why not run the native code, capture the output, and compare?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [id] UUID sending more code and a question or two
Posted by Phil Steitz <st...@yahoo.com>.
--- Tim Reilly <ti...@consultant.com> wrote:
> With that I'll create a bugzilla enhancement to add the UUIDClock and
> UUIDSystemClock code for review. UUIDClock has changed to an interface,
> UUIDSystemClock uses the System class to get the time, without the thread
> and other code to compensate for time resolution issues. The code that
> was
> in UUIDClock I now have in a class called UUIDThreadClock (having some
> issues with the unit tests seeming to hang, I'll send when I can get that
> resolved).
Sounds good.
>
> It would be difficult for me to use the C code in the unit tests (but not
> impossible I suppose.) I guess the question is .. should the unit tests
> have
> this / JNI code? I felt it was important to test against the C reference
> code in the UUID draft appendix, since any errors in implementation for
> this
> code can't be fixed easily (the unique contract depends on correctly
> implementing the spec.)
>
That sounds like a PITA and I wonder if we are really thinking about this
correctly. Interleaving JNI calls and comparing timestamps will be hard
and ultimately inconclusive, IIUC. What exactly did you have in mind here?
Phil
__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [id] UUID sending more code and a question or two
Posted by Tim Reilly <ti...@consultant.com>.
Hi Noel,
> Which UUID draft?
> http://www.webdav.org/specs/draft-leach-uuids-guids-01.txt?
I'm going off this;
http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-01.txt
they are almost identical, except this one is current and adds the uuid urn
namespace, and going to RFC status as I understand. I sent a comment to the
author's of the draft exaplaining the overflow I got and Rich Salz wrote
back noting his intention send in an editorial revision to the RFC (also
noting it's a portability issue.)
> Isn't this something that the SOAP/Axis projects also need, and could
> benefit from?
Yes. Hopefully once the implementation is done, Axis, OJB, Jetspeed, at al
can use this.
Back in August a question came up on the jetspeed list about uuid code, I
looked around a saw the Axis implementation. Back then I proposed to Axis
list and [lang] commons-dev list to move the Axis implementation into
o.a.c.lang. The axis folks had no problem sharing the code but would hold
off on integrating it. On the lang list someone pointed out that the Tyrex
uuid may be better. Some history on the uuid thread:
http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg32052.html
So in the end I'm trying to write a "best of" implementation (i hope.) I did
forget about the Axis code though, and that I can pick up code from there as
needed since the license is ASF.
> Agreed. What about including the C code from the draft
> specification in the
> test, and then comparing output from the reference implementation against
> our implementation?
That was my question. I think it could be valuable, but wasn't sure about
people's feelings regarding JNI. We could change the testRange test to get
the time from the C code before and after generating the time from java and
make sure the time is in between?
> And I'm not sure what AXIS C uses for UUID
> generation.
I'd looked at the APR code briefly, I should look at the Axis C code as
well.
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: Tuesday, January 20, 2004 11:10 AM
> To: Jakarta Commons Developers List
> Subject: RE: [id] UUID sending more code and a question or two
>
>
> Tim Reilly wrote:
> > I'd decided to test my time (clock) values against the
> > example code in the uuid draft.
>
> Which UUID draft?
> http://www.webdav.org/specs/draft-leach-uuids-guids-01.txt?
>
> Isn't this something that the SOAP/Axis projects also need, and could
> benefit from? ref:
> http://ws.apache.org/axis/java/apiDocs/org/apache/axis/components/
> uuid/packa
> ge-summary.html
>
> > I'd get about a 34.07xx year difference in my return values
> > versus what the C code in the draft is giving. Eventually,
> > I figured out to upcast the time struct's return values to
> > unsigned long long before multiplying
>
> > It would be difficult for me to use the C code in the unit tests
> > (but not impossible I suppose.)
>
> > I felt it was important to test against the C reference code
> > in the UUID draft appendix
>
> Agreed. What about including the C code from the draft
> specification in the
> test, and then comparing output from the reference implementation against
> our implementation? And I'm not sure what AXIS C uses for UUID
> generation.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [id] UUID sending more code and a question or two
Posted by "Noel J. Bergman" <no...@devtech.com>.
Tim Reilly wrote:
> I'd decided to test my time (clock) values against the
> example code in the uuid draft.
Which UUID draft?
http://www.webdav.org/specs/draft-leach-uuids-guids-01.txt?
Isn't this something that the SOAP/Axis projects also need, and could
benefit from? ref:
http://ws.apache.org/axis/java/apiDocs/org/apache/axis/components/uuid/packa
ge-summary.html
> I'd get about a 34.07xx year difference in my return values
> versus what the C code in the draft is giving. Eventually,
> I figured out to upcast the time struct's return values to
> unsigned long long before multiplying
> It would be difficult for me to use the C code in the unit tests
> (but not impossible I suppose.)
> I felt it was important to test against the C reference code
> in the UUID draft appendix
Agreed. What about including the C code from the draft specification in the
test, and then comparing output from the reference implementation against
our implementation? And I'm not sure what AXIS C uses for UUID generation.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org