You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@juddi.apache.org by Maarten Coene <Ma...@ToughGuy.net> on 2002/01/22 17:50:05 UTC
[jUDDI-developers] JavaUUIDGen
Hi,
I've changed the pure Java UUID Generator (org.juddi.uuidgen.JavaUUIDGen) to
use real IEEE 802 ethernet addresses instead of a SecureRandom which slowed
down the generation process a lot. The counterpart of this approach is that
Java doesn't provide a way to retrieve this address. This means that a
person who want to use this Java UUID Generator must specify his ethernet
address in the juddi.properties configuration file. I've included an empty
property for this in the juddi.properties file and also put an example of an
ethernet address in there. The old Java UUIDGenerator is also still there
and is called org.juddi.uuidgen.SecureRandomUUIDGen.
There also have to be explained to the user how to retrieve this ethernet
address for different platforms. I don't know where this should be placed
(perhaps in an INSTALL file or something similar -> who will do this????).
Here is a possible way to retrieve this address in Windows 2000/XP (and
probably older version too):
1. Go to the console window (DOS prompt in older versions)
2. At the prompt, type: "ipconfig /all" (without the quotes ;-))
You'll receive something like this:
Windows IP Configuration
Host Name . . . . . . . . . . . . : atlantis
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Unknown
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : kotnet.org
Description . . . . . . . . . . . : D-Link DE-528 Ethernet PCI
Adapter
Physical Address. . . . . . . . . : 00-50-BA-AC-AA-55
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 10.67.29.254
3. Enter the value found at the "Physical Address" property in the
juddi.properties configuration file.
I don't know how to retrieve this address using other platforms, but I'll
guess someone of you knows...
Note that at the moment the ethernet address must be entered in this
hexadecimal form.
Maarten
RE: [jUDDI-developers] JavaUUIDGen
Posted by Maarten Coene <Ma...@ToughGuy.net>.
This was exactly the plan :-)
The secure random version will also be "improved" by a background thread
generating some UUID's in advance so these generated UUID's would we
available immediately.
Maarten
At 20:24 22/01/2002 -0500, Alex Ceponkus wrote:
>Thanks for doing this work Maarten. Just brainstorming and curious what
>others think ... would it make sense to: by default have 0 (or something
>else invalid) as the ethernet address in the properties file which will
>force juddi to use the secure random version of the java uuid generator.
>Then if they put in a real ethernet address, we automagically switch to
>Maarten's updated UUID generator. Just worried that most people will just
>leave the defaults as is. Thoughts?
>
>Alex
>
> > -----Original Message-----
> > From: juddi-developers-admin@lists.sourceforge.net
> > [mailto:juddi-developers-admin@lists.sourceforge.net]On Behalf Of
> > Maarten Coene
> > Sent: Tuesday, January 22, 2002 7:04 PM
> > To: juddi-developers@lists.sourceforge.net
> > Cc: MacBelgium@toughguy.net
> > Subject: [jUDDI-developers] JavaUUIDGen
> >
> >
> > Hi,
> >
> > I've changed the pure Java UUID Generator
> > (org.juddi.uuidgen.JavaUUIDGen) to
> > use real IEEE 802 ethernet addresses instead of a SecureRandom
> > which slowed
> > down the generation process a lot. The counterpart of this
> > approach is that
> > Java doesn't provide a way to retrieve this address. This means that a
> > person who want to use this Java UUID Generator must specify his ethernet
> > address in the juddi.properties configuration file. I've included an empty
> > property for this in the juddi.properties file and also put an
> > example of an
> > ethernet address in there. The old Java UUIDGenerator is also still there
> > and is called org.juddi.uuidgen.SecureRandomUUIDGen.
> >
> > There also have to be explained to the user how to retrieve this ethernet
> > address for different platforms. I don't know where this should be placed
> > (perhaps in an INSTALL file or something similar -> who will do this????).
> > Here is a possible way to retrieve this address in Windows 2000/XP (and
> > probably older version too):
> >
> > 1. Go to the console window (DOS prompt in older versions)
> > 2. At the prompt, type: "ipconfig /all" (without the quotes ;-))
> > You'll receive something like this:
> >
> > Windows IP Configuration
> >
> > Host Name . . . . . . . . . . . . : atlantis
> > Primary Dns Suffix . . . . . . . :
> > Node Type . . . . . . . . . . . . : Unknown
> > IP Routing Enabled. . . . . . . . : No
> > WINS Proxy Enabled. . . . . . . . : No
> >
> > Ethernet adapter Local Area Connection:
> >
> > Connection-specific DNS Suffix . : kotnet.org
> > Description . . . . . . . . . . . : D-Link DE-528 Ethernet PCI
> > Adapter
> > Physical Address. . . . . . . . . : 00-50-BA-AC-AA-55
> > Dhcp Enabled. . . . . . . . . . . : Yes
> > Autoconfiguration Enabled . . . . : Yes
> > IP Address. . . . . . . . . . . . : 10.67.29.254
> >
> > 3. Enter the value found at the "Physical Address" property in the
> > juddi.properties configuration file.
> >
> > I don't know how to retrieve this address using other platforms, but I'll
> > guess someone of you knows...
> >
> > Note that at the moment the ethernet address must be entered in this
> > hexadecimal form.
> >
> > Maarten
> >
> >
> >
> > _______________________________________________
> > juddi-developers mailing list
> > juddi-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/juddi-developers
> >
> >
--
Maarten Coene
Katholieke Universiteit Leuven
Dept. Computerwetenschappen Tel: ++32 (0)16/32 78 25
Celestijnenlaan 200A
B-3001 Heverlee
[jUDDI-developers] init() and destroy()
Posted by Maarten Coene <Ma...@ToughGuy.net>.
Hi,
in a lot of interfaces, there is an init() and destroy() method (for
example: UUIDGen, Authenticator, Configurator, ...). Shouldn't this init()
method be used in the corresponding factory? What happens now is that in
some interface implementations, the init() method is called in the
constructor (SimpleAuthenticator, JavaUUIDGen) or isn't called at all
(SimpleConfigurator). I think the factory should call this init() method
after creating the object. For example with the AutenticatorFactory:
try
{
Class authClass = Class.forName(authClassName);
Authenticator authenticator = (Authenticator) authClass.newInstance();
authenticator.init();
return authenticator;
}
What do you think?
Maarten
RE: [jUDDI-developers] JavaUUIDGen
Posted by Bob Hablutzel <bo...@hablutzel.com>.
A big difference - if multiple JVMs are running with the UUID server at the
same time. Synchronization is localized to a JVM, so you would have a race
condition if multiple JVMs are running (particularly on multiple-CPU
servers).
Obtaining a system-wide resource lock prevents this race condition.
hab
-----Original Message-----
From: Maarten Coene [mailto:MacBelgium@ToughGuy.net]
Sent: Wednesday, January 23, 2002 9:42 AM
To: Bob Hablutzel; juddi-developers@lists.sourceforge.net
Subject: RE: [jUDDI-developers] JavaUUIDGen
Hi,
looks interesting, but it seems like a sort of hack to me. I was wondering:
is there a difference between making the JavaUUIDGen class a Singleton
together with a synchronized nextUUID() method and your proposal?
Maarten
At 08:44 23/01/2002 -0500, Bob Hablutzel wrote:
>Maarten -
>
> The basic idea was to use a system resource that imposes locking
>semantics, since Java doesn't provide direct access to low-level
system-wide
>locking constructs. So, for example, a TCP/IP port can only be bound by one
>thread of execution at once; a file can atomically be created if it didn't
>exist, and so forth.
> The implementation I was working on used server sockets as the locking
>mechanism. It looks something like this:
>
> obtain lock: ServerSocket lock = new ServerSocket(
8090 );
> release lock: lock.close(); lock = null;
>
> So far, it's worked on both NT and Linux; I can test it under Solaris
in
>a day or so. Interestingly, the latency isn't bad at all. I was worried
>about the reopen time-out of TCP ports, but that seems to only apply only
if
>you actually accept connections. Since the lock only requires a bind (which
>is system-wide locking), you can obtain pretty good lock performance.
>
> Let me know if you want me to code this up further, or if you have any
>other comments.
>
>take care,
>
>hab
>
>
>-----Original Message-----
>From: juddi-developers-admin@lists.sourceforge.net
>[mailto:juddi-developers-admin@lists.sourceforge.net]On Behalf Of
>Maarten Coene
>Sent: Wednesday, January 23, 2002 3:29 AM
>To: Bob Hablutzel; juddi-developers@lists.sourceforge.net
>Subject: RE: [jUDDI-developers] JavaUUIDGen
>
>
>sounds interesting, and it seems a good idea since you'll probably get 2
>equal UUIDs when you call the nextUUID() method at the same time twice on
>the same node (since the time and the ethernet address are the same)
>
>Maarten
>
>At 20:15 22/01/2002 -0500, you wrote:
> >Maarten - I was just starting to look at putting in place a global
locking
> >mechanism to ensure that you never got duplicate UUIDs on a node. If you
> >want to talk about the idea I had, it would be pretty quick to
implement -
> >drop me a note.
> >
> >hab
>
>--
>Maarten Coene
>Katholieke Universiteit Leuven
>Dept. Computerwetenschappen Tel: ++32 (0)16/32 78 25
>Celestijnenlaan 200A
>B-3001 Heverlee
>
>
>
>_______________________________________________
>juddi-developers mailing list
>juddi-developers@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/juddi-developers
>
>
>_______________________________________________
>juddi-developers mailing list
>juddi-developers@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/juddi-developers
--
Maarten Coene
Katholieke Universiteit Leuven
Dept. Computerwetenschappen Tel: ++32 (0)16/32 78 25
Celestijnenlaan 200A
B-3001 Heverlee
RE: [jUDDI-developers] JavaUUIDGen
Posted by Maarten Coene <Ma...@ToughGuy.net>.
Hi,
looks interesting, but it seems like a sort of hack to me. I was wondering:
is there a difference between making the JavaUUIDGen class a Singleton
together with a synchronized nextUUID() method and your proposal?
Maarten
At 08:44 23/01/2002 -0500, Bob Hablutzel wrote:
>Maarten -
>
> The basic idea was to use a system resource that imposes locking
>semantics, since Java doesn't provide direct access to low-level system-wide
>locking constructs. So, for example, a TCP/IP port can only be bound by one
>thread of execution at once; a file can atomically be created if it didn't
>exist, and so forth.
> The implementation I was working on used server sockets as the locking
>mechanism. It looks something like this:
>
> obtain lock: ServerSocket lock = new ServerSocket( 8090 );
> release lock: lock.close(); lock = null;
>
> So far, it's worked on both NT and Linux; I can test it under Solaris in
>a day or so. Interestingly, the latency isn't bad at all. I was worried
>about the reopen time-out of TCP ports, but that seems to only apply only if
>you actually accept connections. Since the lock only requires a bind (which
>is system-wide locking), you can obtain pretty good lock performance.
>
> Let me know if you want me to code this up further, or if you have any
>other comments.
>
>take care,
>
>hab
>
>
>-----Original Message-----
>From: juddi-developers-admin@lists.sourceforge.net
>[mailto:juddi-developers-admin@lists.sourceforge.net]On Behalf Of
>Maarten Coene
>Sent: Wednesday, January 23, 2002 3:29 AM
>To: Bob Hablutzel; juddi-developers@lists.sourceforge.net
>Subject: RE: [jUDDI-developers] JavaUUIDGen
>
>
>sounds interesting, and it seems a good idea since you'll probably get 2
>equal UUIDs when you call the nextUUID() method at the same time twice on
>the same node (since the time and the ethernet address are the same)
>
>Maarten
>
>At 20:15 22/01/2002 -0500, you wrote:
> >Maarten - I was just starting to look at putting in place a global locking
> >mechanism to ensure that you never got duplicate UUIDs on a node. If you
> >want to talk about the idea I had, it would be pretty quick to implement -
> >drop me a note.
> >
> >hab
>
>--
>Maarten Coene
>Katholieke Universiteit Leuven
>Dept. Computerwetenschappen Tel: ++32 (0)16/32 78 25
>Celestijnenlaan 200A
>B-3001 Heverlee
>
>
>
>_______________________________________________
>juddi-developers mailing list
>juddi-developers@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/juddi-developers
>
>
>_______________________________________________
>juddi-developers mailing list
>juddi-developers@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/juddi-developers
--
Maarten Coene
Katholieke Universiteit Leuven
Dept. Computerwetenschappen Tel: ++32 (0)16/32 78 25
Celestijnenlaan 200A
B-3001 Heverlee
RE: [jUDDI-developers] JavaUUIDGen
Posted by Bob Hablutzel <bo...@hablutzel.com>.
I'd envision something pluggable, so there could be NULL implementation that
did, well, nothing.
hab
-----Original Message-----
From: juddi-developers-admin@lists.sourceforge.net
[mailto:juddi-developers-admin@lists.sourceforge.net]On Behalf Of Alex
Ceponkus
Sent: Wednesday, January 23, 2002 11:39 AM
To: Bob Hablutzel; Maarten Coene; juddi-developers@lists.sourceforge.net
Subject: RE: [jUDDI-developers] JavaUUIDGen
> Let's see: first off, picking a different port each time would break the
> lock - you would have no way of knowing which lock a particular thread of
> execution was picking. So that won't help.
Yeah, noticed that just as I hit the 'send' button. Forget spell check,
Outlock needs an algorithm check.
> BTW, I think this global lock is worth it even if we don't anticipate
> multiple production 0.6 servers. There might be a test and a production,
> etc. HOWEVER, that's because I'm a paranoid pain in the ass; I don't mind
> being ignored in this case.
My vote is also to implement a global lock even if we find that the port
method doesn't work for whatever reason. However, we might want to consider
letting administrators disable the global locking from the property file.
_______________________________________________
juddi-developers mailing list
juddi-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/juddi-developers
RE: [jUDDI-developers] JavaUUIDGen
Posted by Alex Ceponkus <al...@ceponkus.org>.
> Let's see: first off, picking a different port each time would break the
> lock - you would have no way of knowing which lock a particular thread of
> execution was picking. So that won't help.
Yeah, noticed that just as I hit the 'send' button. Forget spell check,
Outlock needs an algorithm check.
> BTW, I think this global lock is worth it even if we don't anticipate
> multiple production 0.6 servers. There might be a test and a production,
> etc. HOWEVER, that's because I'm a paranoid pain in the ass; I don't mind
> being ignored in this case.
My vote is also to implement a global lock even if we find that the port
method doesn't work for whatever reason. However, we might want to consider
letting administrators disable the global locking from the property file.
RE: [jUDDI-developers] JavaUUIDGen
Posted by Bob Hablutzel <bo...@hablutzel.com>.
Let's see: first off, picking a different port each time would break the
lock - you would have no way of knowing which lock a particular thread of
execution was picking. So that won't help.
However, I think the timout you ran into only comes into place if you
actually accept a connection on a port. (It's typically twice the packet
lifetime, and designed to prevent a security hole where a remote session
previously connected to a port owned by app A mistakenly sends back a packet
to app B when B takes over a port). So far NT and Linux are doing it
"right"; I'll check Solaris later in the week.
BTW, I think this global lock is worth it even if we don't anticipate
multiple production 0.6 servers. There might be a test and a production,
etc. HOWEVER, that's because I'm a paranoid pain in the ass; I don't mind
being ignored in this case.
hab
-----Original Message-----
From: Alex Ceponkus [mailto:alex@ceponkus.org]
Sent: Wednesday, January 23, 2002 11:15 AM
To: Bob Hablutzel; Maarten Coene; juddi-developers@lists.sourceforge.net
Subject: RE: [jUDDI-developers] JavaUUIDGen
This scheme will wreak havoc with my ZoneAlarm. :)
I am interested in hearing about how it performs on Solaris. Several years
ago I used to do sockets programming on top of Solaris and it took a
ridiculous amount of time (several minutes) to make a port available again.
Although we could easily get around that by just incrementing the port
number each time. My guess is that I was just working on an old version of
Solaris and it's probably fixed by now.
-----Original Message-----
From: juddi-developers-admin@lists.sourceforge.net
[mailto:juddi-developers-admin@lists.sourceforge.net]On Behalf Of Bob
Hablutzel
Sent: Wednesday, January 23, 2002 8:44 AM
To: Maarten Coene; juddi-developers@lists.sourceforge.net
Subject: RE: [jUDDI-developers] JavaUUIDGen
Maarten -
The basic idea was to use a system resource that imposes locking
semantics, since Java doesn't provide direct access to low-level system-wide
locking constructs. So, for example, a TCP/IP port can only be bound by one
thread of execution at once; a file can atomically be created if it didn't
exist, and so forth.
The implementation I was working on used server sockets as the locking
mechanism. It looks something like this:
obtain lock: ServerSocket lock = new ServerSocket( 8090 );
release lock: lock.close(); lock = null;
So far, it's worked on both NT and Linux; I can test it under Solaris in
a day or so. Interestingly, the latency isn't bad at all. I was worried
about the reopen time-out of TCP ports, but that seems to only apply only if
you actually accept connections. Since the lock only requires a bind (which
is system-wide locking), you can obtain pretty good lock performance.
Let me know if you want me to code this up further, or if you have any
other comments.
take care,
hab
-----Original Message-----
From: juddi-developers-admin@lists.sourceforge.net
[mailto:juddi-developers-admin@lists.sourceforge.net]On Behalf Of
Maarten Coene
Sent: Wednesday, January 23, 2002 3:29 AM
To: Bob Hablutzel; juddi-developers@lists.sourceforge.net
Subject: RE: [jUDDI-developers] JavaUUIDGen
sounds interesting, and it seems a good idea since you'll probably get 2
equal UUIDs when you call the nextUUID() method at the same time twice on
the same node (since the time and the ethernet address are the same)
Maarten
At 20:15 22/01/2002 -0500, you wrote:
>Maarten - I was just starting to look at putting in place a global locking
>mechanism to ensure that you never got duplicate UUIDs on a node. If you
>want to talk about the idea I had, it would be pretty quick to implement -
>drop me a note.
>
>hab
--
Maarten Coene
Katholieke Universiteit Leuven
Dept. Computerwetenschappen Tel: ++32 (0)16/32 78 25
Celestijnenlaan 200A
B-3001 Heverlee
_______________________________________________
juddi-developers mailing list
juddi-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/juddi-developers
_______________________________________________
juddi-developers mailing list
juddi-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/juddi-developers
RE: [jUDDI-developers] JavaUUIDGen
Posted by Alex Ceponkus <al...@ceponkus.org>.
This scheme will wreak havoc with my ZoneAlarm. :)
I am interested in hearing about how it performs on Solaris. Several years
ago I used to do sockets programming on top of Solaris and it took a
ridiculous amount of time (several minutes) to make a port available again.
Although we could easily get around that by just incrementing the port
number each time. My guess is that I was just working on an old version of
Solaris and it's probably fixed by now.
-----Original Message-----
From: juddi-developers-admin@lists.sourceforge.net
[mailto:juddi-developers-admin@lists.sourceforge.net]On Behalf Of Bob
Hablutzel
Sent: Wednesday, January 23, 2002 8:44 AM
To: Maarten Coene; juddi-developers@lists.sourceforge.net
Subject: RE: [jUDDI-developers] JavaUUIDGen
Maarten -
The basic idea was to use a system resource that imposes locking
semantics, since Java doesn't provide direct access to low-level system-wide
locking constructs. So, for example, a TCP/IP port can only be bound by one
thread of execution at once; a file can atomically be created if it didn't
exist, and so forth.
The implementation I was working on used server sockets as the locking
mechanism. It looks something like this:
obtain lock: ServerSocket lock = new ServerSocket( 8090 );
release lock: lock.close(); lock = null;
So far, it's worked on both NT and Linux; I can test it under Solaris in
a day or so. Interestingly, the latency isn't bad at all. I was worried
about the reopen time-out of TCP ports, but that seems to only apply only if
you actually accept connections. Since the lock only requires a bind (which
is system-wide locking), you can obtain pretty good lock performance.
Let me know if you want me to code this up further, or if you have any
other comments.
take care,
hab
-----Original Message-----
From: juddi-developers-admin@lists.sourceforge.net
[mailto:juddi-developers-admin@lists.sourceforge.net]On Behalf Of
Maarten Coene
Sent: Wednesday, January 23, 2002 3:29 AM
To: Bob Hablutzel; juddi-developers@lists.sourceforge.net
Subject: RE: [jUDDI-developers] JavaUUIDGen
sounds interesting, and it seems a good idea since you'll probably get 2
equal UUIDs when you call the nextUUID() method at the same time twice on
the same node (since the time and the ethernet address are the same)
Maarten
At 20:15 22/01/2002 -0500, you wrote:
>Maarten - I was just starting to look at putting in place a global locking
>mechanism to ensure that you never got duplicate UUIDs on a node. If you
>want to talk about the idea I had, it would be pretty quick to implement -
>drop me a note.
>
>hab
--
Maarten Coene
Katholieke Universiteit Leuven
Dept. Computerwetenschappen Tel: ++32 (0)16/32 78 25
Celestijnenlaan 200A
B-3001 Heverlee
_______________________________________________
juddi-developers mailing list
juddi-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/juddi-developers
_______________________________________________
juddi-developers mailing list
juddi-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/juddi-developers
RE: [jUDDI-developers] JavaUUIDGen
Posted by Bob Hablutzel <bo...@hablutzel.com>.
Maarten -
The basic idea was to use a system resource that imposes locking
semantics, since Java doesn't provide direct access to low-level system-wide
locking constructs. So, for example, a TCP/IP port can only be bound by one
thread of execution at once; a file can atomically be created if it didn't
exist, and so forth.
The implementation I was working on used server sockets as the locking
mechanism. It looks something like this:
obtain lock: ServerSocket lock = new ServerSocket( 8090 );
release lock: lock.close(); lock = null;
So far, it's worked on both NT and Linux; I can test it under Solaris in
a day or so. Interestingly, the latency isn't bad at all. I was worried
about the reopen time-out of TCP ports, but that seems to only apply only if
you actually accept connections. Since the lock only requires a bind (which
is system-wide locking), you can obtain pretty good lock performance.
Let me know if you want me to code this up further, or if you have any
other comments.
take care,
hab
-----Original Message-----
From: juddi-developers-admin@lists.sourceforge.net
[mailto:juddi-developers-admin@lists.sourceforge.net]On Behalf Of
Maarten Coene
Sent: Wednesday, January 23, 2002 3:29 AM
To: Bob Hablutzel; juddi-developers@lists.sourceforge.net
Subject: RE: [jUDDI-developers] JavaUUIDGen
sounds interesting, and it seems a good idea since you'll probably get 2
equal UUIDs when you call the nextUUID() method at the same time twice on
the same node (since the time and the ethernet address are the same)
Maarten
At 20:15 22/01/2002 -0500, you wrote:
>Maarten - I was just starting to look at putting in place a global locking
>mechanism to ensure that you never got duplicate UUIDs on a node. If you
>want to talk about the idea I had, it would be pretty quick to implement -
>drop me a note.
>
>hab
--
Maarten Coene
Katholieke Universiteit Leuven
Dept. Computerwetenschappen Tel: ++32 (0)16/32 78 25
Celestijnenlaan 200A
B-3001 Heverlee
_______________________________________________
juddi-developers mailing list
juddi-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/juddi-developers
RE: [jUDDI-developers] JavaUUIDGen
Posted by Steve Viens <sv...@steveviens.com>.
I'd say two 'production' jUDDI servers on one machine is doubtful (can't
see any benefit).
Steve
-----Original Message-----
From: Bob Hablutzel [mailto:bob@hablutzel.com]
Sent: Wednesday, January 23, 2002 10:39 AM
To: Steve Viens; juddi-developers@lists.sourceforge.net
Subject: RE: [jUDDI-developers] JavaUUIDGen
Seems right. I'm willing to let Maarten take the lead on this, since
he's already in the code. I was really only concerned about the
system-wide locking, which may be too paranoid based on expect usage of
the product. (Do we ever expect there to be two jUDDI servers running on
the same machine at the same time?)
hab
-----Original Message-----
From: juddi-developers-admin@lists.sourceforge.net
[mailto:juddi-developers-admin@lists.sourceforge.net]On Behalf Of Steve
Viens
Sent: Wednesday, January 23, 2002 10:23 AM
To: juddi-developers@lists.sourceforge.net
Subject: RE: [jUDDI-developers] JavaUUIDGen
Hab and Maarten.
Whatever solution(s) you come up with please add the code to the 'core'
juddi source tree (as opposed to developing it as a separate juddi
'module').
The strategy is that jUDDI will try to create a UUIDGen from properties
specified in the juddi.properties file. If there is a problem then
warning messages will be written to the log and jUDDI will default to
use the SimpleUUIDGen implementation. This way jUDDI will always start
up. ... no head scratching during or after installation.
So...
If you come up with a solution that does not require ANY configuration
at all or any other libraries or external resources (i.e. completely
stands alone). Then please replace the org.juddi.uuidgen.SimpleUUIDGen
class with your code.
However ... If there is *any* configuration at all or required java lib
(or system utility that doesn't exist on all platforms) then please
create a new package called:
org.juddi.uuidgen.<whatever>
...and add your code there. AND replace the code in 'SimpleUUIDGen' with
that from the SecureRandomUUIDGen (since this can stand alone - sure
it's slow but it always works on any OS and without configuration or
external requirements).
Does this sound reasonable to you guys?
Steve
-----Original Message-----
From: juddi-developers-admin@lists.sourceforge.net
[mailto:juddi-developers-admin@lists.sourceforge.net] On Behalf Of
Maarten Coene
Sent: Wednesday, January 23, 2002 3:29 AM
To: Bob Hablutzel; juddi-developers@lists.sourceforge.net
Subject: RE: [jUDDI-developers] JavaUUIDGen
sounds interesting, and it seems a good idea since you'll probably get 2
equal UUIDs when you call the nextUUID() method at the same time twice
on the same node (since the time and the ethernet address are the same)
Maarten
At 20:15 22/01/2002 -0500, you wrote:
>Maarten - I was just starting to look at putting in place a global
>locking mechanism to ensure that you never got duplicate UUIDs on a
>node. If you want to talk about the idea I had, it would be pretty
>quick to implement - drop me a note.
>
>hab
--
Maarten Coene
Katholieke Universiteit Leuven
Dept. Computerwetenschappen Tel: ++32 (0)16/32 78 25
Celestijnenlaan 200A
B-3001 Heverlee
_______________________________________________
juddi-developers mailing list juddi-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/juddi-developers
_______________________________________________
juddi-developers mailing list juddi-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/juddi-developers
RE: [jUDDI-developers] JavaUUIDGen
Posted by Bob Hablutzel <bo...@hablutzel.com>.
Seems right. I'm willing to let Maarten take the lead on this, since he's
already in the code. I was really only concerned about the system-wide
locking, which may be too paranoid based on expect usage of the product. (Do
we ever expect there to be two jUDDI servers running on the same machine at
the same time?)
hab
-----Original Message-----
From: juddi-developers-admin@lists.sourceforge.net
[mailto:juddi-developers-admin@lists.sourceforge.net]On Behalf Of Steve
Viens
Sent: Wednesday, January 23, 2002 10:23 AM
To: juddi-developers@lists.sourceforge.net
Subject: RE: [jUDDI-developers] JavaUUIDGen
Hab and Maarten.
Whatever solution(s) you come up with please add the code to the 'core'
juddi source tree (as opposed to developing it as a separate juddi
'module').
The strategy is that jUDDI will try to create a UUIDGen from properties
specified in the juddi.properties file. If there is a problem then
warning messages will be written to the log and jUDDI will default to
use the SimpleUUIDGen implementation. This way jUDDI will always start
up. ... no head scratching during or after installation.
So...
If you come up with a solution that does not require ANY configuration
at all or any other libraries or external resources (i.e. completely
stands alone). Then please replace the org.juddi.uuidgen.SimpleUUIDGen
class with your code.
However ... If there is *any* configuration at all or required java lib
(or system utility that doesn't exist on all platforms) then please
create a new package called:
org.juddi.uuidgen.<whatever>
...and add your code there. AND replace the code in 'SimpleUUIDGen' with
that from the SecureRandomUUIDGen (since this can stand alone - sure
it's slow but it always works on any OS and without configuration or
external requirements).
Does this sound reasonable to you guys?
Steve
-----Original Message-----
From: juddi-developers-admin@lists.sourceforge.net
[mailto:juddi-developers-admin@lists.sourceforge.net] On Behalf Of
Maarten Coene
Sent: Wednesday, January 23, 2002 3:29 AM
To: Bob Hablutzel; juddi-developers@lists.sourceforge.net
Subject: RE: [jUDDI-developers] JavaUUIDGen
sounds interesting, and it seems a good idea since you'll probably get 2
equal UUIDs when you call the nextUUID() method at the same time twice
on
the same node (since the time and the ethernet address are the same)
Maarten
At 20:15 22/01/2002 -0500, you wrote:
>Maarten - I was just starting to look at putting in place a global
>locking mechanism to ensure that you never got duplicate UUIDs on a
>node. If you want to talk about the idea I had, it would be pretty
>quick to implement - drop me a note.
>
>hab
--
Maarten Coene
Katholieke Universiteit Leuven
Dept. Computerwetenschappen Tel: ++32 (0)16/32 78 25
Celestijnenlaan 200A
B-3001 Heverlee
_______________________________________________
juddi-developers mailing list juddi-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/juddi-developers
_______________________________________________
juddi-developers mailing list
juddi-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/juddi-developers
RE: [jUDDI-developers] JavaUUIDGen
Posted by Steve Viens <sv...@steveviens.com>.
Hab and Maarten.
Whatever solution(s) you come up with please add the code to the 'core'
juddi source tree (as opposed to developing it as a separate juddi
'module').
The strategy is that jUDDI will try to create a UUIDGen from properties
specified in the juddi.properties file. If there is a problem then
warning messages will be written to the log and jUDDI will default to
use the SimpleUUIDGen implementation. This way jUDDI will always start
up. ... no head scratching during or after installation.
So...
If you come up with a solution that does not require ANY configuration
at all or any other libraries or external resources (i.e. completely
stands alone). Then please replace the org.juddi.uuidgen.SimpleUUIDGen
class with your code.
However ... If there is *any* configuration at all or required java lib
(or system utility that doesn't exist on all platforms) then please
create a new package called:
org.juddi.uuidgen.<whatever>
...and add your code there. AND replace the code in 'SimpleUUIDGen' with
that from the SecureRandomUUIDGen (since this can stand alone - sure
it's slow but it always works on any OS and without configuration or
external requirements).
Does this sound reasonable to you guys?
Steve
-----Original Message-----
From: juddi-developers-admin@lists.sourceforge.net
[mailto:juddi-developers-admin@lists.sourceforge.net] On Behalf Of
Maarten Coene
Sent: Wednesday, January 23, 2002 3:29 AM
To: Bob Hablutzel; juddi-developers@lists.sourceforge.net
Subject: RE: [jUDDI-developers] JavaUUIDGen
sounds interesting, and it seems a good idea since you'll probably get 2
equal UUIDs when you call the nextUUID() method at the same time twice
on
the same node (since the time and the ethernet address are the same)
Maarten
At 20:15 22/01/2002 -0500, you wrote:
>Maarten - I was just starting to look at putting in place a global
>locking mechanism to ensure that you never got duplicate UUIDs on a
>node. If you want to talk about the idea I had, it would be pretty
>quick to implement - drop me a note.
>
>hab
--
Maarten Coene
Katholieke Universiteit Leuven
Dept. Computerwetenschappen Tel: ++32 (0)16/32 78 25
Celestijnenlaan 200A
B-3001 Heverlee
_______________________________________________
juddi-developers mailing list juddi-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/juddi-developers
RE: [jUDDI-developers] JavaUUIDGen
Posted by Maarten Coene <Ma...@ToughGuy.net>.
sounds interesting, and it seems a good idea since you'll probably get 2
equal UUIDs when you call the nextUUID() method at the same time twice on
the same node (since the time and the ethernet address are the same)
Maarten
At 20:15 22/01/2002 -0500, you wrote:
>Maarten - I was just starting to look at putting in place a global locking
>mechanism to ensure that you never got duplicate UUIDs on a node. If you
>want to talk about the idea I had, it would be pretty quick to implement -
>drop me a note.
>
>hab
--
Maarten Coene
Katholieke Universiteit Leuven
Dept. Computerwetenschappen Tel: ++32 (0)16/32 78 25
Celestijnenlaan 200A
B-3001 Heverlee
RE: [jUDDI-developers] JavaUUIDGen
Posted by Steve Viens <sv...@steveviens.com>.
First - our UUID Generation mission statement (lol)
***** Develop a UUID generator that's FAST, TRUE (as in 'generates true
UUID's'), works on ANY OS, and requires the LEAST amount of EFFORT to
configure (preferably NONE). *****
In this case I like the idea of using an empty property in the
juddi.properties file. Then check to see what comes back - if we pick up
a 'null' value then either "blow up" an log a few messages on EXACTLY
what the problem is and EXACTLY how to fix it ... or - still log the
messages but don't blow up and simply use the SecureRandom version.
Hab had another thought on UUID generation (which sounded interesting -
but I couldn't explain it to you). Maarten and Hab can work that idea
and see what they come up with.
Steve
-----Original Message-----
From: juddi-developers-admin@lists.sourceforge.net
[mailto:juddi-developers-admin@lists.sourceforge.net] On Behalf Of Alex
Ceponkus
Sent: Tuesday, January 22, 2002 8:24 PM
To: Maarten Coene; juddi-developers@lists.sourceforge.net
Subject: RE: [jUDDI-developers] JavaUUIDGen
Thanks for doing this work Maarten. Just brainstorming and curious what
others think ... would it make sense to: by default have 0 (or something
else invalid) as the ethernet address in the properties file which will
force juddi to use the secure random version of the java uuid generator.
Then if they put in a real ethernet address, we automagically switch to
Maarten's updated UUID generator. Just worried that most people will
just leave the defaults as is. Thoughts?
Alex
> -----Original Message-----
> From: juddi-developers-admin@lists.sourceforge.net
> [mailto:juddi-developers-admin@lists.sourceforge.net]On Behalf Of
> Maarten Coene
> Sent: Tuesday, January 22, 2002 7:04 PM
> To: juddi-developers@lists.sourceforge.net
> Cc: MacBelgium@toughguy.net
> Subject: [jUDDI-developers] JavaUUIDGen
>
>
> Hi,
>
> I've changed the pure Java UUID Generator
> (org.juddi.uuidgen.JavaUUIDGen) to
> use real IEEE 802 ethernet addresses instead of a SecureRandom which
> slowed down the generation process a lot. The counterpart of this
> approach is that
> Java doesn't provide a way to retrieve this address. This means that a
> person who want to use this Java UUID Generator must specify his
ethernet
> address in the juddi.properties configuration file. I've included an
empty
> property for this in the juddi.properties file and also put an
> example of an
> ethernet address in there. The old Java UUIDGenerator is also still
there
> and is called org.juddi.uuidgen.SecureRandomUUIDGen.
>
> There also have to be explained to the user how to retrieve this
> ethernet address for different platforms. I don't know where this
> should be placed (perhaps in an INSTALL file or something similar ->
> who will do this????). Here is a possible way to retrieve this address
> in Windows 2000/XP (and probably older version too):
>
> 1. Go to the console window (DOS prompt in older versions)
> 2. At the prompt, type: "ipconfig /all" (without the quotes ;-))
> You'll receive something like this:
>
> Windows IP Configuration
>
> Host Name . . . . . . . . . . . . : atlantis
> Primary Dns Suffix . . . . . . . :
> Node Type . . . . . . . . . . . . : Unknown
> IP Routing Enabled. . . . . . . . : No
> WINS Proxy Enabled. . . . . . . . : No
>
> Ethernet adapter Local Area Connection:
>
> Connection-specific DNS Suffix . : kotnet.org
> Description . . . . . . . . . . . : D-Link DE-528 Ethernet PCI
> Adapter
> Physical Address. . . . . . . . . : 00-50-BA-AC-AA-55
> Dhcp Enabled. . . . . . . . . . . : Yes
> Autoconfiguration Enabled . . . . : Yes
> IP Address. . . . . . . . . . . . : 10.67.29.254
>
> 3. Enter the value found at the "Physical Address" property in the
> juddi.properties configuration file.
>
> I don't know how to retrieve this address using other platforms, but
> I'll guess someone of you knows...
>
> Note that at the moment the ethernet address must be entered in this
> hexadecimal form.
>
> Maarten
>
>
>
> _______________________________________________
> juddi-developers mailing list juddi-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/juddi-developers
>
>
_______________________________________________
juddi-developers mailing list
juddi-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/juddi-developers
RE: [jUDDI-developers] JavaUUIDGen
Posted by Alex Ceponkus <al...@ceponkus.org>.
Thanks for doing this work Maarten. Just brainstorming and curious what
others think ... would it make sense to: by default have 0 (or something
else invalid) as the ethernet address in the properties file which will
force juddi to use the secure random version of the java uuid generator.
Then if they put in a real ethernet address, we automagically switch to
Maarten's updated UUID generator. Just worried that most people will just
leave the defaults as is. Thoughts?
Alex
> -----Original Message-----
> From: juddi-developers-admin@lists.sourceforge.net
> [mailto:juddi-developers-admin@lists.sourceforge.net]On Behalf Of
> Maarten Coene
> Sent: Tuesday, January 22, 2002 7:04 PM
> To: juddi-developers@lists.sourceforge.net
> Cc: MacBelgium@toughguy.net
> Subject: [jUDDI-developers] JavaUUIDGen
>
>
> Hi,
>
> I've changed the pure Java UUID Generator
> (org.juddi.uuidgen.JavaUUIDGen) to
> use real IEEE 802 ethernet addresses instead of a SecureRandom
> which slowed
> down the generation process a lot. The counterpart of this
> approach is that
> Java doesn't provide a way to retrieve this address. This means that a
> person who want to use this Java UUID Generator must specify his ethernet
> address in the juddi.properties configuration file. I've included an empty
> property for this in the juddi.properties file and also put an
> example of an
> ethernet address in there. The old Java UUIDGenerator is also still there
> and is called org.juddi.uuidgen.SecureRandomUUIDGen.
>
> There also have to be explained to the user how to retrieve this ethernet
> address for different platforms. I don't know where this should be placed
> (perhaps in an INSTALL file or something similar -> who will do this????).
> Here is a possible way to retrieve this address in Windows 2000/XP (and
> probably older version too):
>
> 1. Go to the console window (DOS prompt in older versions)
> 2. At the prompt, type: "ipconfig /all" (without the quotes ;-))
> You'll receive something like this:
>
> Windows IP Configuration
>
> Host Name . . . . . . . . . . . . : atlantis
> Primary Dns Suffix . . . . . . . :
> Node Type . . . . . . . . . . . . : Unknown
> IP Routing Enabled. . . . . . . . : No
> WINS Proxy Enabled. . . . . . . . : No
>
> Ethernet adapter Local Area Connection:
>
> Connection-specific DNS Suffix . : kotnet.org
> Description . . . . . . . . . . . : D-Link DE-528 Ethernet PCI
> Adapter
> Physical Address. . . . . . . . . : 00-50-BA-AC-AA-55
> Dhcp Enabled. . . . . . . . . . . : Yes
> Autoconfiguration Enabled . . . . : Yes
> IP Address. . . . . . . . . . . . : 10.67.29.254
>
> 3. Enter the value found at the "Physical Address" property in the
> juddi.properties configuration file.
>
> I don't know how to retrieve this address using other platforms, but I'll
> guess someone of you knows...
>
> Note that at the moment the ethernet address must be entered in this
> hexadecimal form.
>
> Maarten
>
>
>
> _______________________________________________
> juddi-developers mailing list
> juddi-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/juddi-developers
>
>
RE: [jUDDI-developers] JavaUUIDGen
Posted by Bob Hablutzel <bo...@hablutzel.com>.
Linux:
$ /sbin/ifconfig | grep HWaddr
eth0 Link encap:Ethernet HWaddr 00:90:27:37:A6:B4
HWaddr is the address in question. You might need to be root to do this.
(If you want to get fancy:
$ /sbin/ifconfig | perl -ne 'print "Ethernet address: $1\n" if (/HWaddr
(.*$)/);'
Ethernet address: 00:90:27:37:A6:B4
I think Solaris is similar - I'll be back at a Solaris machine on Thursday
and get the right info
Maarten - I was just starting to look at putting in place a global locking
mechanism to ensure that you never got duplicate UUIDs on a node. If you
want to talk about the idea I had, it would be pretty quick to implement -
drop me a note.
hab
-----Original Message-----
From: juddi-developers-admin@lists.sourceforge.net
[mailto:juddi-developers-admin@lists.sourceforge.net]On Behalf Of
Maarten Coene
Sent: Tuesday, January 22, 2002 7:04 PM
To: juddi-developers@lists.sourceforge.net
Cc: MacBelgium@toughguy.net
Subject: [jUDDI-developers] JavaUUIDGen
Hi,
I've changed the pure Java UUID Generator (org.juddi.uuidgen.JavaUUIDGen) to
use real IEEE 802 ethernet addresses instead of a SecureRandom which slowed
down the generation process a lot. The counterpart of this approach is that
Java doesn't provide a way to retrieve this address. This means that a
person who want to use this Java UUID Generator must specify his ethernet
address in the juddi.properties configuration file. I've included an empty
property for this in the juddi.properties file and also put an example of an
ethernet address in there. The old Java UUIDGenerator is also still there
and is called org.juddi.uuidgen.SecureRandomUUIDGen.
There also have to be explained to the user how to retrieve this ethernet
address for different platforms. I don't know where this should be placed
(perhaps in an INSTALL file or something similar -> who will do this????).
Here is a possible way to retrieve this address in Windows 2000/XP (and
probably older version too):
1. Go to the console window (DOS prompt in older versions)
2. At the prompt, type: "ipconfig /all" (without the quotes ;-))
You'll receive something like this:
Windows IP Configuration
Host Name . . . . . . . . . . . . : atlantis
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Unknown
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : kotnet.org
Description . . . . . . . . . . . : D-Link DE-528 Ethernet PCI
Adapter
Physical Address. . . . . . . . . : 00-50-BA-AC-AA-55
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 10.67.29.254
3. Enter the value found at the "Physical Address" property in the
juddi.properties configuration file.
I don't know how to retrieve this address using other platforms, but I'll
guess someone of you knows...
Note that at the moment the ethernet address must be entered in this
hexadecimal form.
Maarten
_______________________________________________
juddi-developers mailing list
juddi-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/juddi-developers