> 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 <[EMAIL PROTECTED]> wrote:
> Lesiecki Nicholas wrote:
> > Hi,
> >
> > --- Christopher Lenz <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
