I don't think we can do very much to really test this. We need to look good and hard at the algorithm :-) There is currently only one potential situation where generated IDs might clash: when they are generated on the same machine (as identified by the IP-address) but on different JVMs at the same time (System.currentTimeMillis() yields the same value). This is pretty unlikely, and I think that by putting the identity hash code of the test case instance into the mix, the resulting IDs should never clash. As I noted a week or so ago, RMI uses
new Object().hashCode()
to get a host/JVM unique ID. If that works, our algorithm should be pretty damn safe :-)
Of course that's just theory, and I have no good idea how to test this... there are just so many factors (JVM memory model, OS scheduling latency, ...).
On a related note, we are now pretty much in a feature freeze until we branch out a CACTUS_15_BRANCH for maintenance. That will be done as soon as we release a beta of 1.5. Until then, we should not add the Test-ID functionality to CVS. We'll keep the already present UniqueGenerator, but I'd like to remove the code that adds it to the request etc. We can add it back later, but it'll probably look completely different anyway if we implement it as a cookie generated on the server side.
Nicholas Lesiecki wrote:
Hi all,
Does anyone have any ideas about how to integration test the unique id functionality? Essentially it will be known to work when two test results are never confused in a multi-threaded/multi-JVM environment. This happened to me all the time when running FilterTestCases at eBlox. I am, however, not sure why, or under what exact circumstances the behavior could be reproduced. Does anyone have any suggestions as to what I should write?
Cheers, nick
-- Christopher Lenz /=/ cmlenz at gmx.de
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
