Mailing-List: contact cactus-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Cactus Developers List" <cactus-dev@jakarta.apache.org>
Message-ID: <20030709161305.2643.qmail@web13601.mail.yahoo.com>
Date: Wed, 9 Jul 2003 09:13:05 -0700 (PDT)
From: Lesiecki Nicholas <ndlesiecki@yahoo.com>
Reply-To: ndlesiecki@yahoo.com
Subject: Re: Moving UniqueId to the server side
To: Cactus Developers List <cactus-dev@jakarta.apache.org>
In-Reply-To: <3F0BDC4E.1000504@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

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

My home internet connection has been wonky of late. Therfore, I can make no
gaurantees as to when I'll have a chance. Feel free to rip it out, or I
will attempt it Saturday morning.

> 
> Sounds good :-)
> 
> > Of course, there may be problems with synching on the application
> context.
> 
> I have no idea about that...

I'll proceed with this plan then, unless I hear otherwise.

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


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