You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@steitz.com> on 2004/02/12 04:57:30 UTC
Re: [PROPOSAL] [id] Prefix, UUID and Host StringIdentifierGenerator
Alban Peignier wrote:
> Hi everybody,
>
> I worked on three StringIdentifierGenerator implementations which can be
> useful.
>
> These is an "ASCII javadoc summary" :
>
> - PrefixStringIdentifierGenerator extends AbstractStringIdentifierGenerator
> PrefixStringIdentifier(String prefix, StringIdentifierGenerator)
> prefixes the identifier returns by the specified generator
> with the given prefix
>
> - HostStringIdentifierGenerator extends PrefixStringIdentifierGenerator
> HostStringIdentifierGenerator(StringIdentifierGenerator) :
> uses the local hostname
> HostStringIdentifierGenerator(InetAddress, StringIdentifierGenerator)
>
> - UUIDClockStringIdentifierGenerator
> extends AbstractStringIdentifierGenerator
> UUIDClockStringIdentifierGenerator(UUIDClock)
>
> Our goal is to be able to compose a HostStringIdentifierGenerator and a
> UUIDClockStringIdentifierGenerator to identify messages in a network
> application.
>
> PS : I can prepare a patch with these three classses. .. but not from this
> place, no real CVS access :o(.
Alban,
I have been playing around with similar ideas -- essentially concatenating
identifiers. We may want to enable more than two identifiers to be
concatentated, so I would suggest something more along the lines of a
CompositeIdentifierGenerator that could wrap an array or list of
IdentifierGenerators and use these to generate "composite" ids. One
example of this would be a CompositeStringIdentifierGenerator that uses
concatenation to combine ids. Another strategy might be concatenate, then
hash, etc.
I am not sure what the best design strategy will be here, but I think the
ability to compose identifiers using different composition strategies may
be a good thing to have.
Another sort of related thing that I have been thinking about is attaching
signatures to ids, so that their authenticity can be validated.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL] [id] Prefix, UUID and Host StringIdentifierGenerator
Posted by Phil Steitz <ph...@steitz.com>.
Alban Peignier wrote:
> Phil Steitz wrote:
>
>> I would suggest something more along the lines of a
>> CompositeIdentifierGenerator that could wrap an array or list of
>> IdentifierGenerators and use these to generate "composite" ids. One
>> example of this would be a CompositeStringIdentifierGenerator that
>> uses concatenation to combine ids. Another strategy might be
>> concatenate, then hash, etc.
>
>
> I started with the same idea .. I created a
> ConstantStringIdentifierGenerator .. and it looks very similar to the
> functor API. Which is the difference between a
> ConstantStringIdentifierGenerator and a ConstantStringGenerator ?
>
> The IdentifierGenerator could be a child of the
> functor.generator.Generator. In this case, all the functor API framework
> would be available (constant, composite, ...)
>
This is an interesting idea. I would be interested in others' opinions on
this. Implementing functor.generator.Generator would be a signinficant
change to the simple IdentifierGenerator interface, but I am open to
considering it. I can see essentially three ways to go here:
1. Make IdentifierGenerator extend functor.generator.Generator
2. Follow the pattern in the FlexiMap functor example
http://jakarta.apache.org/commons/sandbox/functor/xref-test/org/apache/commons/functor/example/FlexiMapExample.html#84
to make generation algorithms pluggable / composable
3. Don't use functors, use inheritance instead (more or less what I was
suggesting above)
Thinking about how to make 3 work, 2 is looking more and more attractive...
Any other ideas on how best to implement id composition?
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [PROPOSAL] [id] Prefix, UUID and Host StringIdentifierGenerator
Posted by Alban Peignier <al...@free.fr>.
Phil Steitz wrote:
> I would suggest something more along the lines of a
> CompositeIdentifierGenerator that could wrap an array or list of
> IdentifierGenerators and use these to generate "composite" ids. One
> example of this would be a CompositeStringIdentifierGenerator that
> uses concatenation to combine ids. Another strategy might be
> concatenate, then hash, etc.
I started with the same idea .. I created a
ConstantStringIdentifierGenerator .. and it looks very similar to the
functor API. Which is the difference between a
ConstantStringIdentifierGenerator and a ConstantStringGenerator ?
The IdentifierGenerator could be a child of the
functor.generator.Generator. In this case, all the functor API framework
would be available (constant, composite, ...)
--
Alban Peignier - alban.peignier@free.fr
http://www.tryphon.org/~alban
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [id] UUID update
Posted by Tim Reilly <ti...@consultant.com>.
Hi Gary,
[I wrote]
> I'll use bugzilla to attach what I've got so that everyone interested can
> review it. It'll not be in the form of patches yet
Bugzilla link:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27022
[Gary resolved with RESOLVED WONTFIX]
Resolved wontfix is fine (since, yes there is nothing to resolve or fix -
just a way to post the zip for review.)
But I'm unclear if there's more meaning to the resolution's comment:
> Please see http://jakarta.apache.org/commons/sandbox/id/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [id] UUID update
Posted by Tim Reilly <ti...@consultant.com>.
> I would attribute the "cryptographic quality" reference in section 4 as
> just referring to randomization. Making the PRNG pluggable might
> be a good
> compromise solution.
>
> Phil
I think that sounds good, for the version 4 (random bytes) uuid (I think
that's what you meant? - version 1 uses MD5 of system info or the MAC
address.)
The other calls to SecureRandom should be changed now that I understand more
about Random randomness.
I can send patches if or unless anyone wants to beat me to it.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [id] UUID update
Posted by Phil Steitz <st...@yahoo.com>.
--- Tim Reilly <ti...@consultant.com> wrote:
> Hi Phil,
>
> > Why, btw, did you think that we
> > needed to use SecureRandom? Is there any expectation in the spec
> > that the
> > random data will be cryptographically secure?
>
> Quoting
> http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-02.txt
> =============================================
> 4.5 Node IDs that do not identify the host
>
> This section describes how to generate a version 1 UUID if an IEEE
> 802 address is not available, or its use is not desired.
>
> One approach is to contact the IEEE and get a separate block of
> addresses. At the time of writing, the application could be found at
> [6], and the cost was US$550.
>
> A better solution is to obtain a 47-bit cryptographic quality random
> number, and use it as the low 47 bits of the node ID, with the most
> =============================================
>
> I took the last paragraph to mean use SecureRandom. I also took for
> granted
> that SecureRandom is "more" random than Random but haven't found
> authoritative advice on that, it seems to be true or well believed?
> Anyone
> know of documentation on the issue? The spec emphasizes the term "high
> quality random".
It all comes down to whether or not you care if a *sequence* of randomly
generated values is predictable. The default Random generator is not bad in
terms of dispersion (i.e., likelihood of collisions, number of matches
among bytes, etc.) but not "secure" in the sense that knowledge of previous
results has little or no value in predicting new values. See
http://en.wikipedia.org/wiki/Cryptographically_secure_pseudo-random_number_generator
for a little more on this.
>
> As far as I understand everything in the specification concerning version
> 1 - the only real guarantee that the id will be *universally* unique is
> when
> using the MAC address since it's from a central authority (and time
> shifting
> backwards is still an issue even when a Mac is used but that the clock
> sequence will deal with it if the generator does the time check and has
> stateful information to know to change the sequence. I won't mention that
> some NIC manufactures may have recycled Mac addresses according some
> posts I
> saw also failures in the state persistence are possible.)
Yes.
> Using alterative node identifiers should be done in a way to make it
> highly/extremely unlikely of a duplicate, but still the
> potential/probability (though small) exists that different system
> generate
> the same node, time, and clock sequence. It also depends on usage,
> duplicates may be generated in systems that never interact so the
> probability of duplicates within a group system actors is really what we
> care about in reality (usually I guess.)
SecureRandom offers no special advantage there. Two byte arrays generated
by a SecureRandom are no less likely to collide than a pair generated by a
Random (at least not significantly -- though the exact probablilities no
doubt differ, both will be remarkably close to expected binomial
probabilities in practice)
>
> I should mention that a security concern was raised about using the MAC
> address, when it will be exposed to other/outside systems. One side of
> the
> security concern is around privacy (the uuid can give away a time and a
> PC.)
> The other security issue I assume is if you've setup some sort of inbound
> firewall rules based on MAC addresses or other reasons not to publish
> your
> MAC's? I believe uuid.so and win32 CoCreateGUID both now generate version
> 4
> uuid's for that reason. Of course, the reality is that the version and
> implementation someone chooses should be guided by their requirements and
> how they are using it (between trusted secure/trusted systems or not.)
>
> Sorry for going on and on .. in answering a simple question ..took the
> opportunity to share some of the research I'd got on the topic. Should
> and
> probably needs to be in the documentation.
>
This is an important issue. I have never viewed GUIDs as in any way
"secure." As you point out, the MAC address is not at all secure. Maybe we
should support both "secure" and "non-secure" version 1 GUIDs.
The comment below in Section 7 suggests, however, that there is no
expectation of cryptographic security, so I guess I would favor the
"non-secure" approach:
Security Considerations
Do not assume that UUIDs are hard to guess; they should not be used
as capabilities, for example.
I would attribute the "cryptographic quality" reference in section 4 as
just referring to randomization. Making the PRNG pluggable might be a good
compromise solution.
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! Search - Find what you�re looking for faster
http://search.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [id] UUID update
Posted by Tim Reilly <ti...@consultant.com>.
Hi Phil,
> Why, btw, did you think that we
> needed to use SecureRandom? Is there any expectation in the spec
> that the
> random data will be cryptographically secure?
Quoting http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-02.txt
=============================================
4.5 Node IDs that do not identify the host
This section describes how to generate a version 1 UUID if an IEEE
802 address is not available, or its use is not desired.
One approach is to contact the IEEE and get a separate block of
addresses. At the time of writing, the application could be found at
[6], and the cost was US$550.
A better solution is to obtain a 47-bit cryptographic quality random
number, and use it as the low 47 bits of the node ID, with the most
=============================================
I took the last paragraph to mean use SecureRandom. I also took for granted
that SecureRandom is "more" random than Random but haven't found
authoritative advice on that, it seems to be true or well believed? Anyone
know of documentation on the issue? The spec emphasizes the term "high
quality random".
As far as I understand everything in the specification concerning version
1 - the only real guarantee that the id will be *universally* unique is when
using the MAC address since it's from a central authority (and time shifting
backwards is still an issue even when a Mac is used but that the clock
sequence will deal with it if the generator does the time check and has
stateful information to know to change the sequence. I won't mention that
some NIC manufactures may have recycled Mac addresses according some posts I
saw also failures in the state persistence are possible.)
Using alterative node identifiers should be done in a way to make it
highly/extremely unlikely of a duplicate, but still the
potential/probability (though small) exists that different system generate
the same node, time, and clock sequence. It also depends on usage,
duplicates may be generated in systems that never interact so the
probability of duplicates within a group system actors is really what we
care about in reality (usually I guess.)
I should mention that a security concern was raised about using the MAC
address, when it will be exposed to other/outside systems. One side of the
security concern is around privacy (the uuid can give away a time and a PC.)
The other security issue I assume is if you've setup some sort of inbound
firewall rules based on MAC addresses or other reasons not to publish your
MAC's? I believe uuid.so and win32 CoCreateGUID both now generate version 4
uuid's for that reason. Of course, the reality is that the version and
implementation someone chooses should be guided by their requirements and
how they are using it (between trusted secure/trusted systems or not.)
Sorry for going on and on .. in answering a simple question ..took the
opportunity to share some of the research I'd got on the topic. Should and
probably needs to be in the documentation.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [id] UUID update
Posted by Phil Steitz <ph...@steitz.com>.
Tim Reilly wrote:
>>Phil Steitz wrote:
>
> I imagine performance tests of anything using SecureRandom
> (VersionFourGenerator, and InMemoryStateImpl) may be dismal due to
> initialization.
Not just initialization. The calls are also *much* slower than Random.
> I think I did a static reference to the SecureRandom so it
> should be the first time that takes a while.
Yes, the static reference is there. Why, btw, did you think that we
needed to use SecureRandom? Is there any expectation in the spec that the
random data will be cryptographically secure?
Phil
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [id] UUID update
Posted by Tim Reilly <ti...@consultant.com>.
> Phil Steitz wrote:
...
> than updating the Apache license to 2.0. This is a good start. We need to
> get a better feel for stability / performance and some more eyeballs on
> this code, so I thought it best to get it into CVS now, even if we decide
> to refactor / repackage down the road. Thanks for the contribution.
It is a lot easier to talk about when it's under source control. The more
eyes for review the better, and as you mention below documenting the "why's"
will be helpful to that end. Let me know your thoughts on additional tests.
One I wanted to make sure of was the writes, and finalize in
ReadWriteFileImpl all happen as expected.
I imagine performance tests of anything using SecureRandom
(VersionFourGenerator, and InMemoryStateImpl) may be dismal due to
initialization. I think I did a static reference to the SecureRandom so it
should be the first time that takes a while. Some other strategies can be
built on top of what's there, like burst generation into a queue if need be.
> Some minimal xdocs, or more complete package documentation
> describing the
> implementation choices made would be a good thing to add about now. Most
> of this is in the code or mail archives, but it would be good to get it
> into the package docs or xdocs.
>
Certainly. Hopefully, I can get this done as soon as possible - probably
within the next few of days, sooner if I can.
> If you have not been following all of the commons-dev build
> stuff, you may
> have missed that you now need to co jakarta-commons-sandbox/sandbox-build
> to get the maven build to work.
I did manage to catch-up on most of the list. I really appreciate Mark and
other's effort doing this, I didn't want to have to checkout the entire
commons tree or have to think about selecting which bits to checkout aside
from [id] - so the change is welcome in my book...checking out as two
eclipse projects is much smoother. It also alleviates my need for the
commons.project.extendsUri=../sandbox-build/ which I was changing locally.
Not sure if you want to keep it or not?
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [id] UUID update
Posted by Phil Steitz <ph...@steitz.com>.
Tim Reilly wrote:
>>I will look at this stuff carefully this weekend, but one thing that
>>jumped out at me from your post above was that the "global lock" issue
>>might be avoidable by putting more into the node identifier, i.e., build
>>in a jvm identifier. IIRC, this is essentially what tomcat when
>>generating session ids to avoid collisions across jvms on the same host.
>>Just something to think about.
>>
>>Phil
>>
>
>
> I'm back. I'm thinking about this suggestion... My original concern is both
> with physical machines that run multiple jvm versions, as well as multiple
> instances of the same jvm (such as in an application server that is
> vertically clustered.)
>
> I don't know of an identifier that I can get that uniquely identifies a jvm
> instance, but there may be something (I'll dig around the tomcat code.)
> Coincidently, I do iterate the System properties and then create an MD5 of
> those concatenated with a random and a (new Object().hashCode()) to generate
> an artificial node id in StateHelper (used in the InMemoryStateImpl). Keep
> in mind, that *ideally* the Node.id is always the MAC address(s) though.
I investigated the tomcat code and concluded that my suggestion above is
no better/different really than what you are doing and has the
disadvantage of making the node id nonstandard (bad). AFAIK, there is no
magical way to generate a guaranteed unique jvm identifier.
> I think I submitted quite a bit to digest in the zip file. Something that
> may make things easier all around might be if I start on creating patches
> just for the VersionFour uuid generator (random uuid)? We can workout
> naming, package structure, and how best to tie in the factory and
> IdentifierUtils.
> Afterwards, we can look at the decisions about the more complex/troublesome
> version 1 generator.
> If this sounds good to everyone I'll start a new thread around that?
>
>
I went ahead and committed the changes in the zip, with no changes other
than updating the Apache license to 2.0. This is a good start. We need to
get a better feel for stability / performance and some more eyeballs on
this code, so I thought it best to get it into CVS now, even if we decide
to refactor / repackage down the road. Thanks for the contribution.
Some minimial xdocs, or more complete package documentation describing the
implementation choices made would be a good thing to add about now. Most
of this is in the code or mail archives, but it would be good to get it
into the package docs or xdocs.
If you have not been following all of the commons-dev build stuff, you may
have missed that you now need to co jakarta-commons-sandbox/sandbox-build
to get the maven build to work.
Phil
> ---------------------------------------------------------------------
> 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 update
Posted by Tim Reilly <ti...@consultant.com>.
> I will look at this stuff carefully this weekend, but one thing that
> jumped out at me from your post above was that the "global lock" issue
> might be avoidable by putting more into the node identifier, i.e., build
> in a jvm identifier. IIRC, this is essentially what tomcat when
> generating session ids to avoid collisions across jvms on the same host.
> Just something to think about.
>
> Phil
>
I'm back. I'm thinking about this suggestion... My original concern is both
with physical machines that run multiple jvm versions, as well as multiple
instances of the same jvm (such as in an application server that is
vertically clustered.)
I don't know of an identifier that I can get that uniquely identifies a jvm
instance, but there may be something (I'll dig around the tomcat code.)
Coincidently, I do iterate the System properties and then create an MD5 of
those concatenated with a random and a (new Object().hashCode()) to generate
an artificial node id in StateHelper (used in the InMemoryStateImpl). Keep
in mind, that *ideally* the Node.id is always the MAC address(s) though.
I think I submitted quite a bit to digest in the zip file. Something that
may make things easier all around might be if I start on creating patches
just for the VersionFour uuid generator (random uuid)? We can workout
naming, package structure, and how best to tie in the factory and
IdentifierUtils.
Afterwards, we can look at the decisions about the more complex/troublesome
version 1 generator.
If this sounds good to everyone I'll start a new thread around that?
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [id] UUID update
Posted by Phil Steitz <ph...@steitz.com>.
Tim Reilly wrote:
> I'll be traveling until March 1st - so I won't have much access to respond
> to comments or question regarding this post until after next week. However,
> looking forward to your thoughts.
>
>
Alrighty then :-)
I will look at this stuff carefully this weekend, but one thing that
jumped out at me from your post above was that the "global lock" issue
might be avoidable by putting more into the node identifier, i.e., build
in a jvm identifier. IIRC, this is essentially what tomcat when
generating session ids to avoid collisions across jvms on the same host.
Just something to think about.
Phil
> ---------------------------------------------------------------------
> 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 update
Posted by Tim Reilly <ti...@consultant.com>.
I'll be traveling until March 1st - so I won't have much access to respond
to comments or question regarding this post until after next week. However,
looking forward to your thoughts.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[id] UUID update
Posted by Tim Reilly <ti...@consultant.com>.
I'm writing tests, and getting ready to put some tentative documentation
together for the uuid code I'd like to contribute. I've made some changes
described below. (Note: I'm using
http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-02.txt for the
specification)
Version 1 uuid generation in java is much more challenging perhaps than in
native code for essentially three reasons:
- Time resolution
Java provides millisecond time resolution, the uuid spec calls for
100-nanosecond intervals since the Gregorian changeover epoch. The spec
allows for "artificial" clocking in systems that do not provide the required
time resolution. An additional challenge comes from the windows operating
system and low time resolution issues. The effective resolution on windows
can be from 1ms to reportedly 54ms. I create a NativeWin32ClockImpl
implementation of the Clock interface, but its performance was miserable
(~30 min for 11K timestamps), so not included.
- Persisting state
The uuid specification recommends persisting the clock sequence, node
identifier, and last uuid timestamp to stable storage. The spec offers some
hints of acceptable practices when writing to stable storage is not feasible
on every single uuid generation call due to performance concerns.
Additionally provisions are made for systems that do not have or can not use
stable storage. In java this is not necessarily an issue, except some
containers prevent file i/o, etc (which is for myself the first think that
comes to mind when I hear stable storage.)
- Device Wide Mutex's
The version 1 algorithm calls for obtaining a system wide lock during
uuid generation. Java virtual machines as far is know have no built in means
of working with a system wide mutex (some workarounds; such as opening a
socket, nio file locks, jni, are possible.) For java when multiple vm
instances are running, or multiple vm's in general are running the uuid
generator needs some way to know it is the only generator creating an id for
the given timestamp, clock sequence, node identifier (mac address) at that
instance.
So to address these issues I've created two new packages,
o.a.c.i.uuid.state, and o.a.c.i.uuid.clock, as well as an
o.a.c.i.uuid.NodeManager interface. Various implementations are possible to
work around the issues mentioned above. I've not used commons Discovery
before (hint, hint, code review), but the intention is to allow discovery to
locate the configured implementations.
The clock package:
Implementations of the o.a.c.i.uuid.clock.Clock interface may address the
time resolution issue in different ways (for example if a system has
available a java real-time library the implementer could use that.)
The state package:
Many diffent ways of addressing stable storage are possible, and the
container in which the code must execute may determine what implemation is
most appropriate. I've create 3 implementations; InMemoryOnlyImpl,
ReadOnlyResourceImpl, and ReadWriteFileImpl. More implementations are
possible; such as a jdbc, jndi, etc. [So long as some sort of locking is
create or used]
The NodeManager:
The NodeManager implementation I've worked on makes the assumption that each
jvm instance is assigned it's own node identifier (mac-address) Other
implementations of the node manager could attempt to use the same set of
node identifiers across vm's if they obtain a device wide lock; such as by
opening a socket, using a file lock, etc.
Other approaches to solving these issues are certainly possible. I could see
where one might publish an rmi service on a known port to service uuid
generation requests (the first vm to obtain the port would become the
server, any additional vm's would become clients.)
My intent is not to solve every possible implementation, but hopefully the
three major spi's allow for flexibility in version 1 generation, and provide
a few implementations that likely solve many of the requirements.
I'll use bugzilla to attach what I've got so that everyone interested can
review it. It'll not be in the form of patches yet (unless someone asks.) I
wanted to get some opinions prior to creating patches and submitting for
possible cvs commit. Additionally, I do have more tests todo and so I'm not
sure certain what expectation within a sandbox project is in terms of
stability of code. Some of the tests I want to do involve determining how
each implementation performs, as well as what I'd consider integration tests
(making sure the interaction between classes generates the correct events.)
Other notes:
With the number of classes this ends up being, I stopped prefixing
everything with UUIDXxxxXxx since it's redundant with the package name and
dropped the prefix from existing (this can be changed if there are
objections.)
I've added commons-codec as a dependency since the Hex.encode/decode methods
are so handy. I'm assuming we want to keep dependencies at a minimum. Hope
it's ok.
The zip I'll attach to bugzilla is out of synch with head, but depending on
the feedback I'll resynchronize prior to creating patches.
Look forward to your feedback
-TR
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [PROPOSAL] [id] Prefix, UUID and Host StringIdentifierGenerator
Posted by Tim Reilly <ti...@consultant.com>.
Sorry I've been MIA for the last week or two. I'm making some tentative
changes to the UUIDClock contract basically in order to accommodate systems
with multiple node identifiers I've realized that the Clock getUUIDTime
contract likely needs to be: returns a unique uuid timestamp within
consecutive calls per Node identifier (e.g. mac-address)
- The reason I qualify this with consecutive calls; is due to the fact that
the system time could move backwards due to a synchronization with an NTP
service or someone or something adjusting the systems clock backwards. (In
which case a new clock sequence needs to be created.)
- The reason to make this per Node identifier is because uniqueness of the
timestamp is critical for a particular node identifier + clock sequence
combination. If more than one node is present for the JVM then more uuids
can be generated for a given system time interval than is possible by using
only a single node identifier.
Alban - I wanted to give you a heads up regarding the possible change. If
the changes are not compatible with your work then perhaps some sort of
timestamp identifier implementation/generator not tied to the uuid generator
could be possible?
(Also I wanted let Phil, Gary, et al know I've not vanished ;-)
I'll hopefully have changes to post to bugzilla within the next few days.
Plus some documentation regarding the changes and see what everyone thinks.
-TR
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org