Hi Oleg,
No I was setting HttpState object into HttpClient object. Now I see where I
went wrong. But the only API method which will allow me to do that is
executeMethod(HostConfiguration hostconfig, HttpMethod method, HttpState
state).
Till now I was using executeMethod(HttpMethod method).Now that means I will
have to create a HostConfiguration object which should be singleton. Am I
right?
Thanks once again for your help.
Regards,
Gagneet
----- Original Message -----
From: "Oleg Kalnichevski" <[EMAIL PROTECTED]>
To: "HttpClient User Discussion" <[email protected]>
Sent: Thursday, April 03, 2008 12:14 AM
Subject: Re: Problem sending request using HttpClient when the server
receiving request goes down and is started again.
gagneet wrote:
Hi Oleg,
Thanks for your inputs. Now I am making a new HttpState object for
each request made. But have found a new problem. This problem occurs when
the requests are concurrent. What is evident is that after redirection
happens the JSESSIONID of both the requests become same. Could not figure
out what makes the JSESSIONID for one request to be overwritten by
JSESSIONID of second request. I am using singleton HttpClient object
which is created using MultiThreadedHttpConnectionManager.
You are passing HttpState as a parameter to the HttpClient#executeMethod,
aren't you?
Oleg
What can be the possible reason for this? What can be the way(s) to
avoid this? Regards,
Gagneet
Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
On Thu, 2008-03-27 at 11:53 +0000, gagneet wrote:
Hi Oleg,
As I was using Singleton HttpClient object the JSESSIONID persisted for
every request. I have cleared the persistence by calling clearCookies()
method on the HttpState object corresponding to the HttpClient object.
Should I call this method after every call or should I call it only if
the connection is timed out? Please advice.
Regards,
Gagneet
Gagneet,
It really depends on how your application manages conversation state on
the client side. Usually applications are expected to maintains an
instance of HttpState per distinct user / thread of execution. This way,
you would not have to mix cookies that belong to different users, and if
an individual connection times out, the HttpState instance associated
with it could simply be discarded along with the JSESSIONID session
cookie. Hope this helps
Oleg
---------------------------------
Why delete messages? Unlimited storage is just a click away.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------
Why delete messages? Unlimited storage is just a click away.
---------------------------------------------------------------------
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]
