I implemented your general suggestions. I'm afraid I didn't understand very
well what you meant by limiting the size of the key to 32 bits. By odd
coincidence, my generated ids end up at approx. 32 characters. I don't think
we should be too concerned about the exact number of bytes pushed about. If
that was important enough to warrant serious concern, we should make our
directive names much shorter. 32 characters seems acceptably low to me.
Hope you like the generator, if not, no need to discuss--simply change it to
suit your preferred algorithm. I'm not picky.
Cheers,
nick
On 6/23/03 4:57 AM, "Christopher Lenz" <[EMAIL PROTECTED]> wrote:
> Lesiecki Nicholas wrote:
>>> Are we sure we need to add static text to the generated id? (I mean all
>>> the "testCase:", "_", etc?
>>
>> No, I'm not sure. I guess I just wanted it there to check if the IDs were
>> really unique, and if not, why...So I'll take it out...
>
> The string is also unnecessarily long, thus just increasing the number of
> bytes that need to be pushed around the system per test. A 32-character wide
> ID should be enough.
>
>>> How confident are we that this leads to a unique id? I'm not sure. What
>>> happens if you're sending several requests on the same machine? The
>>> thread name is often the same.
>>
>> Fair enough.
>
> I also think that the thread name doesn't provide any benefit. It would be
> different if we had access to a combination of thread and process ID (OS
> handle), but we don't.
>
>>> I don't know what the runtime hash is but
>>> I guess it will be same if you're inside the same JVM.
>>
>> Yes, I thought of that while vaccuming. It also does not uniquely ID a JVM
>> (my intent).
>
> java.rmi.server.UID has this simple method to get a host/JVM-unique number:
>
> /**
> * In the absence of an actual pid, just do something somewhat
> * random.
> */
> private static int getHostUniqueNum() {
> return (new Object()).hashCode();
> }
>
> Not sure why this would be guaranteed to return a unique number per JVM, but
> if RMI uses it... ;-)
>
>>> The client ip
>>> will be the same.
>>
>> Yep. And to be fair, the most frequently encountered scenario involves one
>> client machine--not several.
>>
>>> And the currentTimeMillis() will probably be the same
>>> for several requests generated at the same time.
>
> That's true, but more than one test per millisecond is pretty improbable
> (even if we launched multiple tests "simultaneouisly" in different threads).
> Add an 8-bit thread-safe static counter, and we're safe.
>
>> Hmmmm, ok, I see your point.
>>
>>> Am I wrong? :-)
>>
>> No. :(
>>
>>> Maybe adding a random number would do the trick? Or using an existing
>>> unique id algorithm? There are several that exists on the web. I think
>>> there's even one in the JDK in some RMI-related class (can't remember
>>> right now).
>>
>> I'll look for it when I get back to the code. Thanks for all the
>> suggestions!
>
> Some more suggestions:
>
> Instead of using the name of the test class and test method, how about just
> using the identityHashCode() of the test class instance plus the hashCode()
> of the Method object or method name. I *think* this should also uniquely
> identify the JVM we're running in, as the identity hash code of a test class
> instance should effectively never be the same across different virtual
> machines. Otherwise the RMI UID class would be pretty broken AFAICT.
>
> [I wish I hadn't thrown away my UID generation class that I had written for
> Cactus some weeks ago. It was producing sufficiently unique IDs packed into
> a 32-character wide hex array :-P ]
>
> -chris
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
