On Thu, Sep 16, 2010 at 12:51 AM, Amila Suriarachchi <[email protected]> wrote: > >> >> > If some one wants this behavior it can be easily done even with the >> > earlier >> > code by setting appropriate parameters. >> >> I can argue the same with these changes. You can also set appropriate >> parameter to pass your own HttpConnectionManager with custom settings >> (e.g. pass SimpleHttpConnectionManager to effectively disable >> connection reuse or pass MultiThreadedHttpConnectionManager with >> higher maxConnectionsPerHost setting, etc.). > > yes. But the idea of this commit is to fix the problem out of the box. Which > is still not the case.
The key idea of these changes were to ensure that connection reuse is done properly (in thread safe way). The idea of connection reuse by default was a secondary thought. Connection reuse by default was enabled in the 1.5 branch (before any of my changes) but for whatever reason wasn't merged into trunk. So I just made sure the 1.5 branch and trunk work/behave the same. >> >> I think the real question you are raising is if connection reuse >> should be done by default. I thought the answer to that question was >> yes. > > yes if we do this change at the early stages of Axis2. But currently lot of > people use it without using cleanUpTransport method. Even this is the > problem with Rampart and Sandesha. After 1.5.1 release I saw lot of people > report this issue due to same problem. > > So this patch does not solve the problem out of the box for all cases. But > it break the code for some people. No change ever will.. Again, I thought we wanted connection reuse by default. And if that's what we want then people will have to adapt to the new behavior. Personally, I don't care if connection reuse is done by default or not. All I care about is that if/when connection reuse is enabled it is done in a thread safe way. If you want to put a big if statement around the block of code in question that is cool with me. Jarek --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
