jakarta-cactus-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Lenz <cml...@gmx.de>
Subject Re: Moving UniqueId to the server side
Date Wed, 09 Jul 2003 09:11:42 GMT
Lesiecki Nicholas wrote:
> 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.

Yes, we're a couple of days away from a beta and the branch now. If you 
don't have time to remove the unique ID references, I can probably do it 
today or tomorrow.

> 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. 

Sounds good :-)

> Of course, there may be problems with synching on the application context.

I have no idea about that...

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

View raw message