jakarta-cactus-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lesiecki Nicholas <ndlesie...@yahoo.com>
Subject Moving UniqueId to the server side
Date Mon, 07 Jul 2003 15:54:52 GMT
Hi,

--- Christopher Lenz <cmlenz@gmx.de> wrote:
> 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.


Ok, I can rip this all out if you like. It *will* look completely different
once we move to the server. Again, I'd love for us to branch soon so I can
continue the work.

Regarding testing the functionality:

> 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 :-)

I think all these problems will disappear once we hit the server. All I
think we'll have to do is synchronize on the application context:


synchronized(application){
  count++;
}

(where count is a static variable in some generator class.)

That way each incoming test is guaranteed to have a different id with
respect to that application context. Since the server distributes the IDs,
there would be no need to id the clients specifically. We could start count
at System.currentTimeMillis() just to be on the safe side. 

Of course, there may be problems with synching on the application context.
What do you guys think?

Cheers,
Nick
--- Christopher Lenz <cmlenz@gmx.de> wrote:
> Hi Nick,
> 
> 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: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org


Mime
View raw message