No worry. Take your time. This is open source. Everyone participates at his own rhythm! :-)
Have fun, -Vincent > -----Original Message----- > From: Lesiecki Nicholas [mailto:[EMAIL PROTECTED] > Sent: 07 August 2003 17:19 > To: Cactus Developers List > Subject: RE: Moving UniqueId to the server side > > Thanks Vincent! I hadn't thought of that. I don't know when I will get a > chance to work on this again. This weekend I'm visiting family, and next > weekend someone's visiting me... So I guess all my lobbying for being able > to release soon after 1.5 was a moot point. Sorry everyone :( But I'm not > going to give up or forget. > > Cheers, > Nick > > --- Vincent Massol <[EMAIL PROTECTED]> wrote: > > Hmm... Not sure where the problem is. What I can suggest is to verify > > the header is correctly set. You can do that by opening a telnet session > > to your server and typing the GET command. You will then be able to see > > the headers. > > > > Alternatively you can probably use wget to peform the same thing. > > > > -Vincent > > > > > -----Original Message----- > > > From: Nicholas Lesiecki [mailto:[EMAIL PROTECTED] > > > Sent: 28 July 2003 09:18 > > > To: Cactus Developers List > > > Subject: Re: Moving UniqueId to the server side > > > > > > Hello developers, > > > > > > I attempted to implement the move of the uniqueID to the server side. > > > Naively, I attempted to set the generated results id as a header in > > the > > > response to the initial CALL_TEST service. Here is my code: > > > > > > (from AbstractWebTestCaller.java) > > > > > > private void addResultsIdHeaderToResponse(String theResultsId) > > > { > > > HttpServletResponse response = > > > this.webImplicitObjects.getHttpServletResponse(); > > > response.addHeader(HttpServiceDefinition.TEST_ID_PARAM, > > > theResultsId); > > > > > > } > > > > > > Unfortunately, when I try to read this value on the client, it comes > > up as > > > null. It seems that the connection does not register any headers as > > being > > > set. > > > > > > (From DefaultHttpClient:) > > > > > > HttpURLConnection connection = callRunTest(theRequest); > > > String resultsId = getResultsIdFromHeader(connection); > > > > > > GetResultsFromHeader expands to: > > > > > > private String getResultsIdFromHeader(HttpURLConnection theConnection) > > > { > > > String resultsId = > > > theConnection.getHeaderField(HttpServiceDefinition.TEST_ID_PARAM); > > > if (resultsId == null) > > > { > > > throw new IllegalStateException();//I always get this > > > } > > > return resultsId; > > > } > > > > > > I haven't worked much with headers, is either of these two code > > fragments > > > fundamentally flawed? > > > > > > > > > Cheers, > > > Nick > > > On 7/9/03 2:11 AM, "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... > > > > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > --------------------------------------------------------------------- > 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]
