Shouldn't "recycle" be deprecated for the 2.1 release? Seems like we've discussed it before, and all it gives us is a chance for uses like the following, where my first reaction was that maybe the "recycle" call didn't work properly. I don't think it adds much for performance, and it makes the API more confusing, I think.
To Dan,
You might want to structure your call slightly differently, as well:
try {
client.executeMethod(method);
// do what you want here...
}
finally {
// guarantee that you always release the connection - critical if you switch
// to MultiThreadedHttpConnectionManager().
method.releaseConnection();
}
-Eric.
Dan Tran wrote:
Hi I am write a small client/server web app to understand more about httpclient/cookie/and httpsession.
On the httpclient side, I use a get method to keep calling a servlet on server.
<clientcode> HttpClient client = new HttpClient(); GetMethod method = new GetMethod(url); while ( !done ) { client.executeMethod(method); if (method.getStatusCode() == HttpStatus.SC_OK) { method.getResponseBody(); method.releaseConnection(); } else { System.out.println("Unexpected failure: " + method.getStatusLine().toString()); done = true; }
method.recycle(); method.setPath(url);
sleep(sometime)
} </clientcode>
on the server side, the doGet() method use this
<servercode> public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.getSession(); } </servercode>
The first loop, the client is happy. I found a cookie in the response.
After that it throws the following warning message in my lo4j
<warning-snippet> 06:22:37,843 - WARN org.apache.commons.httpclient.HttpMethodBase - Cookie reject ed: "$Version=0; JSESSIONID=6D150D24B3D022F9AB835EF4E0AFEC5E; $Path=/webtest". I llegal path attribute "/webtest". Path of origin: "http://localhost:8080/webtest /webgenservlet" </waring-snippet>
On server side, new session is created for each request
Questions are:
Why server keeps creating new session instead of reuse the old one? What does it mean regarding the Warning.
Advices are greately appreciated.
Happy Coding
-Dan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
