On Mon, 2008-07-21 at 09:19 +0200, Phillip Gussow wrote: > Hi peeps, > > I'm struggling with how to solve a nice problem. Let me sketch the situation: > > I have to call web services of a 3rd party. They have 'funny' web services, > because they first want a login SOAP request and then using the SAME > connection I have to send the actual SOAP request. > In a straight-forward scenario there is no problem. But I don't want to > expose the login-crap to my users AND I myself will be called as a web > service, so I have to service multiple requests at the same time. Also for > performance reasons I do not want to send the login request for every call > that is made to me. So I need to pool the connections and make sure that for > every connection the Login request was already sent. > > This means I need to use the MultiThreadedHttpConnectionManager. > BUT: There is a session timeout on the connection. So when the response is a > 'session-timeout', I need to sent the login request again. I need to hide > this for the people that are calling my service. > > My problem is that I can't hook into when the HttpClient decides to use a > specific connection. > > Anyone any idea on how to solve this problem? >
Phillip, The problem is that HttpClient 3.x treats all connections as stateless. There is nothing one can do about it. Support for stateful connections has been introduced in HttpClient 4.0 (still alpha). You might want to consider upgrading. Oleg > Thanks in advance! > > Phillip Gussow > > > > ________________________________ > The information contained in this communication is confidential, intended > solely for the use of the individual or entity to whom it is addressed and > may be legally privileged and protected by professional secrecy. Access to > this message by anyone else is unauthorized. If you are not the intended > recipient, any disclosure, copying, or distribution of the message, or any > action or omission taken by you in reliance on it is prohibited and may be > unlawful. Please immediately contact the sender if you have received this > message in error. This email does not constitute any commitment from Cordys > Holding BV or any of its subsidiaries except when expressly agreed in a > written agreement between the intended recipient and Cordys Holding BV or its > subsidiaries. Cordys is neither liable for the proper and complete > transmission of the information contained in this communication nor for any > delay in its receipt. Cordys does not guarantee that the integrity of this > communication has been maintained nor that the communication is free of > viruses, interceptions or interference. If you are not the intended recipient > of this communication please return the communication to the sender and > delete and destroy all copies. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
