jakarta-cactus-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Lesiecki <ndlesie...@yahoo.com>
Subject Re: Moving UniqueId to the server side
Date Mon, 28 Jul 2003 07:18:28 GMT
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" <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...


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