You are viewing a plain text version of this content. The canonical link for it is here.
Posted to savan-dev@ws.apache.org by Amila Suriarachchi <am...@gmail.com> on 2010/09/15 13:57:57 UTC
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
On Mon, Sep 6, 2010 at 1:08 AM, <ve...@apache.org> wrote:
> Author: veithen
> Date: Sun Sep 5 19:38:56 2010
> New Revision: 992877
>
> URL: http://svn.apache.org/viewvc?rev=992877&view=rev
> Log:
> Attempt to solve both the CLOSE_WAIT issue and AXIS2-4751 on the trunk:
> * Reverted r963710 (Jarek's second change for AXIS2-4751 on the trunk) to
> get back to the correct baseline for merging r790721.
> * Merged r790721 (CLOSE_WAIT issue) from the 1.5 branch back to the trunk.
> This had never been done, presumably because it caused issues in Rampart
> (that were actually due to a bug in Rampart, fixed in r992868).
> * Merged r824340 (Another change to AbstractHTTPSender that Glen only
> applied to the 1.5 branch) to the trunk.
> * Merged r958718 (Jarek's original change for AXIS2-4751 on the 1.5 branch)
> to the trunk.
>
> Modified:
> axis/axis2/java/core/trunk/ (props changed)
>
> axis/axis2/java/core/trunk/modules/adb-codegen/test-resources/testsuite/attribute.xsd
> (props changed)
>
> axis/axis2/java/core/trunk/modules/adb-codegen/test-resources/testsuite/chameleon_include.xsd
> (props changed)
>
> axis/axis2/java/core/trunk/modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
> (props changed)
> axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/jsr181/
> (props changed)
>
> axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/jsr181/JSR181Helper.java
> (props changed)
>
> axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/jsr181/JSR181HelperImpl.java
> (props changed)
>
> axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/jsr181/NullJSR181Helper.java
> (props changed)
>
> axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/jsr181/WebMethodAnnotation.java
> (props changed)
>
> axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/jsr181/WebParamAnnotation.java
> (props changed)
>
> axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/jsr181/WebResultAnnotation.java
> (props changed)
>
> axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/jsr181/WebServiceAnnotation.java
> (props changed)
>
> axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/jsr181/package-info.java
> (props changed)
>
> axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/transport/http/util/QueryStringParser.java
> (props changed)
>
> axis/axis2/java/core/trunk/modules/kernel/test/org/apache/axis2/transport/http/util/QueryStringParserTest.java
> (props changed)
> axis/axis2/java/core/trunk/modules/transport/http/pom.xml (props
> changed)
> axis/axis2/java/core/trunk/modules/transport/http/src/ (props changed)
>
> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
> axis/axis2/java/core/trunk/modules/transport/local/ (props changed)
>
> axis/axis2/java/core/trunk/modules/webapp/src/main/java/org/apache/axis2/transport/
> (props changed)
>
> axis/axis2/java/core/trunk/modules/webapp/src/main/java/org/apache/axis2/transport/http/
> (props changed)
>
> axis/axis2/java/core/trunk/modules/webapp/src/main/java/org/apache/axis2/transport/http/AxisAdminServlet.java
> (props changed)
>
> axis/axis2/java/core/trunk/modules/webapp/src/main/java/org/apache/axis2/webapp/AdminAgent.java
> (props changed)
>
> axis/axis2/java/core/trunk/modules/webapp/src/main/java/org/apache/axis2/webapp/AxisAdminServlet.java
> (props changed)
>
> Propchange: axis/axis2/java/core/trunk/
>
> ------------------------------------------------------------------------------
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Sun Sep 5 19:38:56 2010
> @@ -1,2 +1,2 @@
> -/axis/axis2/java/core/branches/java/1_5:966825,986944
>
> -/webservices/axis2/branches/java/1_5:745088,749052,749058,751161,751271,760467,765840,790721
> +/axis/axis2/java/core/branches/java/1_5:958718,966825,986944
>
> +/webservices/axis2/branches/java/1_5:745088,749052,749058,751161,751271,760467,765840,790721,824340
>
> Propchange:
> axis/axis2/java/core/trunk/modules/adb-codegen/test-resources/testsuite/attribute.xsd
>
> ------------------------------------------------------------------------------
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Sun Sep 5 19:38:56 2010
> @@ -1 +1 @@
>
> -/axis/axis2/java/core/branches/java/1_5/modules/adb-codegen/test-resources/testsuite/attribute.xsd:966825,986944
>
> +/axis/axis2/java/core/branches/java/1_5/modules/adb-codegen/test-resources/testsuite/attribute.xsd:958718,966825,986944
>
> Propchange:
> axis/axis2/java/core/trunk/modules/adb-codegen/test-resources/testsuite/chameleon_include.xsd
>
> ------------------------------------------------------------------------------
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Sun Sep 5 19:38:56 2010
> @@ -1 +1 @@
>
> -/axis/axis2/java/core/branches/java/1_5/modules/adb-codegen/test-resources/testsuite/chameleon_include.xsd:966825,986944
>
> +/axis/axis2/java/core/branches/java/1_5/modules/adb-codegen/test-resources/testsuite/chameleon_include.xsd:958718,966825,986944
>
> Propchange:
> axis/axis2/java/core/trunk/modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
>
> ------------------------------------------------------------------------------
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Sun Sep 5 19:38:56 2010
> @@ -1 +1 @@
>
> -/axis/axis2/java/core/branches/java/1_5/modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs:966825,986944
>
> +/axis/axis2/java/core/branches/java/1_5/modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs:958718,966825,986944
>
> Propchange:
> axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/jsr181/
>
> ------------------------------------------------------------------------------
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Sun Sep 5 19:38:56 2010
> @@ -1,2 +1,2 @@
>
> -/axis/axis2/java/core/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181:966825*,986944*
>
> -/webservices/axis2/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181:745088,749052,749058,751161,751271,760467,765840,790721
>
> +/axis/axis2/java/core/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181:958718*,966825*,986944*
>
> +/webservices/axis2/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181:745088,749052,749058,751161,751271,760467,765840,790721,824340*
>
> Propchange:
> axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/jsr181/JSR181Helper.java
>
> ------------------------------------------------------------------------------
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Sun Sep 5 19:38:56 2010
> @@ -1,2 +1,2 @@
>
> -/axis/axis2/java/core/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/JSR181Helper.java:966825,986944
>
> -/webservices/axis2/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/JSR181Helper.java:745088,749052,749058,751161,751271,760467,765840,790721
>
> +/axis/axis2/java/core/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/JSR181Helper.java:958718,966825,986944
>
> +/webservices/axis2/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/JSR181Helper.java:745088,749052,749058,751161,751271,760467,765840,790721,824340
>
> Propchange:
> axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/jsr181/JSR181HelperImpl.java
>
> ------------------------------------------------------------------------------
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Sun Sep 5 19:38:56 2010
> @@ -1,2 +1,2 @@
>
> -/axis/axis2/java/core/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/JSR181HelperImpl.java:966825,986944
>
> -/webservices/axis2/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/JSR181HelperImpl.java:745088,749052,749058,751161,751271,760467,765840,790721
>
> +/axis/axis2/java/core/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/JSR181HelperImpl.java:958718,966825,986944
>
> +/webservices/axis2/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/JSR181HelperImpl.java:745088,749052,749058,751161,751271,760467,765840,790721,824340
>
> Propchange:
> axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/jsr181/NullJSR181Helper.java
>
> ------------------------------------------------------------------------------
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Sun Sep 5 19:38:56 2010
> @@ -1,2 +1,2 @@
>
> -/axis/axis2/java/core/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/NullJSR181Helper.java:966825,986944
>
> -/webservices/axis2/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/NullJSR181Helper.java:745088,749052,749058,751161,751271,760467,765840,790721
>
> +/axis/axis2/java/core/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/NullJSR181Helper.java:958718,966825,986944
>
> +/webservices/axis2/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/NullJSR181Helper.java:745088,749052,749058,751161,751271,760467,765840,790721,824340
>
> Propchange:
> axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/jsr181/WebMethodAnnotation.java
>
> ------------------------------------------------------------------------------
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Sun Sep 5 19:38:56 2010
> @@ -1,2 +1,2 @@
>
> -/axis/axis2/java/core/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/WebMethodAnnotation.java:966825,986944
>
> -/webservices/axis2/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/WebMethodAnnotation.java:745088,749052,749058,751161,751271,760467,765840,790721
>
> +/axis/axis2/java/core/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/WebMethodAnnotation.java:958718,966825,986944
>
> +/webservices/axis2/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/WebMethodAnnotation.java:745088,749052,749058,751161,751271,760467,765840,790721,824340
>
> Propchange:
> axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/jsr181/WebParamAnnotation.java
>
> ------------------------------------------------------------------------------
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Sun Sep 5 19:38:56 2010
> @@ -1,2 +1,2 @@
>
> -/axis/axis2/java/core/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/WebParamAnnotation.java:966825,986944
>
> -/webservices/axis2/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/WebParamAnnotation.java:745088,749052,749058,751161,751271,760467,765840,790721
>
> +/axis/axis2/java/core/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/WebParamAnnotation.java:958718,966825,986944
>
> +/webservices/axis2/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/WebParamAnnotation.java:745088,749052,749058,751161,751271,760467,765840,790721,824340
>
> Propchange:
> axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/jsr181/WebResultAnnotation.java
>
> ------------------------------------------------------------------------------
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Sun Sep 5 19:38:56 2010
> @@ -1,2 +1,2 @@
>
> -/axis/axis2/java/core/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/WebResultAnnotation.java:966825,986944
>
> -/webservices/axis2/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/WebResultAnnotation.java:745088,749052,749058,751161,751271,760467,765840,790721
>
> +/axis/axis2/java/core/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/WebResultAnnotation.java:958718,966825,986944
>
> +/webservices/axis2/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/WebResultAnnotation.java:745088,749052,749058,751161,751271,760467,765840,790721,824340
>
> Propchange:
> axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/jsr181/WebServiceAnnotation.java
>
> ------------------------------------------------------------------------------
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Sun Sep 5 19:38:56 2010
> @@ -1,2 +1,2 @@
>
> -/axis/axis2/java/core/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/WebServiceAnnotation.java:966825,986944
>
> -/webservices/axis2/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/WebServiceAnnotation.java:745088,749052,749058,751161,751271,760467,765840,790721
>
> +/axis/axis2/java/core/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/WebServiceAnnotation.java:958718,966825,986944
>
> +/webservices/axis2/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/WebServiceAnnotation.java:745088,749052,749058,751161,751271,760467,765840,790721,824340
>
> Propchange:
> axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/jsr181/package-info.java
>
> ------------------------------------------------------------------------------
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Sun Sep 5 19:38:56 2010
> @@ -1,2 +1,2 @@
>
> -/axis/axis2/java/core/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/package-info.java:966825,986944
>
> -/webservices/axis2/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/package-info.java:745088,749052,749058,751161,751271,760467,765840,790721
>
> +/axis/axis2/java/core/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/package-info.java:958718,966825,986944
>
> +/webservices/axis2/branches/java/1_5/modules/kernel/src/org/apache/axis2/jsr181/package-info.java:745088,749052,749058,751161,751271,760467,765840,790721,824340
>
> Propchange:
> axis/axis2/java/core/trunk/modules/kernel/src/org/apache/axis2/transport/http/util/QueryStringParser.java
>
> ------------------------------------------------------------------------------
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Sun Sep 5 19:38:56 2010
> @@ -1,2 +1,2 @@
>
> -/axis/axis2/java/core/branches/java/1_5/modules/kernel/src/org/apache/axis2/transport/http/util/QueryStringParser.java:966825,986944
>
> -/webservices/axis2/branches/java/1_5/modules/kernel/src/org/apache/axis2/transport/http/util/QueryStringParser.java:765840
>
> +/axis/axis2/java/core/branches/java/1_5/modules/kernel/src/org/apache/axis2/transport/http/util/QueryStringParser.java:958718,966825,986944
>
> +/webservices/axis2/branches/java/1_5/modules/kernel/src/org/apache/axis2/transport/http/util/QueryStringParser.java:765840,790721,824340
>
> Propchange:
> axis/axis2/java/core/trunk/modules/kernel/test/org/apache/axis2/transport/http/util/QueryStringParserTest.java
>
> ------------------------------------------------------------------------------
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Sun Sep 5 19:38:56 2010
> @@ -1,2 +1,2 @@
>
> -/axis/axis2/java/core/branches/java/1_5/modules/kernel/test/org/apache/axis2/transport/http/util/QueryStringParserTest.java:966825,986944
>
> -/webservices/axis2/branches/java/1_5/modules/kernel/test/org/apache/axis2/transport/http/util/QueryStringParserTest.java:765840
>
> +/axis/axis2/java/core/branches/java/1_5/modules/kernel/test/org/apache/axis2/transport/http/util/QueryStringParserTest.java:958718,966825,986944
>
> +/webservices/axis2/branches/java/1_5/modules/kernel/test/org/apache/axis2/transport/http/util/QueryStringParserTest.java:765840,790721,824340
>
> Propchange: axis/axis2/java/core/trunk/modules/transport/http/pom.xml
>
> ------------------------------------------------------------------------------
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Sun Sep 5 19:38:56 2010
> @@ -1,3 +1,3 @@
>
> -/axis/axis2/java/core/branches/java/1_5/modules/transport/http/pom.xml:966825,986944
>
> -/webservices/axis2/branches/java/1_5/modules/transport/http/pom.xml:765840,790721
>
> +/axis/axis2/java/core/branches/java/1_5/modules/transport/http/pom.xml:958718,966825,986944
>
> +/webservices/axis2/branches/java/1_5/modules/transport/http/pom.xml:765840,790721,824340
> /webservices/axis2/tags/java/v1.5/modules/transport/http/pom.xml:790721
>
> Propchange: axis/axis2/java/core/trunk/modules/transport/http/src/
>
> ------------------------------------------------------------------------------
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Sun Sep 5 19:38:56 2010
> @@ -1,2 +1,2 @@
>
> -/axis/axis2/java/core/branches/java/1_5/modules/transport/http/src:966825,986944
> -/webservices/axis2/branches/java/1_5/modules/transport/http/src:765840
>
> +/axis/axis2/java/core/branches/java/1_5/modules/transport/http/src:958718,966825,986944
>
> +/webservices/axis2/branches/java/1_5/modules/transport/http/src:765840,790721,824340
>
> Modified:
> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
> URL:
> http://svn.apache.org/viewvc/axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java?rev=992877&r1=992876&r2=992877&view=diff
>
> ==============================================================================
> ---
> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
> (original)
> +++
> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
> Sun Sep 5 19:38:56 2010
> @@ -25,12 +25,13 @@ import org.apache.axiom.om.OMOutputForma
> import org.apache.axis2.AxisFault;
> import org.apache.axis2.Constants;
> import org.apache.axis2.context.MessageContext;
> -import org.apache.axis2.context.ConfigurationContext;
> import org.apache.axis2.context.OperationContext;
> +import org.apache.axis2.context.ConfigurationContext;
> import org.apache.axis2.description.TransportOutDescription;
> import org.apache.axis2.i18n.Messages;
> import org.apache.axis2.transport.MessageFormatter;
> import org.apache.axis2.transport.TransportUtils;
> +import org.apache.axis2.util.JavaUtils;
> import org.apache.axis2.wsdl.WSDLConstants;
> import org.apache.commons.httpclient.Credentials;
> import org.apache.commons.httpclient.Header;
> @@ -49,6 +50,8 @@ import org.apache.commons.httpclient.Use
> import org.apache.commons.httpclient.auth.AuthPolicy;
> import org.apache.commons.httpclient.auth.AuthScope;
> import org.apache.commons.httpclient.params.HttpMethodParams;
> +import org.apache.commons.httpclient.params.HttpConnectionManagerParams;
> +import org.apache.commons.httpclient.params.HttpClientParams;
> import org.apache.commons.httpclient.protocol.Protocol;
> import org.apache.commons.logging.Log;
> import org.apache.commons.logging.LogFactory;
> @@ -510,21 +513,16 @@ public abstract class AbstractHTTPSender
>
> HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
> if (connManager == null) {
> log.trace("Making new ConnectionManager");
> - connManager = new
> MultiThreadedHttpConnectionManager();
> - /*
> - * Commented out for now as bugs in other parts of
> Axis2 cause test failures when
> - * proper connection reuse is enabled.
> - */
> - //
> configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
> - // connManager);
> -
> + connManager = new
> MultiThreadedHttpConnectionManager();
> +
> configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
> + connManager);
> }
>
-1 on this change.
This tries to solve the problem by introducing another problem. Now since
configuration context is set to use one MultiThreadedHttpConnectionManager
it can only make two simultaneous connections for one host.
If some one wants this behavior it can be easily done even with the earlier
code by setting appropriate parameters.
thanks,
Amila.
> }
> }
>
> /*
> - * Create a new instance of HttpClient since it is not
> - * used in thread-safe way here.
> + * Create a new instance of HttpClient since the way
> + * it is used here it's not fully thread-safe.
> */
> httpClient = new HttpClient(connManager);
>
> @@ -541,7 +539,8 @@ public abstract class AbstractHTTPSender
> HttpMethod method) throws IOException {
> HostConfiguration config = this.getHostConfiguration(httpClient,
> msgContext, url);
>
> - msgContext.setProperty(HTTPConstants.HTTP_METHOD, method);
> + if (!msgContext.getOptions().isUseSeparateListener())
> + msgContext.setProperty(HTTPConstants.HTTP_METHOD, method);
>
> // set the custom headers, if available
> addCustomHeaders(method, msgContext);
>
> Propchange: axis/axis2/java/core/trunk/modules/transport/local/
>
> ------------------------------------------------------------------------------
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Sun Sep 5 19:38:56 2010
> @@ -1,2 +1,2 @@
>
> -/axis/axis2/java/core/branches/java/1_5/modules/transport/local:966825,986944
> -/webservices/axis2/branches/java/1_5/modules/transport/local:765840
>
> +/axis/axis2/java/core/branches/java/1_5/modules/transport/local:958718,966825,986944
>
> +/webservices/axis2/branches/java/1_5/modules/transport/local:765840,790721,824340
>
> Propchange:
> axis/axis2/java/core/trunk/modules/webapp/src/main/java/org/apache/axis2/transport/
>
> ------------------------------------------------------------------------------
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Sun Sep 5 19:38:56 2010
> @@ -1,2 +1,2 @@
>
> -/axis/axis2/java/core/branches/java/1_5/modules/webapp/src/main/java/org/apache/axis2/transport:966825*,986944*
>
> -/webservices/axis2/branches/java/1_5/modules/webapp/src/main/java/org/apache/axis2/transport:745088,749052,749058,751161,751271,760467,765840,790721
>
> +/axis/axis2/java/core/branches/java/1_5/modules/webapp/src/main/java/org/apache/axis2/transport:958718*,966825*,986944*
>
> +/webservices/axis2/branches/java/1_5/modules/webapp/src/main/java/org/apache/axis2/transport:745088,749052,749058,751161,751271,760467,765840,790721,824340*
>
> Propchange:
> axis/axis2/java/core/trunk/modules/webapp/src/main/java/org/apache/axis2/transport/http/
>
> ------------------------------------------------------------------------------
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Sun Sep 5 19:38:56 2010
> @@ -1,2 +1,2 @@
>
> -/axis/axis2/java/core/branches/java/1_5/modules/webapp/src/main/java/org/apache/axis2/transport/http:966825*,986944*
>
> -/webservices/axis2/branches/java/1_5/modules/webapp/src/main/java/org/apache/axis2/transport/http:745088,749052,749058,751161,751271,760467,765840,790721
>
> +/axis/axis2/java/core/branches/java/1_5/modules/webapp/src/main/java/org/apache/axis2/transport/http:958718*,966825*,986944*
>
> +/webservices/axis2/branches/java/1_5/modules/webapp/src/main/java/org/apache/axis2/transport/http:745088,749052,749058,751161,751271,760467,765840,790721,824340*
>
> Propchange:
> axis/axis2/java/core/trunk/modules/webapp/src/main/java/org/apache/axis2/transport/http/AxisAdminServlet.java
>
> ------------------------------------------------------------------------------
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Sun Sep 5 19:38:56 2010
> @@ -1,2 +1,2 @@
>
> -/axis/axis2/java/core/branches/java/1_5/modules/webapp/src/main/java/org/apache/axis2/transport/http/AxisAdminServlet.java:966825,986944
>
> -/webservices/axis2/branches/java/1_5/modules/webapp/src/main/java/org/apache/axis2/transport/http/AxisAdminServlet.java:745088,749052,749058,751161,751271,760467,765840,790721
>
> +/axis/axis2/java/core/branches/java/1_5/modules/webapp/src/main/java/org/apache/axis2/transport/http/AxisAdminServlet.java:958718,966825,986944
>
> +/webservices/axis2/branches/java/1_5/modules/webapp/src/main/java/org/apache/axis2/transport/http/AxisAdminServlet.java:745088,749052,749058,751161,751271,760467,765840,790721,824340
>
> Propchange:
> axis/axis2/java/core/trunk/modules/webapp/src/main/java/org/apache/axis2/webapp/AdminAgent.java
>
> ------------------------------------------------------------------------------
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Sun Sep 5 19:38:56 2010
> @@ -1,2 +1,2 @@
>
> -/axis/axis2/java/core/branches/java/1_5/modules/webapp/src/main/java/org/apache/axis2/webapp/AdminAgent.java:966825,986944
>
> -/webservices/axis2/branches/java/1_5/modules/webapp/src/main/java/org/apache/axis2/webapp/AdminAgent.java:765840
>
> +/axis/axis2/java/core/branches/java/1_5/modules/webapp/src/main/java/org/apache/axis2/webapp/AdminAgent.java:958718,966825,986944
>
> +/webservices/axis2/branches/java/1_5/modules/webapp/src/main/java/org/apache/axis2/webapp/AdminAgent.java:765840,790721,824340
>
> Propchange:
> axis/axis2/java/core/trunk/modules/webapp/src/main/java/org/apache/axis2/webapp/AxisAdminServlet.java
>
> ------------------------------------------------------------------------------
> --- svn:mergeinfo (original)
> +++ svn:mergeinfo Sun Sep 5 19:38:56 2010
> @@ -1,2 +1,2 @@
>
> -/axis/axis2/java/core/branches/java/1_5/modules/webapp/src/main/java/org/apache/axis2/webapp/AxisAdminServlet.java:966825,986944
>
> -/webservices/axis2/branches/java/1_5/modules/webapp/src/main/java/org/apache/axis2/webapp/AxisAdminServlet.java:765840
>
> +/axis/axis2/java/core/branches/java/1_5/modules/webapp/src/main/java/org/apache/axis2/webapp/AxisAdminServlet.java:958718,966825,986944
>
> +/webservices/axis2/branches/java/1_5/modules/webapp/src/main/java/org/apache/axis2/webapp/AxisAdminServlet.java:765840,790721,824340
>
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Sep 17, 2010 at 7:41 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi Amila, Jarek,
>
> On 9/17/2010 7:55 AM, Amila Suriarachchi wrote:
> > As I told, this bug is reported with Axis2 1.5.1 not with trunk. hence
> this
> > issue is not relevant.
>
> The issue isn't just 4751, Amila - the larger issues were 935, 2883, and
> others (search for CLOSE_WAIT). When we used the old (pre-1.5.1) methods
> of
> connection management, there was a significant problem with memory leakage
> and connection starvation, even if options.setCallTransportCleanup() had
> been
> called. The following code would die after about 3600 repetitions on
> Windows, some other number on linux:
>
> ServiceClient client = new ServiceClient();
> Options options = new Options();
> // options.setCallTransportCleanup(true); // Doesn't matter
> options.setTo(new
> EndpointReference("http://localhost:8080/axis2/services/Version"));
> options.setAction("urn:getVersion");
> client.setOptions(options);
> SOAPFactory fac = OMAbstractFactory.getSOAP11Factory();
> String NS = "http://ws.apache.org/axis2";
> OMElement req = fac.createOMElement(new QName(NS, "getVersion"));
> for (int i = 0; i < 10000; i++) {
> client.sendReceive(req);
> System.out.println(i);
> }
> System.out.println("All done.");
>
> The above will happily chug along forever with 1.5.1 and 1.5.2.
>
Does this works without client.cleanupTransport()?
What you try to show here is an high load case. For that even with Axis2 1.5
users can move to option 2 or 3 (please see my other mail) by setting proper
parameters.
thanks,
Amila.
>
> > this is the original code.
> > [...]
> > it reuses http client only if user has set so. otherwise if the user has
> set
> > an http connection manager object then
> > it creates a new httpClient per every call.
> >
> > I'll revert this change since issue you point out is not applicable here.
>
> Please don't do any further reverting. I'd suggest as Jarek did that we
> start another thread re: connection sharing. I think the right answer is
> to
> always use connection sharing and if you need more than 2 concurrent
> connections to a given host you should just configure the
> HttpConnectionManagerParams.
>
> IMHO for 1.6 we need to:
>
> * Make sure sessions / cookies work as expected
> * Move to HTTPClient 4.0
> * Make sure we have a test suite that covers all the potential breakages,
> including the test above
>
> Thanks,
> --Glen
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Sep 17, 2010 at 7:41 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi Amila, Jarek,
>
> On 9/17/2010 7:55 AM, Amila Suriarachchi wrote:
> > As I told, this bug is reported with Axis2 1.5.1 not with trunk. hence
> this
> > issue is not relevant.
>
> The issue isn't just 4751, Amila - the larger issues were 935, 2883, and
> others (search for CLOSE_WAIT). When we used the old (pre-1.5.1) methods
> of
> connection management, there was a significant problem with memory leakage
> and connection starvation, even if options.setCallTransportCleanup() had
> been
> called. The following code would die after about 3600 repetitions on
> Windows, some other number on linux:
>
> ServiceClient client = new ServiceClient();
> Options options = new Options();
> // options.setCallTransportCleanup(true); // Doesn't matter
> options.setTo(new
> EndpointReference("http://localhost:8080/axis2/services/Version"));
> options.setAction("urn:getVersion");
> client.setOptions(options);
> SOAPFactory fac = OMAbstractFactory.getSOAP11Factory();
> String NS = "http://ws.apache.org/axis2";
> OMElement req = fac.createOMElement(new QName(NS, "getVersion"));
> for (int i = 0; i < 10000; i++) {
> client.sendReceive(req);
> System.out.println(i);
> }
> System.out.println("All done.");
>
> The above will happily chug along forever with 1.5.1 and 1.5.2.
>
Does this works without client.cleanupTransport()?
What you try to show here is an high load case. For that even with Axis2 1.5
users can move to option 2 or 3 (please see my other mail) by setting proper
parameters.
thanks,
Amila.
>
> > this is the original code.
> > [...]
> > it reuses http client only if user has set so. otherwise if the user has
> set
> > an http connection manager object then
> > it creates a new httpClient per every call.
> >
> > I'll revert this change since issue you point out is not applicable here.
>
> Please don't do any further reverting. I'd suggest as Jarek did that we
> start another thread re: connection sharing. I think the right answer is
> to
> always use connection sharing and if you need more than 2 concurrent
> connections to a given host you should just configure the
> HttpConnectionManagerParams.
>
> IMHO for 1.6 we need to:
>
> * Make sure sessions / cookies work as expected
> * Move to HTTPClient 4.0
> * Make sure we have a test suite that covers all the potential breakages,
> including the test above
>
> Thanks,
> --Glen
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Sep 17, 2010 at 7:41 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi Amila, Jarek,
>
> On 9/17/2010 7:55 AM, Amila Suriarachchi wrote:
> > As I told, this bug is reported with Axis2 1.5.1 not with trunk. hence
> this
> > issue is not relevant.
>
> The issue isn't just 4751, Amila - the larger issues were 935, 2883, and
> others (search for CLOSE_WAIT). When we used the old (pre-1.5.1) methods
> of
> connection management, there was a significant problem with memory leakage
> and connection starvation, even if options.setCallTransportCleanup() had
> been
> called. The following code would die after about 3600 repetitions on
> Windows, some other number on linux:
>
> ServiceClient client = new ServiceClient();
> Options options = new Options();
> // options.setCallTransportCleanup(true); // Doesn't matter
> options.setTo(new
> EndpointReference("http://localhost:8080/axis2/services/Version"));
> options.setAction("urn:getVersion");
> client.setOptions(options);
> SOAPFactory fac = OMAbstractFactory.getSOAP11Factory();
> String NS = "http://ws.apache.org/axis2";
> OMElement req = fac.createOMElement(new QName(NS, "getVersion"));
> for (int i = 0; i < 10000; i++) {
> client.sendReceive(req);
> System.out.println(i);
> }
> System.out.println("All done.");
>
> The above will happily chug along forever with 1.5.1 and 1.5.2.
>
Does this works without client.cleanupTransport()?
What you try to show here is an high load case. For that even with Axis2 1.5
users can move to option 2 or 3 (please see my other mail) by setting proper
parameters.
thanks,
Amila.
>
> > this is the original code.
> > [...]
> > it reuses http client only if user has set so. otherwise if the user has
> set
> > an http connection manager object then
> > it creates a new httpClient per every call.
> >
> > I'll revert this change since issue you point out is not applicable here.
>
> Please don't do any further reverting. I'd suggest as Jarek did that we
> start another thread re: connection sharing. I think the right answer is
> to
> always use connection sharing and if you need more than 2 concurrent
> connections to a given host you should just configure the
> HttpConnectionManagerParams.
>
> IMHO for 1.6 we need to:
>
> * Make sure sessions / cookies work as expected
> * Move to HTTPClient 4.0
> * Make sure we have a test suite that covers all the potential breakages,
> including the test above
>
> Thanks,
> --Glen
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Sep 17, 2010 at 7:41 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi Amila, Jarek,
>
> On 9/17/2010 7:55 AM, Amila Suriarachchi wrote:
> > As I told, this bug is reported with Axis2 1.5.1 not with trunk. hence
> this
> > issue is not relevant.
>
> The issue isn't just 4751, Amila - the larger issues were 935, 2883, and
> others (search for CLOSE_WAIT). When we used the old (pre-1.5.1) methods
> of
> connection management, there was a significant problem with memory leakage
> and connection starvation, even if options.setCallTransportCleanup() had
> been
> called. The following code would die after about 3600 repetitions on
> Windows, some other number on linux:
>
> ServiceClient client = new ServiceClient();
> Options options = new Options();
> // options.setCallTransportCleanup(true); // Doesn't matter
> options.setTo(new
> EndpointReference("http://localhost:8080/axis2/services/Version"));
> options.setAction("urn:getVersion");
> client.setOptions(options);
> SOAPFactory fac = OMAbstractFactory.getSOAP11Factory();
> String NS = "http://ws.apache.org/axis2";
> OMElement req = fac.createOMElement(new QName(NS, "getVersion"));
> for (int i = 0; i < 10000; i++) {
> client.sendReceive(req);
> System.out.println(i);
> }
> System.out.println("All done.");
>
> The above will happily chug along forever with 1.5.1 and 1.5.2.
>
Does this works without client.cleanupTransport()?
What you try to show here is an high load case. For that even with Axis2 1.5
users can move to option 2 or 3 (please see my other mail) by setting proper
parameters.
thanks,
Amila.
>
> > this is the original code.
> > [...]
> > it reuses http client only if user has set so. otherwise if the user has
> set
> > an http connection manager object then
> > it creates a new httpClient per every call.
> >
> > I'll revert this change since issue you point out is not applicable here.
>
> Please don't do any further reverting. I'd suggest as Jarek did that we
> start another thread re: connection sharing. I think the right answer is
> to
> always use connection sharing and if you need more than 2 concurrent
> connections to a given host you should just configure the
> HttpConnectionManagerParams.
>
> IMHO for 1.6 we need to:
>
> * Make sure sessions / cookies work as expected
> * Move to HTTPClient 4.0
> * Make sure we have a test suite that covers all the potential breakages,
> including the test above
>
> Thanks,
> --Glen
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Sep 17, 2010 at 7:41 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi Amila, Jarek,
>
> On 9/17/2010 7:55 AM, Amila Suriarachchi wrote:
> > As I told, this bug is reported with Axis2 1.5.1 not with trunk. hence
> this
> > issue is not relevant.
>
> The issue isn't just 4751, Amila - the larger issues were 935, 2883, and
> others (search for CLOSE_WAIT). When we used the old (pre-1.5.1) methods
> of
> connection management, there was a significant problem with memory leakage
> and connection starvation, even if options.setCallTransportCleanup() had
> been
> called. The following code would die after about 3600 repetitions on
> Windows, some other number on linux:
>
> ServiceClient client = new ServiceClient();
> Options options = new Options();
> // options.setCallTransportCleanup(true); // Doesn't matter
> options.setTo(new
> EndpointReference("http://localhost:8080/axis2/services/Version"));
> options.setAction("urn:getVersion");
> client.setOptions(options);
> SOAPFactory fac = OMAbstractFactory.getSOAP11Factory();
> String NS = "http://ws.apache.org/axis2";
> OMElement req = fac.createOMElement(new QName(NS, "getVersion"));
> for (int i = 0; i < 10000; i++) {
> client.sendReceive(req);
> System.out.println(i);
> }
> System.out.println("All done.");
>
> The above will happily chug along forever with 1.5.1 and 1.5.2.
>
Does this works without client.cleanupTransport()?
What you try to show here is an high load case. For that even with Axis2 1.5
users can move to option 2 or 3 (please see my other mail) by setting proper
parameters.
thanks,
Amila.
>
> > this is the original code.
> > [...]
> > it reuses http client only if user has set so. otherwise if the user has
> set
> > an http connection manager object then
> > it creates a new httpClient per every call.
> >
> > I'll revert this change since issue you point out is not applicable here.
>
> Please don't do any further reverting. I'd suggest as Jarek did that we
> start another thread re: connection sharing. I think the right answer is
> to
> always use connection sharing and if you need more than 2 concurrent
> connections to a given host you should just configure the
> HttpConnectionManagerParams.
>
> IMHO for 1.6 we need to:
>
> * Make sure sessions / cookies work as expected
> * Move to HTTPClient 4.0
> * Make sure we have a test suite that covers all the potential breakages,
> including the test above
>
> Thanks,
> --Glen
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/
modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/
modules/kernel/src/org/apache/a
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Amila, Jarek,
On 9/17/2010 7:55 AM, Amila Suriarachchi wrote:
> As I told, this bug is reported with Axis2 1.5.1 not with trunk. hence this
> issue is not relevant.
The issue isn't just 4751, Amila - the larger issues were 935, 2883, and
others (search for CLOSE_WAIT). When we used the old (pre-1.5.1) methods of
connection management, there was a significant problem with memory leakage
and connection starvation, even if options.setCallTransportCleanup() had been
called. The following code would die after about 3600 repetitions on
Windows, some other number on linux:
ServiceClient client = new ServiceClient();
Options options = new Options();
// options.setCallTransportCleanup(true); // Doesn't matter
options.setTo(new
EndpointReference("http://localhost:8080/axis2/services/Version"));
options.setAction("urn:getVersion");
client.setOptions(options);
SOAPFactory fac = OMAbstractFactory.getSOAP11Factory();
String NS = "http://ws.apache.org/axis2";
OMElement req = fac.createOMElement(new QName(NS, "getVersion"));
for (int i = 0; i < 10000; i++) {
client.sendReceive(req);
System.out.println(i);
}
System.out.println("All done.");
The above will happily chug along forever with 1.5.1 and 1.5.2.
> this is the original code.
> [...]
> it reuses http client only if user has set so. otherwise if the user has set
> an http connection manager object then
> it creates a new httpClient per every call.
>
> I'll revert this change since issue you point out is not applicable here.
Please don't do any further reverting. I'd suggest as Jarek did that we
start another thread re: connection sharing. I think the right answer is to
always use connection sharing and if you need more than 2 concurrent
connections to a given host you should just configure the
HttpConnectionManagerParams.
IMHO for 1.6 we need to:
* Make sure sessions / cookies work as expected
* Move to HTTPClient 4.0
* Make sure we have a test suite that covers all the potential breakages,
including the test above
Thanks,
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/
modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/
modules/kernel/src/org/apache/a
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Jarek,
On 9/17/2010 11:06 AM, Jarek Gawor wrote:
> An attempt was made in the 1.5 branch to ensure connection pool is
> reused between the calls but that reused HttpClient instance instead
> of HttpConnectionManager instance... and you know the rest.
Not to beat a dead horse :), but AFAIK Oleg still recommends using a single
HTTPClient across multiple threads. It's true that using it that way will
mean having to pass a separate HTTPState object to each execute() call, but
that's apparently the recommended pattern.
See this thread - http://bit.ly/cWlfYD
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Sep 17, 2010 at 8:36 PM, Jarek Gawor <jg...@gmail.com> wrote:
> On Fri, Sep 17, 2010 at 7:55 AM, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >
> >>
> >> See https://issues.apache.org/jira/browse/AXIS2-4751 for details. The
> >> thread safety problem was solved by not reusing HttpClient instance.
> >
> > As I told, this bug is reported with Axis2 1.5.1 not with trunk. hence
> this
> > issue is not relevant.
> >
> > this is the original code.
> > HttpClient httpClient;
> > Object reuse =
> > msgContext.getOptions().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
> > if (reuse == null) {
> > reuse =
> >
> msgContext.getConfigurationContext().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
> > }
> >
> > if (reuse != null && JavaUtils.isTrueExplicitly(reuse)) {
> > httpClient = (HttpClient)
> > msgContext.getOptions().getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
> > if (httpClient == null) {
> > httpClient = (HttpClient)
> > msgContext.getConfigurationContext()
> > .getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
> > }
> > if (httpClient != null)
> > return httpClient;
> > MultiThreadedHttpConnectionManager connectionManager =
> > new MultiThreadedHttpConnectionManager();
> > httpClient = new HttpClient(connectionManager);
> > msgContext.getConfigurationContext()
> > .setProperty(HTTPConstants.CACHED_HTTP_CLIENT,
> > httpClient);
> > } else {
> > HttpConnectionManager connManager =
> > (HttpConnectionManager) msgContext.getProperty(
> >
> > HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
> > if (connManager == null) {
> > connManager =
> > (HttpConnectionManager) msgContext.getProperty(
> >
> > HTTPConstants.MUTTITHREAD_HTTP_CONNECTION_MANAGER);
> > }
> > if (connManager != null) {
> > httpClient = new HttpClient(connManager);
> > } else {
> > //Multi threaded http connection manager has set as the
> > default
> > connManager = new MultiThreadedHttpConnectionManager();
> > httpClient = new HttpClient(connManager);
> > }
> > }
> >
> > // Get the timeout values set in the runtime
> > initializeTimeouts(msgContext, httpClient);
> >
> > return httpClient;
> >
> > it reuses http client only if user has set so. otherwise if the user has
> set
> > an http connection manager object then
> > it creates a new httpClient per every call.
>
> This code is bad for two reasons:
>
> 1) In the first block when REUSE_HTTP_CLIENT is true, the code will
> reuse HttpClient instance. As I mentioned before, that way we use
> HttpClient instance in the code right now is not thread safe.
>
Can you please explain how one can not come up with the same argument with
the current code?
Here people reuse httpClient if they know it is thread safe.
>
> This directly relates to the key problem my original changes were
> addressing.
>
Please see here[1]. What you are talking about an issue due to the changes
done only to Axis2 1.5.1.
> 2) When REUSE_HTTP_CLIENT is not set or false and
> MULTITHREAD_HTTP_CONNECTION_MANAGER is not set, the code will create a
> new instance of MultiThreadedHttpConnectionManager and HttpClient.
> Creating a new instance of MultiThreadedHttpConnectionManager on each
> call means it is creating a new connection pool per call but the
> connection pool is not really being reused. That can lead to a lot of
> connections being open and remain open longer then needed.
>
In Axis2 1.5 there are three possible methods in which http client is used.
1. Creating one connection per invocation
2. Reusing same httpClient object per all invocations
3. Reusing same connectionManager object for all invocations.
in Axis2 1.5.1 what is has done is actually restricting this to option 2.
Hence your issue.
Then the current code has restricted it to only option 2 and 3 and make
option 3 default.
In Axis2 1.5 the default is option 1. Which has the problems you mentioned
at the high loads. For normal
loads that is not a considerable problem. For such case users has option to
move into option 2 or 3 according to
their usage.
So what we try to say making option 3 as default (and removing options 1) is
that it supports high loads by default. But it is not the case as I shown
since it creates only two connections to the back end servers.
> An attempt was made in the 1.5 branch to ensure connection pool is
> reused between the calls but that reused HttpClient instance instead
> of HttpConnectionManager instance... and you know the rest.
>
> So, please do not revert back to this version of the code.
>
Even we agree to keep only option 2 and 3 (default) I see following problems
with this patch.
1. if (httpClient == null) {
httpClient = (HttpClient)
configContext.getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
}
No need to have this code. (yes this is there with the earlier code as well)
when you check with message context it
should have return the property if it in the configuration context.
2. if (connManager == null) {
// reuse HttpConnectionManager
synchronized (configContext) {
connManager = (HttpConnectionManager)
configContext.getProperty(
HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
if (connManager == null) {
log.trace("Making new ConnectionManager");
connManager = new MultiThreadedHttpConnectionManager();
configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
connManager);
}
}
}
Instead of doing this we need to set the connection manager at the transport
initialization time. We may be creating an unnecessary connection manage if
user always reuse the httpClient. But I think it is better than having a
synchronized block.
3. // Set the default timeout in case we have a connection pool starvation
to 30sec
httpClient.getParams().setConnectionManagerTimeout(30000);
remove this and ask users to must use serviceClient.cleanupTransport() since
option 2 and 3 requires this. otherwise connections are not released and the
system hangs.
thanks,
Amila.
[1]
http://svn.apache.org/viewvc/axis/axis2/java/core/branches/1_5/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java?revision=824340&view=markup
>
> Jarek
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/
modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/
modules/kernel/src/org/apache/a
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Jarek,
On 9/17/2010 11:06 AM, Jarek Gawor wrote:
> An attempt was made in the 1.5 branch to ensure connection pool is
> reused between the calls but that reused HttpClient instance instead
> of HttpConnectionManager instance... and you know the rest.
Not to beat a dead horse :), but AFAIK Oleg still recommends using a single
HTTPClient across multiple threads. It's true that using it that way will
mean having to pass a separate HTTPState object to each execute() call, but
that's apparently the recommended pattern.
See this thread - http://bit.ly/cWlfYD
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Sep 17, 2010 at 8:36 PM, Jarek Gawor <jg...@gmail.com> wrote:
> On Fri, Sep 17, 2010 at 7:55 AM, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >
> >>
> >> See https://issues.apache.org/jira/browse/AXIS2-4751 for details. The
> >> thread safety problem was solved by not reusing HttpClient instance.
> >
> > As I told, this bug is reported with Axis2 1.5.1 not with trunk. hence
> this
> > issue is not relevant.
> >
> > this is the original code.
> > HttpClient httpClient;
> > Object reuse =
> > msgContext.getOptions().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
> > if (reuse == null) {
> > reuse =
> >
> msgContext.getConfigurationContext().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
> > }
> >
> > if (reuse != null && JavaUtils.isTrueExplicitly(reuse)) {
> > httpClient = (HttpClient)
> > msgContext.getOptions().getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
> > if (httpClient == null) {
> > httpClient = (HttpClient)
> > msgContext.getConfigurationContext()
> > .getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
> > }
> > if (httpClient != null)
> > return httpClient;
> > MultiThreadedHttpConnectionManager connectionManager =
> > new MultiThreadedHttpConnectionManager();
> > httpClient = new HttpClient(connectionManager);
> > msgContext.getConfigurationContext()
> > .setProperty(HTTPConstants.CACHED_HTTP_CLIENT,
> > httpClient);
> > } else {
> > HttpConnectionManager connManager =
> > (HttpConnectionManager) msgContext.getProperty(
> >
> > HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
> > if (connManager == null) {
> > connManager =
> > (HttpConnectionManager) msgContext.getProperty(
> >
> > HTTPConstants.MUTTITHREAD_HTTP_CONNECTION_MANAGER);
> > }
> > if (connManager != null) {
> > httpClient = new HttpClient(connManager);
> > } else {
> > //Multi threaded http connection manager has set as the
> > default
> > connManager = new MultiThreadedHttpConnectionManager();
> > httpClient = new HttpClient(connManager);
> > }
> > }
> >
> > // Get the timeout values set in the runtime
> > initializeTimeouts(msgContext, httpClient);
> >
> > return httpClient;
> >
> > it reuses http client only if user has set so. otherwise if the user has
> set
> > an http connection manager object then
> > it creates a new httpClient per every call.
>
> This code is bad for two reasons:
>
> 1) In the first block when REUSE_HTTP_CLIENT is true, the code will
> reuse HttpClient instance. As I mentioned before, that way we use
> HttpClient instance in the code right now is not thread safe.
>
Can you please explain how one can not come up with the same argument with
the current code?
Here people reuse httpClient if they know it is thread safe.
>
> This directly relates to the key problem my original changes were
> addressing.
>
Please see here[1]. What you are talking about an issue due to the changes
done only to Axis2 1.5.1.
> 2) When REUSE_HTTP_CLIENT is not set or false and
> MULTITHREAD_HTTP_CONNECTION_MANAGER is not set, the code will create a
> new instance of MultiThreadedHttpConnectionManager and HttpClient.
> Creating a new instance of MultiThreadedHttpConnectionManager on each
> call means it is creating a new connection pool per call but the
> connection pool is not really being reused. That can lead to a lot of
> connections being open and remain open longer then needed.
>
In Axis2 1.5 there are three possible methods in which http client is used.
1. Creating one connection per invocation
2. Reusing same httpClient object per all invocations
3. Reusing same connectionManager object for all invocations.
in Axis2 1.5.1 what is has done is actually restricting this to option 2.
Hence your issue.
Then the current code has restricted it to only option 2 and 3 and make
option 3 default.
In Axis2 1.5 the default is option 1. Which has the problems you mentioned
at the high loads. For normal
loads that is not a considerable problem. For such case users has option to
move into option 2 or 3 according to
their usage.
So what we try to say making option 3 as default (and removing options 1) is
that it supports high loads by default. But it is not the case as I shown
since it creates only two connections to the back end servers.
> An attempt was made in the 1.5 branch to ensure connection pool is
> reused between the calls but that reused HttpClient instance instead
> of HttpConnectionManager instance... and you know the rest.
>
> So, please do not revert back to this version of the code.
>
Even we agree to keep only option 2 and 3 (default) I see following problems
with this patch.
1. if (httpClient == null) {
httpClient = (HttpClient)
configContext.getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
}
No need to have this code. (yes this is there with the earlier code as well)
when you check with message context it
should have return the property if it in the configuration context.
2. if (connManager == null) {
// reuse HttpConnectionManager
synchronized (configContext) {
connManager = (HttpConnectionManager)
configContext.getProperty(
HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
if (connManager == null) {
log.trace("Making new ConnectionManager");
connManager = new MultiThreadedHttpConnectionManager();
configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
connManager);
}
}
}
Instead of doing this we need to set the connection manager at the transport
initialization time. We may be creating an unnecessary connection manage if
user always reuse the httpClient. But I think it is better than having a
synchronized block.
3. // Set the default timeout in case we have a connection pool starvation
to 30sec
httpClient.getParams().setConnectionManagerTimeout(30000);
remove this and ask users to must use serviceClient.cleanupTransport() since
option 2 and 3 requires this. otherwise connections are not released and the
system hangs.
thanks,
Amila.
[1]
http://svn.apache.org/viewvc/axis/axis2/java/core/branches/1_5/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java?revision=824340&view=markup
>
> Jarek
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Sep 17, 2010 at 8:36 PM, Jarek Gawor <jg...@gmail.com> wrote:
> On Fri, Sep 17, 2010 at 7:55 AM, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >
> >>
> >> See https://issues.apache.org/jira/browse/AXIS2-4751 for details. The
> >> thread safety problem was solved by not reusing HttpClient instance.
> >
> > As I told, this bug is reported with Axis2 1.5.1 not with trunk. hence
> this
> > issue is not relevant.
> >
> > this is the original code.
> > HttpClient httpClient;
> > Object reuse =
> > msgContext.getOptions().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
> > if (reuse == null) {
> > reuse =
> >
> msgContext.getConfigurationContext().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
> > }
> >
> > if (reuse != null && JavaUtils.isTrueExplicitly(reuse)) {
> > httpClient = (HttpClient)
> > msgContext.getOptions().getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
> > if (httpClient == null) {
> > httpClient = (HttpClient)
> > msgContext.getConfigurationContext()
> > .getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
> > }
> > if (httpClient != null)
> > return httpClient;
> > MultiThreadedHttpConnectionManager connectionManager =
> > new MultiThreadedHttpConnectionManager();
> > httpClient = new HttpClient(connectionManager);
> > msgContext.getConfigurationContext()
> > .setProperty(HTTPConstants.CACHED_HTTP_CLIENT,
> > httpClient);
> > } else {
> > HttpConnectionManager connManager =
> > (HttpConnectionManager) msgContext.getProperty(
> >
> > HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
> > if (connManager == null) {
> > connManager =
> > (HttpConnectionManager) msgContext.getProperty(
> >
> > HTTPConstants.MUTTITHREAD_HTTP_CONNECTION_MANAGER);
> > }
> > if (connManager != null) {
> > httpClient = new HttpClient(connManager);
> > } else {
> > //Multi threaded http connection manager has set as the
> > default
> > connManager = new MultiThreadedHttpConnectionManager();
> > httpClient = new HttpClient(connManager);
> > }
> > }
> >
> > // Get the timeout values set in the runtime
> > initializeTimeouts(msgContext, httpClient);
> >
> > return httpClient;
> >
> > it reuses http client only if user has set so. otherwise if the user has
> set
> > an http connection manager object then
> > it creates a new httpClient per every call.
>
> This code is bad for two reasons:
>
> 1) In the first block when REUSE_HTTP_CLIENT is true, the code will
> reuse HttpClient instance. As I mentioned before, that way we use
> HttpClient instance in the code right now is not thread safe.
>
Can you please explain how one can not come up with the same argument with
the current code?
Here people reuse httpClient if they know it is thread safe.
>
> This directly relates to the key problem my original changes were
> addressing.
>
Please see here[1]. What you are talking about an issue due to the changes
done only to Axis2 1.5.1.
> 2) When REUSE_HTTP_CLIENT is not set or false and
> MULTITHREAD_HTTP_CONNECTION_MANAGER is not set, the code will create a
> new instance of MultiThreadedHttpConnectionManager and HttpClient.
> Creating a new instance of MultiThreadedHttpConnectionManager on each
> call means it is creating a new connection pool per call but the
> connection pool is not really being reused. That can lead to a lot of
> connections being open and remain open longer then needed.
>
In Axis2 1.5 there are three possible methods in which http client is used.
1. Creating one connection per invocation
2. Reusing same httpClient object per all invocations
3. Reusing same connectionManager object for all invocations.
in Axis2 1.5.1 what is has done is actually restricting this to option 2.
Hence your issue.
Then the current code has restricted it to only option 2 and 3 and make
option 3 default.
In Axis2 1.5 the default is option 1. Which has the problems you mentioned
at the high loads. For normal
loads that is not a considerable problem. For such case users has option to
move into option 2 or 3 according to
their usage.
So what we try to say making option 3 as default (and removing options 1) is
that it supports high loads by default. But it is not the case as I shown
since it creates only two connections to the back end servers.
> An attempt was made in the 1.5 branch to ensure connection pool is
> reused between the calls but that reused HttpClient instance instead
> of HttpConnectionManager instance... and you know the rest.
>
> So, please do not revert back to this version of the code.
>
Even we agree to keep only option 2 and 3 (default) I see following problems
with this patch.
1. if (httpClient == null) {
httpClient = (HttpClient)
configContext.getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
}
No need to have this code. (yes this is there with the earlier code as well)
when you check with message context it
should have return the property if it in the configuration context.
2. if (connManager == null) {
// reuse HttpConnectionManager
synchronized (configContext) {
connManager = (HttpConnectionManager)
configContext.getProperty(
HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
if (connManager == null) {
log.trace("Making new ConnectionManager");
connManager = new MultiThreadedHttpConnectionManager();
configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
connManager);
}
}
}
Instead of doing this we need to set the connection manager at the transport
initialization time. We may be creating an unnecessary connection manage if
user always reuse the httpClient. But I think it is better than having a
synchronized block.
3. // Set the default timeout in case we have a connection pool starvation
to 30sec
httpClient.getParams().setConnectionManagerTimeout(30000);
remove this and ask users to must use serviceClient.cleanupTransport() since
option 2 and 3 requires this. otherwise connections are not released and the
system hangs.
thanks,
Amila.
[1]
http://svn.apache.org/viewvc/axis/axis2/java/core/branches/1_5/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java?revision=824340&view=markup
>
> Jarek
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/
modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/
modules/kernel/src/org/apache/a
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Jarek,
On 9/17/2010 11:06 AM, Jarek Gawor wrote:
> An attempt was made in the 1.5 branch to ensure connection pool is
> reused between the calls but that reused HttpClient instance instead
> of HttpConnectionManager instance... and you know the rest.
Not to beat a dead horse :), but AFAIK Oleg still recommends using a single
HTTPClient across multiple threads. It's true that using it that way will
mean having to pass a separate HTTPState object to each execute() call, but
that's apparently the recommended pattern.
See this thread - http://bit.ly/cWlfYD
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/
modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/
modules/kernel/src/org/apache/a
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Jarek,
On 9/17/2010 11:06 AM, Jarek Gawor wrote:
> An attempt was made in the 1.5 branch to ensure connection pool is
> reused between the calls but that reused HttpClient instance instead
> of HttpConnectionManager instance... and you know the rest.
Not to beat a dead horse :), but AFAIK Oleg still recommends using a single
HTTPClient across multiple threads. It's true that using it that way will
mean having to pass a separate HTTPState object to each execute() call, but
that's apparently the recommended pattern.
See this thread - http://bit.ly/cWlfYD
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/
modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/
modules/kernel/src/org/apache/a
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Jarek,
On 9/17/2010 11:06 AM, Jarek Gawor wrote:
> An attempt was made in the 1.5 branch to ensure connection pool is
> reused between the calls but that reused HttpClient instance instead
> of HttpConnectionManager instance... and you know the rest.
Not to beat a dead horse :), but AFAIK Oleg still recommends using a single
HTTPClient across multiple threads. It's true that using it that way will
mean having to pass a separate HTTPState object to each execute() call, but
that's apparently the recommended pattern.
See this thread - http://bit.ly/cWlfYD
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Sep 17, 2010 at 8:36 PM, Jarek Gawor <jg...@gmail.com> wrote:
> On Fri, Sep 17, 2010 at 7:55 AM, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >
> >>
> >> See https://issues.apache.org/jira/browse/AXIS2-4751 for details. The
> >> thread safety problem was solved by not reusing HttpClient instance.
> >
> > As I told, this bug is reported with Axis2 1.5.1 not with trunk. hence
> this
> > issue is not relevant.
> >
> > this is the original code.
> > HttpClient httpClient;
> > Object reuse =
> > msgContext.getOptions().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
> > if (reuse == null) {
> > reuse =
> >
> msgContext.getConfigurationContext().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
> > }
> >
> > if (reuse != null && JavaUtils.isTrueExplicitly(reuse)) {
> > httpClient = (HttpClient)
> > msgContext.getOptions().getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
> > if (httpClient == null) {
> > httpClient = (HttpClient)
> > msgContext.getConfigurationContext()
> > .getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
> > }
> > if (httpClient != null)
> > return httpClient;
> > MultiThreadedHttpConnectionManager connectionManager =
> > new MultiThreadedHttpConnectionManager();
> > httpClient = new HttpClient(connectionManager);
> > msgContext.getConfigurationContext()
> > .setProperty(HTTPConstants.CACHED_HTTP_CLIENT,
> > httpClient);
> > } else {
> > HttpConnectionManager connManager =
> > (HttpConnectionManager) msgContext.getProperty(
> >
> > HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
> > if (connManager == null) {
> > connManager =
> > (HttpConnectionManager) msgContext.getProperty(
> >
> > HTTPConstants.MUTTITHREAD_HTTP_CONNECTION_MANAGER);
> > }
> > if (connManager != null) {
> > httpClient = new HttpClient(connManager);
> > } else {
> > //Multi threaded http connection manager has set as the
> > default
> > connManager = new MultiThreadedHttpConnectionManager();
> > httpClient = new HttpClient(connManager);
> > }
> > }
> >
> > // Get the timeout values set in the runtime
> > initializeTimeouts(msgContext, httpClient);
> >
> > return httpClient;
> >
> > it reuses http client only if user has set so. otherwise if the user has
> set
> > an http connection manager object then
> > it creates a new httpClient per every call.
>
> This code is bad for two reasons:
>
> 1) In the first block when REUSE_HTTP_CLIENT is true, the code will
> reuse HttpClient instance. As I mentioned before, that way we use
> HttpClient instance in the code right now is not thread safe.
>
Can you please explain how one can not come up with the same argument with
the current code?
Here people reuse httpClient if they know it is thread safe.
>
> This directly relates to the key problem my original changes were
> addressing.
>
Please see here[1]. What you are talking about an issue due to the changes
done only to Axis2 1.5.1.
> 2) When REUSE_HTTP_CLIENT is not set or false and
> MULTITHREAD_HTTP_CONNECTION_MANAGER is not set, the code will create a
> new instance of MultiThreadedHttpConnectionManager and HttpClient.
> Creating a new instance of MultiThreadedHttpConnectionManager on each
> call means it is creating a new connection pool per call but the
> connection pool is not really being reused. That can lead to a lot of
> connections being open and remain open longer then needed.
>
In Axis2 1.5 there are three possible methods in which http client is used.
1. Creating one connection per invocation
2. Reusing same httpClient object per all invocations
3. Reusing same connectionManager object for all invocations.
in Axis2 1.5.1 what is has done is actually restricting this to option 2.
Hence your issue.
Then the current code has restricted it to only option 2 and 3 and make
option 3 default.
In Axis2 1.5 the default is option 1. Which has the problems you mentioned
at the high loads. For normal
loads that is not a considerable problem. For such case users has option to
move into option 2 or 3 according to
their usage.
So what we try to say making option 3 as default (and removing options 1) is
that it supports high loads by default. But it is not the case as I shown
since it creates only two connections to the back end servers.
> An attempt was made in the 1.5 branch to ensure connection pool is
> reused between the calls but that reused HttpClient instance instead
> of HttpConnectionManager instance... and you know the rest.
>
> So, please do not revert back to this version of the code.
>
Even we agree to keep only option 2 and 3 (default) I see following problems
with this patch.
1. if (httpClient == null) {
httpClient = (HttpClient)
configContext.getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
}
No need to have this code. (yes this is there with the earlier code as well)
when you check with message context it
should have return the property if it in the configuration context.
2. if (connManager == null) {
// reuse HttpConnectionManager
synchronized (configContext) {
connManager = (HttpConnectionManager)
configContext.getProperty(
HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
if (connManager == null) {
log.trace("Making new ConnectionManager");
connManager = new MultiThreadedHttpConnectionManager();
configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
connManager);
}
}
}
Instead of doing this we need to set the connection manager at the transport
initialization time. We may be creating an unnecessary connection manage if
user always reuse the httpClient. But I think it is better than having a
synchronized block.
3. // Set the default timeout in case we have a connection pool starvation
to 30sec
httpClient.getParams().setConnectionManagerTimeout(30000);
remove this and ask users to must use serviceClient.cleanupTransport() since
option 2 and 3 requires this. otherwise connections are not released and the
system hangs.
thanks,
Amila.
[1]
http://svn.apache.org/viewvc/axis/axis2/java/core/branches/1_5/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java?revision=824340&view=markup
>
> Jarek
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Sep 17, 2010 at 8:36 PM, Jarek Gawor <jg...@gmail.com> wrote:
> On Fri, Sep 17, 2010 at 7:55 AM, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >
> >>
> >> See https://issues.apache.org/jira/browse/AXIS2-4751 for details. The
> >> thread safety problem was solved by not reusing HttpClient instance.
> >
> > As I told, this bug is reported with Axis2 1.5.1 not with trunk. hence
> this
> > issue is not relevant.
> >
> > this is the original code.
> > HttpClient httpClient;
> > Object reuse =
> > msgContext.getOptions().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
> > if (reuse == null) {
> > reuse =
> >
> msgContext.getConfigurationContext().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
> > }
> >
> > if (reuse != null && JavaUtils.isTrueExplicitly(reuse)) {
> > httpClient = (HttpClient)
> > msgContext.getOptions().getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
> > if (httpClient == null) {
> > httpClient = (HttpClient)
> > msgContext.getConfigurationContext()
> > .getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
> > }
> > if (httpClient != null)
> > return httpClient;
> > MultiThreadedHttpConnectionManager connectionManager =
> > new MultiThreadedHttpConnectionManager();
> > httpClient = new HttpClient(connectionManager);
> > msgContext.getConfigurationContext()
> > .setProperty(HTTPConstants.CACHED_HTTP_CLIENT,
> > httpClient);
> > } else {
> > HttpConnectionManager connManager =
> > (HttpConnectionManager) msgContext.getProperty(
> >
> > HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
> > if (connManager == null) {
> > connManager =
> > (HttpConnectionManager) msgContext.getProperty(
> >
> > HTTPConstants.MUTTITHREAD_HTTP_CONNECTION_MANAGER);
> > }
> > if (connManager != null) {
> > httpClient = new HttpClient(connManager);
> > } else {
> > //Multi threaded http connection manager has set as the
> > default
> > connManager = new MultiThreadedHttpConnectionManager();
> > httpClient = new HttpClient(connManager);
> > }
> > }
> >
> > // Get the timeout values set in the runtime
> > initializeTimeouts(msgContext, httpClient);
> >
> > return httpClient;
> >
> > it reuses http client only if user has set so. otherwise if the user has
> set
> > an http connection manager object then
> > it creates a new httpClient per every call.
>
> This code is bad for two reasons:
>
> 1) In the first block when REUSE_HTTP_CLIENT is true, the code will
> reuse HttpClient instance. As I mentioned before, that way we use
> HttpClient instance in the code right now is not thread safe.
>
Can you please explain how one can not come up with the same argument with
the current code?
Here people reuse httpClient if they know it is thread safe.
>
> This directly relates to the key problem my original changes were
> addressing.
>
Please see here[1]. What you are talking about an issue due to the changes
done only to Axis2 1.5.1.
> 2) When REUSE_HTTP_CLIENT is not set or false and
> MULTITHREAD_HTTP_CONNECTION_MANAGER is not set, the code will create a
> new instance of MultiThreadedHttpConnectionManager and HttpClient.
> Creating a new instance of MultiThreadedHttpConnectionManager on each
> call means it is creating a new connection pool per call but the
> connection pool is not really being reused. That can lead to a lot of
> connections being open and remain open longer then needed.
>
In Axis2 1.5 there are three possible methods in which http client is used.
1. Creating one connection per invocation
2. Reusing same httpClient object per all invocations
3. Reusing same connectionManager object for all invocations.
in Axis2 1.5.1 what is has done is actually restricting this to option 2.
Hence your issue.
Then the current code has restricted it to only option 2 and 3 and make
option 3 default.
In Axis2 1.5 the default is option 1. Which has the problems you mentioned
at the high loads. For normal
loads that is not a considerable problem. For such case users has option to
move into option 2 or 3 according to
their usage.
So what we try to say making option 3 as default (and removing options 1) is
that it supports high loads by default. But it is not the case as I shown
since it creates only two connections to the back end servers.
> An attempt was made in the 1.5 branch to ensure connection pool is
> reused between the calls but that reused HttpClient instance instead
> of HttpConnectionManager instance... and you know the rest.
>
> So, please do not revert back to this version of the code.
>
Even we agree to keep only option 2 and 3 (default) I see following problems
with this patch.
1. if (httpClient == null) {
httpClient = (HttpClient)
configContext.getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
}
No need to have this code. (yes this is there with the earlier code as well)
when you check with message context it
should have return the property if it in the configuration context.
2. if (connManager == null) {
// reuse HttpConnectionManager
synchronized (configContext) {
connManager = (HttpConnectionManager)
configContext.getProperty(
HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
if (connManager == null) {
log.trace("Making new ConnectionManager");
connManager = new MultiThreadedHttpConnectionManager();
configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
connManager);
}
}
}
Instead of doing this we need to set the connection manager at the transport
initialization time. We may be creating an unnecessary connection manage if
user always reuse the httpClient. But I think it is better than having a
synchronized block.
3. // Set the default timeout in case we have a connection pool starvation
to 30sec
httpClient.getParams().setConnectionManagerTimeout(30000);
remove this and ask users to must use serviceClient.cleanupTransport() since
option 2 and 3 requires this. otherwise connections are not released and the
system hangs.
thanks,
Amila.
[1]
http://svn.apache.org/viewvc/axis/axis2/java/core/branches/1_5/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java?revision=824340&view=markup
>
> Jarek
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Jarek Gawor <jg...@gmail.com>.
On Fri, Sep 17, 2010 at 7:55 AM, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
>>
>> See https://issues.apache.org/jira/browse/AXIS2-4751 for details. The
>> thread safety problem was solved by not reusing HttpClient instance.
>
> As I told, this bug is reported with Axis2 1.5.1 not with trunk. hence this
> issue is not relevant.
>
> this is the original code.
> HttpClient httpClient;
> Object reuse =
> msgContext.getOptions().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
> if (reuse == null) {
> reuse =
> msgContext.getConfigurationContext().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
> }
>
> if (reuse != null && JavaUtils.isTrueExplicitly(reuse)) {
> httpClient = (HttpClient)
> msgContext.getOptions().getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
> if (httpClient == null) {
> httpClient = (HttpClient)
> msgContext.getConfigurationContext()
> .getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
> }
> if (httpClient != null)
> return httpClient;
> MultiThreadedHttpConnectionManager connectionManager =
> new MultiThreadedHttpConnectionManager();
> httpClient = new HttpClient(connectionManager);
> msgContext.getConfigurationContext()
> .setProperty(HTTPConstants.CACHED_HTTP_CLIENT,
> httpClient);
> } else {
> HttpConnectionManager connManager =
> (HttpConnectionManager) msgContext.getProperty(
>
> HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
> if (connManager == null) {
> connManager =
> (HttpConnectionManager) msgContext.getProperty(
>
> HTTPConstants.MUTTITHREAD_HTTP_CONNECTION_MANAGER);
> }
> if (connManager != null) {
> httpClient = new HttpClient(connManager);
> } else {
> //Multi threaded http connection manager has set as the
> default
> connManager = new MultiThreadedHttpConnectionManager();
> httpClient = new HttpClient(connManager);
> }
> }
>
> // Get the timeout values set in the runtime
> initializeTimeouts(msgContext, httpClient);
>
> return httpClient;
>
> it reuses http client only if user has set so. otherwise if the user has set
> an http connection manager object then
> it creates a new httpClient per every call.
This code is bad for two reasons:
1) In the first block when REUSE_HTTP_CLIENT is true, the code will
reuse HttpClient instance. As I mentioned before, that way we use
HttpClient instance in the code right now is not thread safe.
This directly relates to the key problem my original changes were addressing.
2) When REUSE_HTTP_CLIENT is not set or false and
MULTITHREAD_HTTP_CONNECTION_MANAGER is not set, the code will create a
new instance of MultiThreadedHttpConnectionManager and HttpClient.
Creating a new instance of MultiThreadedHttpConnectionManager on each
call means it is creating a new connection pool per call but the
connection pool is not really being reused. That can lead to a lot of
connections being open and remain open longer then needed.
An attempt was made in the 1.5 branch to ensure connection pool is
reused between the calls but that reused HttpClient instance instead
of HttpConnectionManager instance... and you know the rest.
So, please do not revert back to this version of the code.
Jarek
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Jarek Gawor <jg...@gmail.com>.
On Fri, Sep 17, 2010 at 7:55 AM, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
>>
>> See https://issues.apache.org/jira/browse/AXIS2-4751 for details. The
>> thread safety problem was solved by not reusing HttpClient instance.
>
> As I told, this bug is reported with Axis2 1.5.1 not with trunk. hence this
> issue is not relevant.
>
> this is the original code.
> HttpClient httpClient;
> Object reuse =
> msgContext.getOptions().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
> if (reuse == null) {
> reuse =
> msgContext.getConfigurationContext().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
> }
>
> if (reuse != null && JavaUtils.isTrueExplicitly(reuse)) {
> httpClient = (HttpClient)
> msgContext.getOptions().getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
> if (httpClient == null) {
> httpClient = (HttpClient)
> msgContext.getConfigurationContext()
> .getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
> }
> if (httpClient != null)
> return httpClient;
> MultiThreadedHttpConnectionManager connectionManager =
> new MultiThreadedHttpConnectionManager();
> httpClient = new HttpClient(connectionManager);
> msgContext.getConfigurationContext()
> .setProperty(HTTPConstants.CACHED_HTTP_CLIENT,
> httpClient);
> } else {
> HttpConnectionManager connManager =
> (HttpConnectionManager) msgContext.getProperty(
>
> HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
> if (connManager == null) {
> connManager =
> (HttpConnectionManager) msgContext.getProperty(
>
> HTTPConstants.MUTTITHREAD_HTTP_CONNECTION_MANAGER);
> }
> if (connManager != null) {
> httpClient = new HttpClient(connManager);
> } else {
> //Multi threaded http connection manager has set as the
> default
> connManager = new MultiThreadedHttpConnectionManager();
> httpClient = new HttpClient(connManager);
> }
> }
>
> // Get the timeout values set in the runtime
> initializeTimeouts(msgContext, httpClient);
>
> return httpClient;
>
> it reuses http client only if user has set so. otherwise if the user has set
> an http connection manager object then
> it creates a new httpClient per every call.
This code is bad for two reasons:
1) In the first block when REUSE_HTTP_CLIENT is true, the code will
reuse HttpClient instance. As I mentioned before, that way we use
HttpClient instance in the code right now is not thread safe.
This directly relates to the key problem my original changes were addressing.
2) When REUSE_HTTP_CLIENT is not set or false and
MULTITHREAD_HTTP_CONNECTION_MANAGER is not set, the code will create a
new instance of MultiThreadedHttpConnectionManager and HttpClient.
Creating a new instance of MultiThreadedHttpConnectionManager on each
call means it is creating a new connection pool per call but the
connection pool is not really being reused. That can lead to a lot of
connections being open and remain open longer then needed.
An attempt was made in the 1.5 branch to ensure connection pool is
reused between the calls but that reused HttpClient instance instead
of HttpConnectionManager instance... and you know the rest.
So, please do not revert back to this version of the code.
Jarek
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Jarek Gawor <jg...@gmail.com>.
On Fri, Sep 17, 2010 at 7:55 AM, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
>>
>> See https://issues.apache.org/jira/browse/AXIS2-4751 for details. The
>> thread safety problem was solved by not reusing HttpClient instance.
>
> As I told, this bug is reported with Axis2 1.5.1 not with trunk. hence this
> issue is not relevant.
>
> this is the original code.
> HttpClient httpClient;
> Object reuse =
> msgContext.getOptions().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
> if (reuse == null) {
> reuse =
> msgContext.getConfigurationContext().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
> }
>
> if (reuse != null && JavaUtils.isTrueExplicitly(reuse)) {
> httpClient = (HttpClient)
> msgContext.getOptions().getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
> if (httpClient == null) {
> httpClient = (HttpClient)
> msgContext.getConfigurationContext()
> .getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
> }
> if (httpClient != null)
> return httpClient;
> MultiThreadedHttpConnectionManager connectionManager =
> new MultiThreadedHttpConnectionManager();
> httpClient = new HttpClient(connectionManager);
> msgContext.getConfigurationContext()
> .setProperty(HTTPConstants.CACHED_HTTP_CLIENT,
> httpClient);
> } else {
> HttpConnectionManager connManager =
> (HttpConnectionManager) msgContext.getProperty(
>
> HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
> if (connManager == null) {
> connManager =
> (HttpConnectionManager) msgContext.getProperty(
>
> HTTPConstants.MUTTITHREAD_HTTP_CONNECTION_MANAGER);
> }
> if (connManager != null) {
> httpClient = new HttpClient(connManager);
> } else {
> //Multi threaded http connection manager has set as the
> default
> connManager = new MultiThreadedHttpConnectionManager();
> httpClient = new HttpClient(connManager);
> }
> }
>
> // Get the timeout values set in the runtime
> initializeTimeouts(msgContext, httpClient);
>
> return httpClient;
>
> it reuses http client only if user has set so. otherwise if the user has set
> an http connection manager object then
> it creates a new httpClient per every call.
This code is bad for two reasons:
1) In the first block when REUSE_HTTP_CLIENT is true, the code will
reuse HttpClient instance. As I mentioned before, that way we use
HttpClient instance in the code right now is not thread safe.
This directly relates to the key problem my original changes were addressing.
2) When REUSE_HTTP_CLIENT is not set or false and
MULTITHREAD_HTTP_CONNECTION_MANAGER is not set, the code will create a
new instance of MultiThreadedHttpConnectionManager and HttpClient.
Creating a new instance of MultiThreadedHttpConnectionManager on each
call means it is creating a new connection pool per call but the
connection pool is not really being reused. That can lead to a lot of
connections being open and remain open longer then needed.
An attempt was made in the 1.5 branch to ensure connection pool is
reused between the calls but that reused HttpClient instance instead
of HttpConnectionManager instance... and you know the rest.
So, please do not revert back to this version of the code.
Jarek
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/
modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/
modules/kernel/src/org/apache/a
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Amila, Jarek,
On 9/17/2010 7:55 AM, Amila Suriarachchi wrote:
> As I told, this bug is reported with Axis2 1.5.1 not with trunk. hence this
> issue is not relevant.
The issue isn't just 4751, Amila - the larger issues were 935, 2883, and
others (search for CLOSE_WAIT). When we used the old (pre-1.5.1) methods of
connection management, there was a significant problem with memory leakage
and connection starvation, even if options.setCallTransportCleanup() had been
called. The following code would die after about 3600 repetitions on
Windows, some other number on linux:
ServiceClient client = new ServiceClient();
Options options = new Options();
// options.setCallTransportCleanup(true); // Doesn't matter
options.setTo(new
EndpointReference("http://localhost:8080/axis2/services/Version"));
options.setAction("urn:getVersion");
client.setOptions(options);
SOAPFactory fac = OMAbstractFactory.getSOAP11Factory();
String NS = "http://ws.apache.org/axis2";
OMElement req = fac.createOMElement(new QName(NS, "getVersion"));
for (int i = 0; i < 10000; i++) {
client.sendReceive(req);
System.out.println(i);
}
System.out.println("All done.");
The above will happily chug along forever with 1.5.1 and 1.5.2.
> this is the original code.
> [...]
> it reuses http client only if user has set so. otherwise if the user has set
> an http connection manager object then
> it creates a new httpClient per every call.
>
> I'll revert this change since issue you point out is not applicable here.
Please don't do any further reverting. I'd suggest as Jarek did that we
start another thread re: connection sharing. I think the right answer is to
always use connection sharing and if you need more than 2 concurrent
connections to a given host you should just configure the
HttpConnectionManagerParams.
IMHO for 1.6 we need to:
* Make sure sessions / cookies work as expected
* Move to HTTPClient 4.0
* Make sure we have a test suite that covers all the potential breakages,
including the test above
Thanks,
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/
modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/
modules/kernel/src/org/apache/a
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Amila, Jarek,
On 9/17/2010 7:55 AM, Amila Suriarachchi wrote:
> As I told, this bug is reported with Axis2 1.5.1 not with trunk. hence this
> issue is not relevant.
The issue isn't just 4751, Amila - the larger issues were 935, 2883, and
others (search for CLOSE_WAIT). When we used the old (pre-1.5.1) methods of
connection management, there was a significant problem with memory leakage
and connection starvation, even if options.setCallTransportCleanup() had been
called. The following code would die after about 3600 repetitions on
Windows, some other number on linux:
ServiceClient client = new ServiceClient();
Options options = new Options();
// options.setCallTransportCleanup(true); // Doesn't matter
options.setTo(new
EndpointReference("http://localhost:8080/axis2/services/Version"));
options.setAction("urn:getVersion");
client.setOptions(options);
SOAPFactory fac = OMAbstractFactory.getSOAP11Factory();
String NS = "http://ws.apache.org/axis2";
OMElement req = fac.createOMElement(new QName(NS, "getVersion"));
for (int i = 0; i < 10000; i++) {
client.sendReceive(req);
System.out.println(i);
}
System.out.println("All done.");
The above will happily chug along forever with 1.5.1 and 1.5.2.
> this is the original code.
> [...]
> it reuses http client only if user has set so. otherwise if the user has set
> an http connection manager object then
> it creates a new httpClient per every call.
>
> I'll revert this change since issue you point out is not applicable here.
Please don't do any further reverting. I'd suggest as Jarek did that we
start another thread re: connection sharing. I think the right answer is to
always use connection sharing and if you need more than 2 concurrent
connections to a given host you should just configure the
HttpConnectionManagerParams.
IMHO for 1.6 we need to:
* Make sure sessions / cookies work as expected
* Move to HTTPClient 4.0
* Make sure we have a test suite that covers all the potential breakages,
including the test above
Thanks,
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/
modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/
modules/kernel/src/org/apache/a
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Amila, Jarek,
On 9/17/2010 7:55 AM, Amila Suriarachchi wrote:
> As I told, this bug is reported with Axis2 1.5.1 not with trunk. hence this
> issue is not relevant.
The issue isn't just 4751, Amila - the larger issues were 935, 2883, and
others (search for CLOSE_WAIT). When we used the old (pre-1.5.1) methods of
connection management, there was a significant problem with memory leakage
and connection starvation, even if options.setCallTransportCleanup() had been
called. The following code would die after about 3600 repetitions on
Windows, some other number on linux:
ServiceClient client = new ServiceClient();
Options options = new Options();
// options.setCallTransportCleanup(true); // Doesn't matter
options.setTo(new
EndpointReference("http://localhost:8080/axis2/services/Version"));
options.setAction("urn:getVersion");
client.setOptions(options);
SOAPFactory fac = OMAbstractFactory.getSOAP11Factory();
String NS = "http://ws.apache.org/axis2";
OMElement req = fac.createOMElement(new QName(NS, "getVersion"));
for (int i = 0; i < 10000; i++) {
client.sendReceive(req);
System.out.println(i);
}
System.out.println("All done.");
The above will happily chug along forever with 1.5.1 and 1.5.2.
> this is the original code.
> [...]
> it reuses http client only if user has set so. otherwise if the user has set
> an http connection manager object then
> it creates a new httpClient per every call.
>
> I'll revert this change since issue you point out is not applicable here.
Please don't do any further reverting. I'd suggest as Jarek did that we
start another thread re: connection sharing. I think the right answer is to
always use connection sharing and if you need more than 2 concurrent
connections to a given host you should just configure the
HttpConnectionManagerParams.
IMHO for 1.6 we need to:
* Make sure sessions / cookies work as expected
* Move to HTTPClient 4.0
* Make sure we have a test suite that covers all the potential breakages,
including the test above
Thanks,
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Jarek Gawor <jg...@gmail.com>.
On Fri, Sep 17, 2010 at 7:55 AM, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
>>
>> See https://issues.apache.org/jira/browse/AXIS2-4751 for details. The
>> thread safety problem was solved by not reusing HttpClient instance.
>
> As I told, this bug is reported with Axis2 1.5.1 not with trunk. hence this
> issue is not relevant.
>
> this is the original code.
> HttpClient httpClient;
> Object reuse =
> msgContext.getOptions().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
> if (reuse == null) {
> reuse =
> msgContext.getConfigurationContext().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
> }
>
> if (reuse != null && JavaUtils.isTrueExplicitly(reuse)) {
> httpClient = (HttpClient)
> msgContext.getOptions().getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
> if (httpClient == null) {
> httpClient = (HttpClient)
> msgContext.getConfigurationContext()
> .getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
> }
> if (httpClient != null)
> return httpClient;
> MultiThreadedHttpConnectionManager connectionManager =
> new MultiThreadedHttpConnectionManager();
> httpClient = new HttpClient(connectionManager);
> msgContext.getConfigurationContext()
> .setProperty(HTTPConstants.CACHED_HTTP_CLIENT,
> httpClient);
> } else {
> HttpConnectionManager connManager =
> (HttpConnectionManager) msgContext.getProperty(
>
> HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
> if (connManager == null) {
> connManager =
> (HttpConnectionManager) msgContext.getProperty(
>
> HTTPConstants.MUTTITHREAD_HTTP_CONNECTION_MANAGER);
> }
> if (connManager != null) {
> httpClient = new HttpClient(connManager);
> } else {
> //Multi threaded http connection manager has set as the
> default
> connManager = new MultiThreadedHttpConnectionManager();
> httpClient = new HttpClient(connManager);
> }
> }
>
> // Get the timeout values set in the runtime
> initializeTimeouts(msgContext, httpClient);
>
> return httpClient;
>
> it reuses http client only if user has set so. otherwise if the user has set
> an http connection manager object then
> it creates a new httpClient per every call.
This code is bad for two reasons:
1) In the first block when REUSE_HTTP_CLIENT is true, the code will
reuse HttpClient instance. As I mentioned before, that way we use
HttpClient instance in the code right now is not thread safe.
This directly relates to the key problem my original changes were addressing.
2) When REUSE_HTTP_CLIENT is not set or false and
MULTITHREAD_HTTP_CONNECTION_MANAGER is not set, the code will create a
new instance of MultiThreadedHttpConnectionManager and HttpClient.
Creating a new instance of MultiThreadedHttpConnectionManager on each
call means it is creating a new connection pool per call but the
connection pool is not really being reused. That can lead to a lot of
connections being open and remain open longer then needed.
An attempt was made in the 1.5 branch to ensure connection pool is
reused between the calls but that reused HttpClient instance instead
of HttpConnectionManager instance... and you know the rest.
So, please do not revert back to this version of the code.
Jarek
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/
modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/
modules/kernel/src/org/apache/a
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Amila, Jarek,
On 9/17/2010 7:55 AM, Amila Suriarachchi wrote:
> As I told, this bug is reported with Axis2 1.5.1 not with trunk. hence this
> issue is not relevant.
The issue isn't just 4751, Amila - the larger issues were 935, 2883, and
others (search for CLOSE_WAIT). When we used the old (pre-1.5.1) methods of
connection management, there was a significant problem with memory leakage
and connection starvation, even if options.setCallTransportCleanup() had been
called. The following code would die after about 3600 repetitions on
Windows, some other number on linux:
ServiceClient client = new ServiceClient();
Options options = new Options();
// options.setCallTransportCleanup(true); // Doesn't matter
options.setTo(new
EndpointReference("http://localhost:8080/axis2/services/Version"));
options.setAction("urn:getVersion");
client.setOptions(options);
SOAPFactory fac = OMAbstractFactory.getSOAP11Factory();
String NS = "http://ws.apache.org/axis2";
OMElement req = fac.createOMElement(new QName(NS, "getVersion"));
for (int i = 0; i < 10000; i++) {
client.sendReceive(req);
System.out.println(i);
}
System.out.println("All done.");
The above will happily chug along forever with 1.5.1 and 1.5.2.
> this is the original code.
> [...]
> it reuses http client only if user has set so. otherwise if the user has set
> an http connection manager object then
> it creates a new httpClient per every call.
>
> I'll revert this change since issue you point out is not applicable here.
Please don't do any further reverting. I'd suggest as Jarek did that we
start another thread re: connection sharing. I think the right answer is to
always use connection sharing and if you need more than 2 concurrent
connections to a given host you should just configure the
HttpConnectionManagerParams.
IMHO for 1.6 we need to:
* Make sure sessions / cookies work as expected
* Move to HTTPClient 4.0
* Make sure we have a test suite that covers all the potential breakages,
including the test above
Thanks,
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Jarek Gawor <jg...@gmail.com>.
On Fri, Sep 17, 2010 at 7:55 AM, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>
>>
>> See https://issues.apache.org/jira/browse/AXIS2-4751 for details. The
>> thread safety problem was solved by not reusing HttpClient instance.
>
> As I told, this bug is reported with Axis2 1.5.1 not with trunk. hence this
> issue is not relevant.
>
> this is the original code.
> HttpClient httpClient;
> Object reuse =
> msgContext.getOptions().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
> if (reuse == null) {
> reuse =
> msgContext.getConfigurationContext().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
> }
>
> if (reuse != null && JavaUtils.isTrueExplicitly(reuse)) {
> httpClient = (HttpClient)
> msgContext.getOptions().getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
> if (httpClient == null) {
> httpClient = (HttpClient)
> msgContext.getConfigurationContext()
> .getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
> }
> if (httpClient != null)
> return httpClient;
> MultiThreadedHttpConnectionManager connectionManager =
> new MultiThreadedHttpConnectionManager();
> httpClient = new HttpClient(connectionManager);
> msgContext.getConfigurationContext()
> .setProperty(HTTPConstants.CACHED_HTTP_CLIENT,
> httpClient);
> } else {
> HttpConnectionManager connManager =
> (HttpConnectionManager) msgContext.getProperty(
>
> HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
> if (connManager == null) {
> connManager =
> (HttpConnectionManager) msgContext.getProperty(
>
> HTTPConstants.MUTTITHREAD_HTTP_CONNECTION_MANAGER);
> }
> if (connManager != null) {
> httpClient = new HttpClient(connManager);
> } else {
> //Multi threaded http connection manager has set as the
> default
> connManager = new MultiThreadedHttpConnectionManager();
> httpClient = new HttpClient(connManager);
> }
> }
>
> // Get the timeout values set in the runtime
> initializeTimeouts(msgContext, httpClient);
>
> return httpClient;
>
> it reuses http client only if user has set so. otherwise if the user has set
> an http connection manager object then
> it creates a new httpClient per every call.
This code is bad for two reasons:
1) In the first block when REUSE_HTTP_CLIENT is true, the code will
reuse HttpClient instance. As I mentioned before, that way we use
HttpClient instance in the code right now is not thread safe.
This directly relates to the key problem my original changes were addressing.
2) When REUSE_HTTP_CLIENT is not set or false and
MULTITHREAD_HTTP_CONNECTION_MANAGER is not set, the code will create a
new instance of MultiThreadedHttpConnectionManager and HttpClient.
Creating a new instance of MultiThreadedHttpConnectionManager on each
call means it is creating a new connection pool per call but the
connection pool is not really being reused. That can lead to a lot of
connections being open and remain open longer then needed.
An attempt was made in the 1.5 branch to ensure connection pool is
reused between the calls but that reused HttpClient instance instead
of HttpConnectionManager instance... and you know the rest.
So, please do not revert back to this version of the code.
Jarek
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Sep 17, 2010 at 10:41 AM, Jarek Gawor <jg...@gmail.com> wrote:
> On Thu, Sep 16, 2010 at 3:47 AM, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >> The key idea of these changes were to ensure that connection reuse is
> >> done properly (in thread safe way).
> >
> > Can you please explain this problem with the code with revision 909680.
> >
> > After that you have commit twice and Andreas has revert them and merge
> with
> > Axis2 1.5.
> >
> > if there is a thread safe problem then we need to fix that. But what I am
> > saying is that
> > we should not do any other change unless it solves every thing out of the
> > box.
>
> See https://issues.apache.org/jira/browse/AXIS2-4751 for details. The
> thread safety problem was solved by not reusing HttpClient instance.
>
As I told, this bug is reported with Axis2 1.5.1 not with trunk. hence this
issue is not relevant.
this is the original code.
HttpClient httpClient;
Object reuse =
msgContext.getOptions().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
if (reuse == null) {
reuse =
msgContext.getConfigurationContext().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
}
if (reuse != null && JavaUtils.isTrueExplicitly(reuse)) {
httpClient = (HttpClient)
msgContext.getOptions().getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
if (httpClient == null) {
httpClient = (HttpClient)
msgContext.getConfigurationContext()
.getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
}
if (httpClient != null)
return httpClient;
MultiThreadedHttpConnectionManager connectionManager =
new MultiThreadedHttpConnectionManager();
httpClient = new HttpClient(connectionManager);
msgContext.getConfigurationContext()
.setProperty(HTTPConstants.CACHED_HTTP_CLIENT,
httpClient);
} else {
HttpConnectionManager connManager =
(HttpConnectionManager) msgContext.getProperty(
HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
if (connManager == null) {
connManager =
(HttpConnectionManager) msgContext.getProperty(
HTTPConstants.MUTTITHREAD_HTTP_CONNECTION_MANAGER);
}
if (connManager != null) {
httpClient = new HttpClient(connManager);
} else {
//Multi threaded http connection manager has set as the
default
connManager = new MultiThreadedHttpConnectionManager();
httpClient = new HttpClient(connManager);
}
}
// Get the timeout values set in the runtime
initializeTimeouts(msgContext, httpClient);
return httpClient;
it reuses http client only if user has set so. otherwise if the user has set
an http connection manager object then
it creates a new httpClient per every call.
I'll revert this change since issue you point out is not applicable here.
thanks,
Amila.
>
> >> 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.
> >
> > I think the reason is that there was not proper discussion on axis2-dev
> list
> > about this change and the
> > side effects it introduces.
>
> Start a new thread and let's discuss if connection caching should be
> done by default or not.
>
> Jarek
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Sep 17, 2010 at 10:41 AM, Jarek Gawor <jg...@gmail.com> wrote:
> On Thu, Sep 16, 2010 at 3:47 AM, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >> The key idea of these changes were to ensure that connection reuse is
> >> done properly (in thread safe way).
> >
> > Can you please explain this problem with the code with revision 909680.
> >
> > After that you have commit twice and Andreas has revert them and merge
> with
> > Axis2 1.5.
> >
> > if there is a thread safe problem then we need to fix that. But what I am
> > saying is that
> > we should not do any other change unless it solves every thing out of the
> > box.
>
> See https://issues.apache.org/jira/browse/AXIS2-4751 for details. The
> thread safety problem was solved by not reusing HttpClient instance.
>
As I told, this bug is reported with Axis2 1.5.1 not with trunk. hence this
issue is not relevant.
this is the original code.
HttpClient httpClient;
Object reuse =
msgContext.getOptions().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
if (reuse == null) {
reuse =
msgContext.getConfigurationContext().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
}
if (reuse != null && JavaUtils.isTrueExplicitly(reuse)) {
httpClient = (HttpClient)
msgContext.getOptions().getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
if (httpClient == null) {
httpClient = (HttpClient)
msgContext.getConfigurationContext()
.getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
}
if (httpClient != null)
return httpClient;
MultiThreadedHttpConnectionManager connectionManager =
new MultiThreadedHttpConnectionManager();
httpClient = new HttpClient(connectionManager);
msgContext.getConfigurationContext()
.setProperty(HTTPConstants.CACHED_HTTP_CLIENT,
httpClient);
} else {
HttpConnectionManager connManager =
(HttpConnectionManager) msgContext.getProperty(
HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
if (connManager == null) {
connManager =
(HttpConnectionManager) msgContext.getProperty(
HTTPConstants.MUTTITHREAD_HTTP_CONNECTION_MANAGER);
}
if (connManager != null) {
httpClient = new HttpClient(connManager);
} else {
//Multi threaded http connection manager has set as the
default
connManager = new MultiThreadedHttpConnectionManager();
httpClient = new HttpClient(connManager);
}
}
// Get the timeout values set in the runtime
initializeTimeouts(msgContext, httpClient);
return httpClient;
it reuses http client only if user has set so. otherwise if the user has set
an http connection manager object then
it creates a new httpClient per every call.
I'll revert this change since issue you point out is not applicable here.
thanks,
Amila.
>
> >> 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.
> >
> > I think the reason is that there was not proper discussion on axis2-dev
> list
> > about this change and the
> > side effects it introduces.
>
> Start a new thread and let's discuss if connection caching should be
> done by default or not.
>
> Jarek
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Sep 17, 2010 at 10:41 AM, Jarek Gawor <jg...@gmail.com> wrote:
> On Thu, Sep 16, 2010 at 3:47 AM, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >> The key idea of these changes were to ensure that connection reuse is
> >> done properly (in thread safe way).
> >
> > Can you please explain this problem with the code with revision 909680.
> >
> > After that you have commit twice and Andreas has revert them and merge
> with
> > Axis2 1.5.
> >
> > if there is a thread safe problem then we need to fix that. But what I am
> > saying is that
> > we should not do any other change unless it solves every thing out of the
> > box.
>
> See https://issues.apache.org/jira/browse/AXIS2-4751 for details. The
> thread safety problem was solved by not reusing HttpClient instance.
>
As I told, this bug is reported with Axis2 1.5.1 not with trunk. hence this
issue is not relevant.
this is the original code.
HttpClient httpClient;
Object reuse =
msgContext.getOptions().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
if (reuse == null) {
reuse =
msgContext.getConfigurationContext().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
}
if (reuse != null && JavaUtils.isTrueExplicitly(reuse)) {
httpClient = (HttpClient)
msgContext.getOptions().getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
if (httpClient == null) {
httpClient = (HttpClient)
msgContext.getConfigurationContext()
.getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
}
if (httpClient != null)
return httpClient;
MultiThreadedHttpConnectionManager connectionManager =
new MultiThreadedHttpConnectionManager();
httpClient = new HttpClient(connectionManager);
msgContext.getConfigurationContext()
.setProperty(HTTPConstants.CACHED_HTTP_CLIENT,
httpClient);
} else {
HttpConnectionManager connManager =
(HttpConnectionManager) msgContext.getProperty(
HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
if (connManager == null) {
connManager =
(HttpConnectionManager) msgContext.getProperty(
HTTPConstants.MUTTITHREAD_HTTP_CONNECTION_MANAGER);
}
if (connManager != null) {
httpClient = new HttpClient(connManager);
} else {
//Multi threaded http connection manager has set as the
default
connManager = new MultiThreadedHttpConnectionManager();
httpClient = new HttpClient(connManager);
}
}
// Get the timeout values set in the runtime
initializeTimeouts(msgContext, httpClient);
return httpClient;
it reuses http client only if user has set so. otherwise if the user has set
an http connection manager object then
it creates a new httpClient per every call.
I'll revert this change since issue you point out is not applicable here.
thanks,
Amila.
>
> >> 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.
> >
> > I think the reason is that there was not proper discussion on axis2-dev
> list
> > about this change and the
> > side effects it introduces.
>
> Start a new thread and let's discuss if connection caching should be
> done by default or not.
>
> Jarek
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Sep 17, 2010 at 10:41 AM, Jarek Gawor <jg...@gmail.com> wrote:
> On Thu, Sep 16, 2010 at 3:47 AM, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >> The key idea of these changes were to ensure that connection reuse is
> >> done properly (in thread safe way).
> >
> > Can you please explain this problem with the code with revision 909680.
> >
> > After that you have commit twice and Andreas has revert them and merge
> with
> > Axis2 1.5.
> >
> > if there is a thread safe problem then we need to fix that. But what I am
> > saying is that
> > we should not do any other change unless it solves every thing out of the
> > box.
>
> See https://issues.apache.org/jira/browse/AXIS2-4751 for details. The
> thread safety problem was solved by not reusing HttpClient instance.
>
As I told, this bug is reported with Axis2 1.5.1 not with trunk. hence this
issue is not relevant.
this is the original code.
HttpClient httpClient;
Object reuse =
msgContext.getOptions().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
if (reuse == null) {
reuse =
msgContext.getConfigurationContext().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
}
if (reuse != null && JavaUtils.isTrueExplicitly(reuse)) {
httpClient = (HttpClient)
msgContext.getOptions().getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
if (httpClient == null) {
httpClient = (HttpClient)
msgContext.getConfigurationContext()
.getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
}
if (httpClient != null)
return httpClient;
MultiThreadedHttpConnectionManager connectionManager =
new MultiThreadedHttpConnectionManager();
httpClient = new HttpClient(connectionManager);
msgContext.getConfigurationContext()
.setProperty(HTTPConstants.CACHED_HTTP_CLIENT,
httpClient);
} else {
HttpConnectionManager connManager =
(HttpConnectionManager) msgContext.getProperty(
HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
if (connManager == null) {
connManager =
(HttpConnectionManager) msgContext.getProperty(
HTTPConstants.MUTTITHREAD_HTTP_CONNECTION_MANAGER);
}
if (connManager != null) {
httpClient = new HttpClient(connManager);
} else {
//Multi threaded http connection manager has set as the
default
connManager = new MultiThreadedHttpConnectionManager();
httpClient = new HttpClient(connManager);
}
}
// Get the timeout values set in the runtime
initializeTimeouts(msgContext, httpClient);
return httpClient;
it reuses http client only if user has set so. otherwise if the user has set
an http connection manager object then
it creates a new httpClient per every call.
I'll revert this change since issue you point out is not applicable here.
thanks,
Amila.
>
> >> 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.
> >
> > I think the reason is that there was not proper discussion on axis2-dev
> list
> > about this change and the
> > side effects it introduces.
>
> Start a new thread and let's discuss if connection caching should be
> done by default or not.
>
> Jarek
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Amila Suriarachchi <am...@gmail.com>.
On Fri, Sep 17, 2010 at 10:41 AM, Jarek Gawor <jg...@gmail.com> wrote:
> On Thu, Sep 16, 2010 at 3:47 AM, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >> The key idea of these changes were to ensure that connection reuse is
> >> done properly (in thread safe way).
> >
> > Can you please explain this problem with the code with revision 909680.
> >
> > After that you have commit twice and Andreas has revert them and merge
> with
> > Axis2 1.5.
> >
> > if there is a thread safe problem then we need to fix that. But what I am
> > saying is that
> > we should not do any other change unless it solves every thing out of the
> > box.
>
> See https://issues.apache.org/jira/browse/AXIS2-4751 for details. The
> thread safety problem was solved by not reusing HttpClient instance.
>
As I told, this bug is reported with Axis2 1.5.1 not with trunk. hence this
issue is not relevant.
this is the original code.
HttpClient httpClient;
Object reuse =
msgContext.getOptions().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
if (reuse == null) {
reuse =
msgContext.getConfigurationContext().getProperty(HTTPConstants.REUSE_HTTP_CLIENT);
}
if (reuse != null && JavaUtils.isTrueExplicitly(reuse)) {
httpClient = (HttpClient)
msgContext.getOptions().getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
if (httpClient == null) {
httpClient = (HttpClient)
msgContext.getConfigurationContext()
.getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
}
if (httpClient != null)
return httpClient;
MultiThreadedHttpConnectionManager connectionManager =
new MultiThreadedHttpConnectionManager();
httpClient = new HttpClient(connectionManager);
msgContext.getConfigurationContext()
.setProperty(HTTPConstants.CACHED_HTTP_CLIENT,
httpClient);
} else {
HttpConnectionManager connManager =
(HttpConnectionManager) msgContext.getProperty(
HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
if (connManager == null) {
connManager =
(HttpConnectionManager) msgContext.getProperty(
HTTPConstants.MUTTITHREAD_HTTP_CONNECTION_MANAGER);
}
if (connManager != null) {
httpClient = new HttpClient(connManager);
} else {
//Multi threaded http connection manager has set as the
default
connManager = new MultiThreadedHttpConnectionManager();
httpClient = new HttpClient(connManager);
}
}
// Get the timeout values set in the runtime
initializeTimeouts(msgContext, httpClient);
return httpClient;
it reuses http client only if user has set so. otherwise if the user has set
an http connection manager object then
it creates a new httpClient per every call.
I'll revert this change since issue you point out is not applicable here.
thanks,
Amila.
>
> >> 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.
> >
> > I think the reason is that there was not proper discussion on axis2-dev
> list
> > about this change and the
> > side effects it introduces.
>
> Start a new thread and let's discuss if connection caching should be
> done by default or not.
>
> Jarek
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Jarek Gawor <jg...@gmail.com>.
On Thu, Sep 16, 2010 at 3:47 AM, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>> The key idea of these changes were to ensure that connection reuse is
>> done properly (in thread safe way).
>
> Can you please explain this problem with the code with revision 909680.
>
> After that you have commit twice and Andreas has revert them and merge with
> Axis2 1.5.
>
> if there is a thread safe problem then we need to fix that. But what I am
> saying is that
> we should not do any other change unless it solves every thing out of the
> box.
See https://issues.apache.org/jira/browse/AXIS2-4751 for details. The
thread safety problem was solved by not reusing HttpClient instance.
>> 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.
>
> I think the reason is that there was not proper discussion on axis2-dev list
> about this change and the
> side effects it introduces.
Start a new thread and let's discuss if connection caching should be
done by default or not.
Jarek
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Jarek Gawor <jg...@gmail.com>.
On Thu, Sep 16, 2010 at 3:47 AM, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>> The key idea of these changes were to ensure that connection reuse is
>> done properly (in thread safe way).
>
> Can you please explain this problem with the code with revision 909680.
>
> After that you have commit twice and Andreas has revert them and merge with
> Axis2 1.5.
>
> if there is a thread safe problem then we need to fix that. But what I am
> saying is that
> we should not do any other change unless it solves every thing out of the
> box.
See https://issues.apache.org/jira/browse/AXIS2-4751 for details. The
thread safety problem was solved by not reusing HttpClient instance.
>> 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.
>
> I think the reason is that there was not proper discussion on axis2-dev list
> about this change and the
> side effects it introduces.
Start a new thread and let's discuss if connection caching should be
done by default or not.
Jarek
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Jarek Gawor <jg...@gmail.com>.
On Thu, Sep 16, 2010 at 3:47 AM, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>> The key idea of these changes were to ensure that connection reuse is
>> done properly (in thread safe way).
>
> Can you please explain this problem with the code with revision 909680.
>
> After that you have commit twice and Andreas has revert them and merge with
> Axis2 1.5.
>
> if there is a thread safe problem then we need to fix that. But what I am
> saying is that
> we should not do any other change unless it solves every thing out of the
> box.
See https://issues.apache.org/jira/browse/AXIS2-4751 for details. The
thread safety problem was solved by not reusing HttpClient instance.
>> 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.
>
> I think the reason is that there was not proper discussion on axis2-dev list
> about this change and the
> side effects it introduces.
Start a new thread and let's discuss if connection caching should be
done by default or not.
Jarek
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Jarek Gawor <jg...@gmail.com>.
On Thu, Sep 16, 2010 at 3:47 AM, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>> The key idea of these changes were to ensure that connection reuse is
>> done properly (in thread safe way).
>
> Can you please explain this problem with the code with revision 909680.
>
> After that you have commit twice and Andreas has revert them and merge with
> Axis2 1.5.
>
> if there is a thread safe problem then we need to fix that. But what I am
> saying is that
> we should not do any other change unless it solves every thing out of the
> box.
See https://issues.apache.org/jira/browse/AXIS2-4751 for details. The
thread safety problem was solved by not reusing HttpClient instance.
>> 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.
>
> I think the reason is that there was not proper discussion on axis2-dev list
> about this change and the
> side effects it introduces.
Start a new thread and let's discuss if connection caching should be
done by default or not.
Jarek
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Jarek Gawor <jg...@gmail.com>.
On Thu, Sep 16, 2010 at 3:47 AM, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>> The key idea of these changes were to ensure that connection reuse is
>> done properly (in thread safe way).
>
> Can you please explain this problem with the code with revision 909680.
>
> After that you have commit twice and Andreas has revert them and merge with
> Axis2 1.5.
>
> if there is a thread safe problem then we need to fix that. But what I am
> saying is that
> we should not do any other change unless it solves every thing out of the
> box.
See https://issues.apache.org/jira/browse/AXIS2-4751 for details. The
thread safety problem was solved by not reusing HttpClient instance.
>> 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.
>
> I think the reason is that there was not proper discussion on axis2-dev list
> about this change and the
> side effects it introduces.
Start a new thread and let's discuss if connection caching should be
done by default or not.
Jarek
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Amila Suriarachchi <am...@gmail.com>.
On Thu, Sep 16, 2010 at 11:17 AM, Jarek Gawor <jg...@gmail.com> wrote:
> On Thu, Sep 16, 2010 at 12:51 AM, Amila Suriarachchi
> <am...@gmail.com> 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).
Can you please explain this problem with the code with revision 909680.
After that you have commit twice and Andreas has revert them and merge with
Axis2 1.5.
if there is a thread safe problem then we need to fix that. But what I am
saying is that
we should not do any other change unless it solves every thing out of the
box.
> 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.
I think the reason is that there was not proper discussion on axis2-dev list
about this change and the
side effects it introduces.
thanks,
Amila
> 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: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Amila Suriarachchi <am...@gmail.com>.
On Thu, Sep 16, 2010 at 11:17 AM, Jarek Gawor <jg...@gmail.com> wrote:
> On Thu, Sep 16, 2010 at 12:51 AM, Amila Suriarachchi
> <am...@gmail.com> 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).
Can you please explain this problem with the code with revision 909680.
After that you have commit twice and Andreas has revert them and merge with
Axis2 1.5.
if there is a thread safe problem then we need to fix that. But what I am
saying is that
we should not do any other change unless it solves every thing out of the
box.
> 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.
I think the reason is that there was not proper discussion on axis2-dev list
about this change and the
side effects it introduces.
thanks,
Amila
> 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: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Amila Suriarachchi <am...@gmail.com>.
On Thu, Sep 16, 2010 at 11:17 AM, Jarek Gawor <jg...@gmail.com> wrote:
> On Thu, Sep 16, 2010 at 12:51 AM, Amila Suriarachchi
> <am...@gmail.com> 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).
Can you please explain this problem with the code with revision 909680.
After that you have commit twice and Andreas has revert them and merge with
Axis2 1.5.
if there is a thread safe problem then we need to fix that. But what I am
saying is that
we should not do any other change unless it solves every thing out of the
box.
> 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.
I think the reason is that there was not proper discussion on axis2-dev list
about this change and the
side effects it introduces.
thanks,
Amila
> 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: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Amila Suriarachchi <am...@gmail.com>.
On Thu, Sep 16, 2010 at 11:17 AM, Jarek Gawor <jg...@gmail.com> wrote:
> On Thu, Sep 16, 2010 at 12:51 AM, Amila Suriarachchi
> <am...@gmail.com> 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).
Can you please explain this problem with the code with revision 909680.
After that you have commit twice and Andreas has revert them and merge with
Axis2 1.5.
if there is a thread safe problem then we need to fix that. But what I am
saying is that
we should not do any other change unless it solves every thing out of the
box.
> 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.
I think the reason is that there was not proper discussion on axis2-dev list
about this change and the
side effects it introduces.
thanks,
Amila
> 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: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Amila Suriarachchi <am...@gmail.com>.
On Thu, Sep 16, 2010 at 11:17 AM, Jarek Gawor <jg...@gmail.com> wrote:
> On Thu, Sep 16, 2010 at 12:51 AM, Amila Suriarachchi
> <am...@gmail.com> 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).
Can you please explain this problem with the code with revision 909680.
After that you have commit twice and Andreas has revert them and merge with
Axis2 1.5.
if there is a thread safe problem then we need to fix that. But what I am
saying is that
we should not do any other change unless it solves every thing out of the
box.
> 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.
I think the reason is that there was not proper discussion on axis2-dev list
about this change and the
side effects it introduces.
thanks,
Amila
> 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: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Jarek Gawor <jg...@gmail.com>.
On Thu, Sep 16, 2010 at 12:51 AM, Amila Suriarachchi
<am...@gmail.com> 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Jarek Gawor <jg...@gmail.com>.
On Thu, Sep 16, 2010 at 12:51 AM, Amila Suriarachchi
<am...@gmail.com> 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Jarek Gawor <jg...@gmail.com>.
On Thu, Sep 16, 2010 at 12:51 AM, Amila Suriarachchi
<am...@gmail.com> 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Jarek Gawor <jg...@gmail.com>.
On Thu, Sep 16, 2010 at 12:51 AM, Amila Suriarachchi
<am...@gmail.com> 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Jarek Gawor <jg...@gmail.com>.
On Thu, Sep 16, 2010 at 12:51 AM, Amila Suriarachchi
<am...@gmail.com> 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Amila Suriarachchi <am...@gmail.com>.
On Wed, Sep 15, 2010 at 9:56 PM, Jarek Gawor <jg...@gmail.com> wrote:
> On Wed, Sep 15, 2010 at 7:57 AM, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >> Modified:
> >>
> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
> >> URL:
> >>
> http://svn.apache.org/viewvc/axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java?rev=992877&r1=992876&r2=992877&view=diff
> >>
> >>
> ==============================================================================
> >> ---
> >>
> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
> >> (original)
> >> +++
> >>
> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
> >> Sun Sep 5 19:38:56 2010
> >> @@ -25,12 +25,13 @@ import org.apache.axiom.om.OMOutputForma
> >> import org.apache.axis2.AxisFault;
> >> import org.apache.axis2.Constants;
> >> import org.apache.axis2.context.MessageContext;
> >> -import org.apache.axis2.context.ConfigurationContext;
> >> import org.apache.axis2.context.OperationContext;
> >> +import org.apache.axis2.context.ConfigurationContext;
> >> import org.apache.axis2.description.TransportOutDescription;
> >> import org.apache.axis2.i18n.Messages;
> >> import org.apache.axis2.transport.MessageFormatter;
> >> import org.apache.axis2.transport.TransportUtils;
> >> +import org.apache.axis2.util.JavaUtils;
> >> import org.apache.axis2.wsdl.WSDLConstants;
> >> import org.apache.commons.httpclient.Credentials;
> >> import org.apache.commons.httpclient.Header;
> >> @@ -49,6 +50,8 @@ import org.apache.commons.httpclient.Use
> >> import org.apache.commons.httpclient.auth.AuthPolicy;
> >> import org.apache.commons.httpclient.auth.AuthScope;
> >> import org.apache.commons.httpclient.params.HttpMethodParams;
> >> +import
> org.apache.commons.httpclient.params.HttpConnectionManagerParams;
> >> +import org.apache.commons.httpclient.params.HttpClientParams;
> >> import org.apache.commons.httpclient.protocol.Protocol;
> >> import org.apache.commons.logging.Log;
> >> import org.apache.commons.logging.LogFactory;
> >> @@ -510,21 +513,16 @@ public abstract class AbstractHTTPSender
> >>
> >> HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
> >> if (connManager == null) {
> >> log.trace("Making new ConnectionManager");
> >> - connManager = new
> >> MultiThreadedHttpConnectionManager();
> >> - /*
> >> - * Commented out for now as bugs in other parts of
> >> Axis2 cause test failures when
> >> - * proper connection reuse is enabled.
> >> - */
> >> - //
> >>
> configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
> >> - // connManager);
> >> -
> >> + connManager = new
> >> MultiThreadedHttpConnectionManager();
> >> +
> >>
> configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
> >> + connManager);
> >> }
> >
> > -1 on this change.
> >
> > This tries to solve the problem by introducing another problem. Now since
> > configuration context is set to use one
> MultiThreadedHttpConnectionManager
> > it can only make two simultaneous connections for one host.
>
> It's a change in behavior. Connection caching is now done by default
> and by default MultiThreadedHttpConnectionManager limits the number of
> connections in the pool for the same host to 2. That seems like a
> reasonable default to me but we can always add an option to change it.
>
No I think. This is the reason why you have to comment out the set method at
your first commit.
Axis2 is being used in Bpel servers and Mashup servers where it try to make
many connections with
back end hosts. Think about a scenario where you get 100s of connections for
a BPEL server.
>
> > 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.
>
> 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.
thanks,
Amila.
> If we agree on that then there is no reason for -1.
>
>
> Jarek
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Amila Suriarachchi <am...@gmail.com>.
On Wed, Sep 15, 2010 at 9:56 PM, Jarek Gawor <jg...@gmail.com> wrote:
> On Wed, Sep 15, 2010 at 7:57 AM, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >> Modified:
> >>
> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
> >> URL:
> >>
> http://svn.apache.org/viewvc/axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java?rev=992877&r1=992876&r2=992877&view=diff
> >>
> >>
> ==============================================================================
> >> ---
> >>
> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
> >> (original)
> >> +++
> >>
> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
> >> Sun Sep 5 19:38:56 2010
> >> @@ -25,12 +25,13 @@ import org.apache.axiom.om.OMOutputForma
> >> import org.apache.axis2.AxisFault;
> >> import org.apache.axis2.Constants;
> >> import org.apache.axis2.context.MessageContext;
> >> -import org.apache.axis2.context.ConfigurationContext;
> >> import org.apache.axis2.context.OperationContext;
> >> +import org.apache.axis2.context.ConfigurationContext;
> >> import org.apache.axis2.description.TransportOutDescription;
> >> import org.apache.axis2.i18n.Messages;
> >> import org.apache.axis2.transport.MessageFormatter;
> >> import org.apache.axis2.transport.TransportUtils;
> >> +import org.apache.axis2.util.JavaUtils;
> >> import org.apache.axis2.wsdl.WSDLConstants;
> >> import org.apache.commons.httpclient.Credentials;
> >> import org.apache.commons.httpclient.Header;
> >> @@ -49,6 +50,8 @@ import org.apache.commons.httpclient.Use
> >> import org.apache.commons.httpclient.auth.AuthPolicy;
> >> import org.apache.commons.httpclient.auth.AuthScope;
> >> import org.apache.commons.httpclient.params.HttpMethodParams;
> >> +import
> org.apache.commons.httpclient.params.HttpConnectionManagerParams;
> >> +import org.apache.commons.httpclient.params.HttpClientParams;
> >> import org.apache.commons.httpclient.protocol.Protocol;
> >> import org.apache.commons.logging.Log;
> >> import org.apache.commons.logging.LogFactory;
> >> @@ -510,21 +513,16 @@ public abstract class AbstractHTTPSender
> >>
> >> HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
> >> if (connManager == null) {
> >> log.trace("Making new ConnectionManager");
> >> - connManager = new
> >> MultiThreadedHttpConnectionManager();
> >> - /*
> >> - * Commented out for now as bugs in other parts of
> >> Axis2 cause test failures when
> >> - * proper connection reuse is enabled.
> >> - */
> >> - //
> >>
> configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
> >> - // connManager);
> >> -
> >> + connManager = new
> >> MultiThreadedHttpConnectionManager();
> >> +
> >>
> configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
> >> + connManager);
> >> }
> >
> > -1 on this change.
> >
> > This tries to solve the problem by introducing another problem. Now since
> > configuration context is set to use one
> MultiThreadedHttpConnectionManager
> > it can only make two simultaneous connections for one host.
>
> It's a change in behavior. Connection caching is now done by default
> and by default MultiThreadedHttpConnectionManager limits the number of
> connections in the pool for the same host to 2. That seems like a
> reasonable default to me but we can always add an option to change it.
>
No I think. This is the reason why you have to comment out the set method at
your first commit.
Axis2 is being used in Bpel servers and Mashup servers where it try to make
many connections with
back end hosts. Think about a scenario where you get 100s of connections for
a BPEL server.
>
> > 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.
>
> 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.
thanks,
Amila.
> If we agree on that then there is no reason for -1.
>
>
> Jarek
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Amila Suriarachchi <am...@gmail.com>.
On Wed, Sep 15, 2010 at 9:56 PM, Jarek Gawor <jg...@gmail.com> wrote:
> On Wed, Sep 15, 2010 at 7:57 AM, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >> Modified:
> >>
> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
> >> URL:
> >>
> http://svn.apache.org/viewvc/axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java?rev=992877&r1=992876&r2=992877&view=diff
> >>
> >>
> ==============================================================================
> >> ---
> >>
> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
> >> (original)
> >> +++
> >>
> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
> >> Sun Sep 5 19:38:56 2010
> >> @@ -25,12 +25,13 @@ import org.apache.axiom.om.OMOutputForma
> >> import org.apache.axis2.AxisFault;
> >> import org.apache.axis2.Constants;
> >> import org.apache.axis2.context.MessageContext;
> >> -import org.apache.axis2.context.ConfigurationContext;
> >> import org.apache.axis2.context.OperationContext;
> >> +import org.apache.axis2.context.ConfigurationContext;
> >> import org.apache.axis2.description.TransportOutDescription;
> >> import org.apache.axis2.i18n.Messages;
> >> import org.apache.axis2.transport.MessageFormatter;
> >> import org.apache.axis2.transport.TransportUtils;
> >> +import org.apache.axis2.util.JavaUtils;
> >> import org.apache.axis2.wsdl.WSDLConstants;
> >> import org.apache.commons.httpclient.Credentials;
> >> import org.apache.commons.httpclient.Header;
> >> @@ -49,6 +50,8 @@ import org.apache.commons.httpclient.Use
> >> import org.apache.commons.httpclient.auth.AuthPolicy;
> >> import org.apache.commons.httpclient.auth.AuthScope;
> >> import org.apache.commons.httpclient.params.HttpMethodParams;
> >> +import
> org.apache.commons.httpclient.params.HttpConnectionManagerParams;
> >> +import org.apache.commons.httpclient.params.HttpClientParams;
> >> import org.apache.commons.httpclient.protocol.Protocol;
> >> import org.apache.commons.logging.Log;
> >> import org.apache.commons.logging.LogFactory;
> >> @@ -510,21 +513,16 @@ public abstract class AbstractHTTPSender
> >>
> >> HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
> >> if (connManager == null) {
> >> log.trace("Making new ConnectionManager");
> >> - connManager = new
> >> MultiThreadedHttpConnectionManager();
> >> - /*
> >> - * Commented out for now as bugs in other parts of
> >> Axis2 cause test failures when
> >> - * proper connection reuse is enabled.
> >> - */
> >> - //
> >>
> configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
> >> - // connManager);
> >> -
> >> + connManager = new
> >> MultiThreadedHttpConnectionManager();
> >> +
> >>
> configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
> >> + connManager);
> >> }
> >
> > -1 on this change.
> >
> > This tries to solve the problem by introducing another problem. Now since
> > configuration context is set to use one
> MultiThreadedHttpConnectionManager
> > it can only make two simultaneous connections for one host.
>
> It's a change in behavior. Connection caching is now done by default
> and by default MultiThreadedHttpConnectionManager limits the number of
> connections in the pool for the same host to 2. That seems like a
> reasonable default to me but we can always add an option to change it.
>
No I think. This is the reason why you have to comment out the set method at
your first commit.
Axis2 is being used in Bpel servers and Mashup servers where it try to make
many connections with
back end hosts. Think about a scenario where you get 100s of connections for
a BPEL server.
>
> > 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.
>
> 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.
thanks,
Amila.
> If we agree on that then there is no reason for -1.
>
>
> Jarek
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Amila Suriarachchi <am...@gmail.com>.
On Wed, Sep 15, 2010 at 9:56 PM, Jarek Gawor <jg...@gmail.com> wrote:
> On Wed, Sep 15, 2010 at 7:57 AM, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >> Modified:
> >>
> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
> >> URL:
> >>
> http://svn.apache.org/viewvc/axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java?rev=992877&r1=992876&r2=992877&view=diff
> >>
> >>
> ==============================================================================
> >> ---
> >>
> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
> >> (original)
> >> +++
> >>
> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
> >> Sun Sep 5 19:38:56 2010
> >> @@ -25,12 +25,13 @@ import org.apache.axiom.om.OMOutputForma
> >> import org.apache.axis2.AxisFault;
> >> import org.apache.axis2.Constants;
> >> import org.apache.axis2.context.MessageContext;
> >> -import org.apache.axis2.context.ConfigurationContext;
> >> import org.apache.axis2.context.OperationContext;
> >> +import org.apache.axis2.context.ConfigurationContext;
> >> import org.apache.axis2.description.TransportOutDescription;
> >> import org.apache.axis2.i18n.Messages;
> >> import org.apache.axis2.transport.MessageFormatter;
> >> import org.apache.axis2.transport.TransportUtils;
> >> +import org.apache.axis2.util.JavaUtils;
> >> import org.apache.axis2.wsdl.WSDLConstants;
> >> import org.apache.commons.httpclient.Credentials;
> >> import org.apache.commons.httpclient.Header;
> >> @@ -49,6 +50,8 @@ import org.apache.commons.httpclient.Use
> >> import org.apache.commons.httpclient.auth.AuthPolicy;
> >> import org.apache.commons.httpclient.auth.AuthScope;
> >> import org.apache.commons.httpclient.params.HttpMethodParams;
> >> +import
> org.apache.commons.httpclient.params.HttpConnectionManagerParams;
> >> +import org.apache.commons.httpclient.params.HttpClientParams;
> >> import org.apache.commons.httpclient.protocol.Protocol;
> >> import org.apache.commons.logging.Log;
> >> import org.apache.commons.logging.LogFactory;
> >> @@ -510,21 +513,16 @@ public abstract class AbstractHTTPSender
> >>
> >> HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
> >> if (connManager == null) {
> >> log.trace("Making new ConnectionManager");
> >> - connManager = new
> >> MultiThreadedHttpConnectionManager();
> >> - /*
> >> - * Commented out for now as bugs in other parts of
> >> Axis2 cause test failures when
> >> - * proper connection reuse is enabled.
> >> - */
> >> - //
> >>
> configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
> >> - // connManager);
> >> -
> >> + connManager = new
> >> MultiThreadedHttpConnectionManager();
> >> +
> >>
> configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
> >> + connManager);
> >> }
> >
> > -1 on this change.
> >
> > This tries to solve the problem by introducing another problem. Now since
> > configuration context is set to use one
> MultiThreadedHttpConnectionManager
> > it can only make two simultaneous connections for one host.
>
> It's a change in behavior. Connection caching is now done by default
> and by default MultiThreadedHttpConnectionManager limits the number of
> connections in the pool for the same host to 2. That seems like a
> reasonable default to me but we can always add an option to change it.
>
No I think. This is the reason why you have to comment out the set method at
your first commit.
Axis2 is being used in Bpel servers and Mashup servers where it try to make
many connections with
back end hosts. Think about a scenario where you get 100s of connections for
a BPEL server.
>
> > 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.
>
> 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.
thanks,
Amila.
> If we agree on that then there is no reason for -1.
>
>
> Jarek
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Amila Suriarachchi <am...@gmail.com>.
On Wed, Sep 15, 2010 at 9:56 PM, Jarek Gawor <jg...@gmail.com> wrote:
> On Wed, Sep 15, 2010 at 7:57 AM, Amila Suriarachchi
> <am...@gmail.com> wrote:
> >
> >> Modified:
> >>
> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
> >> URL:
> >>
> http://svn.apache.org/viewvc/axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java?rev=992877&r1=992876&r2=992877&view=diff
> >>
> >>
> ==============================================================================
> >> ---
> >>
> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
> >> (original)
> >> +++
> >>
> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
> >> Sun Sep 5 19:38:56 2010
> >> @@ -25,12 +25,13 @@ import org.apache.axiom.om.OMOutputForma
> >> import org.apache.axis2.AxisFault;
> >> import org.apache.axis2.Constants;
> >> import org.apache.axis2.context.MessageContext;
> >> -import org.apache.axis2.context.ConfigurationContext;
> >> import org.apache.axis2.context.OperationContext;
> >> +import org.apache.axis2.context.ConfigurationContext;
> >> import org.apache.axis2.description.TransportOutDescription;
> >> import org.apache.axis2.i18n.Messages;
> >> import org.apache.axis2.transport.MessageFormatter;
> >> import org.apache.axis2.transport.TransportUtils;
> >> +import org.apache.axis2.util.JavaUtils;
> >> import org.apache.axis2.wsdl.WSDLConstants;
> >> import org.apache.commons.httpclient.Credentials;
> >> import org.apache.commons.httpclient.Header;
> >> @@ -49,6 +50,8 @@ import org.apache.commons.httpclient.Use
> >> import org.apache.commons.httpclient.auth.AuthPolicy;
> >> import org.apache.commons.httpclient.auth.AuthScope;
> >> import org.apache.commons.httpclient.params.HttpMethodParams;
> >> +import
> org.apache.commons.httpclient.params.HttpConnectionManagerParams;
> >> +import org.apache.commons.httpclient.params.HttpClientParams;
> >> import org.apache.commons.httpclient.protocol.Protocol;
> >> import org.apache.commons.logging.Log;
> >> import org.apache.commons.logging.LogFactory;
> >> @@ -510,21 +513,16 @@ public abstract class AbstractHTTPSender
> >>
> >> HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
> >> if (connManager == null) {
> >> log.trace("Making new ConnectionManager");
> >> - connManager = new
> >> MultiThreadedHttpConnectionManager();
> >> - /*
> >> - * Commented out for now as bugs in other parts of
> >> Axis2 cause test failures when
> >> - * proper connection reuse is enabled.
> >> - */
> >> - //
> >>
> configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
> >> - // connManager);
> >> -
> >> + connManager = new
> >> MultiThreadedHttpConnectionManager();
> >> +
> >>
> configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
> >> + connManager);
> >> }
> >
> > -1 on this change.
> >
> > This tries to solve the problem by introducing another problem. Now since
> > configuration context is set to use one
> MultiThreadedHttpConnectionManager
> > it can only make two simultaneous connections for one host.
>
> It's a change in behavior. Connection caching is now done by default
> and by default MultiThreadedHttpConnectionManager limits the number of
> connections in the pool for the same host to 2. That seems like a
> reasonable default to me but we can always add an option to change it.
>
No I think. This is the reason why you have to comment out the set method at
your first commit.
Axis2 is being used in Bpel servers and Mashup servers where it try to make
many connections with
back end hosts. Think about a scenario where you get 100s of connections for
a BPEL server.
>
> > 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.
>
> 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.
thanks,
Amila.
> If we agree on that then there is no reason for -1.
>
>
> Jarek
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Jarek Gawor <jg...@gmail.com>.
On Wed, Sep 15, 2010 at 7:57 AM, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>> Modified:
>> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
>> URL:
>> http://svn.apache.org/viewvc/axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java?rev=992877&r1=992876&r2=992877&view=diff
>>
>> ==============================================================================
>> ---
>> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
>> (original)
>> +++
>> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
>> Sun Sep 5 19:38:56 2010
>> @@ -25,12 +25,13 @@ import org.apache.axiom.om.OMOutputForma
>> import org.apache.axis2.AxisFault;
>> import org.apache.axis2.Constants;
>> import org.apache.axis2.context.MessageContext;
>> -import org.apache.axis2.context.ConfigurationContext;
>> import org.apache.axis2.context.OperationContext;
>> +import org.apache.axis2.context.ConfigurationContext;
>> import org.apache.axis2.description.TransportOutDescription;
>> import org.apache.axis2.i18n.Messages;
>> import org.apache.axis2.transport.MessageFormatter;
>> import org.apache.axis2.transport.TransportUtils;
>> +import org.apache.axis2.util.JavaUtils;
>> import org.apache.axis2.wsdl.WSDLConstants;
>> import org.apache.commons.httpclient.Credentials;
>> import org.apache.commons.httpclient.Header;
>> @@ -49,6 +50,8 @@ import org.apache.commons.httpclient.Use
>> import org.apache.commons.httpclient.auth.AuthPolicy;
>> import org.apache.commons.httpclient.auth.AuthScope;
>> import org.apache.commons.httpclient.params.HttpMethodParams;
>> +import org.apache.commons.httpclient.params.HttpConnectionManagerParams;
>> +import org.apache.commons.httpclient.params.HttpClientParams;
>> import org.apache.commons.httpclient.protocol.Protocol;
>> import org.apache.commons.logging.Log;
>> import org.apache.commons.logging.LogFactory;
>> @@ -510,21 +513,16 @@ public abstract class AbstractHTTPSender
>>
>> HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
>> if (connManager == null) {
>> log.trace("Making new ConnectionManager");
>> - connManager = new
>> MultiThreadedHttpConnectionManager();
>> - /*
>> - * Commented out for now as bugs in other parts of
>> Axis2 cause test failures when
>> - * proper connection reuse is enabled.
>> - */
>> - //
>> configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
>> - // connManager);
>> -
>> + connManager = new
>> MultiThreadedHttpConnectionManager();
>> +
>> configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
>> + connManager);
>> }
>
> -1 on this change.
>
> This tries to solve the problem by introducing another problem. Now since
> configuration context is set to use one MultiThreadedHttpConnectionManager
> it can only make two simultaneous connections for one host.
It's a change in behavior. Connection caching is now done by default
and by default MultiThreadedHttpConnectionManager limits the number of
connections in the pool for the same host to 2. That seems like a
reasonable default to me but we can always add an option to change it.
> 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.).
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. If we agree on that then there is no reason for -1.
Jarek
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Jarek Gawor <jg...@gmail.com>.
On Wed, Sep 15, 2010 at 7:57 AM, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>> Modified:
>> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
>> URL:
>> http://svn.apache.org/viewvc/axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java?rev=992877&r1=992876&r2=992877&view=diff
>>
>> ==============================================================================
>> ---
>> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
>> (original)
>> +++
>> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
>> Sun Sep 5 19:38:56 2010
>> @@ -25,12 +25,13 @@ import org.apache.axiom.om.OMOutputForma
>> import org.apache.axis2.AxisFault;
>> import org.apache.axis2.Constants;
>> import org.apache.axis2.context.MessageContext;
>> -import org.apache.axis2.context.ConfigurationContext;
>> import org.apache.axis2.context.OperationContext;
>> +import org.apache.axis2.context.ConfigurationContext;
>> import org.apache.axis2.description.TransportOutDescription;
>> import org.apache.axis2.i18n.Messages;
>> import org.apache.axis2.transport.MessageFormatter;
>> import org.apache.axis2.transport.TransportUtils;
>> +import org.apache.axis2.util.JavaUtils;
>> import org.apache.axis2.wsdl.WSDLConstants;
>> import org.apache.commons.httpclient.Credentials;
>> import org.apache.commons.httpclient.Header;
>> @@ -49,6 +50,8 @@ import org.apache.commons.httpclient.Use
>> import org.apache.commons.httpclient.auth.AuthPolicy;
>> import org.apache.commons.httpclient.auth.AuthScope;
>> import org.apache.commons.httpclient.params.HttpMethodParams;
>> +import org.apache.commons.httpclient.params.HttpConnectionManagerParams;
>> +import org.apache.commons.httpclient.params.HttpClientParams;
>> import org.apache.commons.httpclient.protocol.Protocol;
>> import org.apache.commons.logging.Log;
>> import org.apache.commons.logging.LogFactory;
>> @@ -510,21 +513,16 @@ public abstract class AbstractHTTPSender
>>
>> HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
>> if (connManager == null) {
>> log.trace("Making new ConnectionManager");
>> - connManager = new
>> MultiThreadedHttpConnectionManager();
>> - /*
>> - * Commented out for now as bugs in other parts of
>> Axis2 cause test failures when
>> - * proper connection reuse is enabled.
>> - */
>> - //
>> configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
>> - // connManager);
>> -
>> + connManager = new
>> MultiThreadedHttpConnectionManager();
>> +
>> configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
>> + connManager);
>> }
>
> -1 on this change.
>
> This tries to solve the problem by introducing another problem. Now since
> configuration context is set to use one MultiThreadedHttpConnectionManager
> it can only make two simultaneous connections for one host.
It's a change in behavior. Connection caching is now done by default
and by default MultiThreadedHttpConnectionManager limits the number of
connections in the pool for the same host to 2. That seems like a
reasonable default to me but we can always add an option to change it.
> 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.).
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. If we agree on that then there is no reason for -1.
Jarek
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Jarek Gawor <jg...@gmail.com>.
On Wed, Sep 15, 2010 at 7:57 AM, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>> Modified:
>> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
>> URL:
>> http://svn.apache.org/viewvc/axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java?rev=992877&r1=992876&r2=992877&view=diff
>>
>> ==============================================================================
>> ---
>> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
>> (original)
>> +++
>> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
>> Sun Sep 5 19:38:56 2010
>> @@ -25,12 +25,13 @@ import org.apache.axiom.om.OMOutputForma
>> import org.apache.axis2.AxisFault;
>> import org.apache.axis2.Constants;
>> import org.apache.axis2.context.MessageContext;
>> -import org.apache.axis2.context.ConfigurationContext;
>> import org.apache.axis2.context.OperationContext;
>> +import org.apache.axis2.context.ConfigurationContext;
>> import org.apache.axis2.description.TransportOutDescription;
>> import org.apache.axis2.i18n.Messages;
>> import org.apache.axis2.transport.MessageFormatter;
>> import org.apache.axis2.transport.TransportUtils;
>> +import org.apache.axis2.util.JavaUtils;
>> import org.apache.axis2.wsdl.WSDLConstants;
>> import org.apache.commons.httpclient.Credentials;
>> import org.apache.commons.httpclient.Header;
>> @@ -49,6 +50,8 @@ import org.apache.commons.httpclient.Use
>> import org.apache.commons.httpclient.auth.AuthPolicy;
>> import org.apache.commons.httpclient.auth.AuthScope;
>> import org.apache.commons.httpclient.params.HttpMethodParams;
>> +import org.apache.commons.httpclient.params.HttpConnectionManagerParams;
>> +import org.apache.commons.httpclient.params.HttpClientParams;
>> import org.apache.commons.httpclient.protocol.Protocol;
>> import org.apache.commons.logging.Log;
>> import org.apache.commons.logging.LogFactory;
>> @@ -510,21 +513,16 @@ public abstract class AbstractHTTPSender
>>
>> HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
>> if (connManager == null) {
>> log.trace("Making new ConnectionManager");
>> - connManager = new
>> MultiThreadedHttpConnectionManager();
>> - /*
>> - * Commented out for now as bugs in other parts of
>> Axis2 cause test failures when
>> - * proper connection reuse is enabled.
>> - */
>> - //
>> configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
>> - // connManager);
>> -
>> + connManager = new
>> MultiThreadedHttpConnectionManager();
>> +
>> configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
>> + connManager);
>> }
>
> -1 on this change.
>
> This tries to solve the problem by introducing another problem. Now since
> configuration context is set to use one MultiThreadedHttpConnectionManager
> it can only make two simultaneous connections for one host.
It's a change in behavior. Connection caching is now done by default
and by default MultiThreadedHttpConnectionManager limits the number of
connections in the pool for the same host to 2. That seems like a
reasonable default to me but we can always add an option to change it.
> 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.).
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. If we agree on that then there is no reason for -1.
Jarek
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Jarek Gawor <jg...@gmail.com>.
On Wed, Sep 15, 2010 at 7:57 AM, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>> Modified:
>> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
>> URL:
>> http://svn.apache.org/viewvc/axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java?rev=992877&r1=992876&r2=992877&view=diff
>>
>> ==============================================================================
>> ---
>> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
>> (original)
>> +++
>> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
>> Sun Sep 5 19:38:56 2010
>> @@ -25,12 +25,13 @@ import org.apache.axiom.om.OMOutputForma
>> import org.apache.axis2.AxisFault;
>> import org.apache.axis2.Constants;
>> import org.apache.axis2.context.MessageContext;
>> -import org.apache.axis2.context.ConfigurationContext;
>> import org.apache.axis2.context.OperationContext;
>> +import org.apache.axis2.context.ConfigurationContext;
>> import org.apache.axis2.description.TransportOutDescription;
>> import org.apache.axis2.i18n.Messages;
>> import org.apache.axis2.transport.MessageFormatter;
>> import org.apache.axis2.transport.TransportUtils;
>> +import org.apache.axis2.util.JavaUtils;
>> import org.apache.axis2.wsdl.WSDLConstants;
>> import org.apache.commons.httpclient.Credentials;
>> import org.apache.commons.httpclient.Header;
>> @@ -49,6 +50,8 @@ import org.apache.commons.httpclient.Use
>> import org.apache.commons.httpclient.auth.AuthPolicy;
>> import org.apache.commons.httpclient.auth.AuthScope;
>> import org.apache.commons.httpclient.params.HttpMethodParams;
>> +import org.apache.commons.httpclient.params.HttpConnectionManagerParams;
>> +import org.apache.commons.httpclient.params.HttpClientParams;
>> import org.apache.commons.httpclient.protocol.Protocol;
>> import org.apache.commons.logging.Log;
>> import org.apache.commons.logging.LogFactory;
>> @@ -510,21 +513,16 @@ public abstract class AbstractHTTPSender
>>
>> HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
>> if (connManager == null) {
>> log.trace("Making new ConnectionManager");
>> - connManager = new
>> MultiThreadedHttpConnectionManager();
>> - /*
>> - * Commented out for now as bugs in other parts of
>> Axis2 cause test failures when
>> - * proper connection reuse is enabled.
>> - */
>> - //
>> configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
>> - // connManager);
>> -
>> + connManager = new
>> MultiThreadedHttpConnectionManager();
>> +
>> configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
>> + connManager);
>> }
>
> -1 on this change.
>
> This tries to solve the problem by introducing another problem. Now since
> configuration context is set to use one MultiThreadedHttpConnectionManager
> it can only make two simultaneous connections for one host.
It's a change in behavior. Connection caching is now done by default
and by default MultiThreadedHttpConnectionManager limits the number of
connections in the pool for the same host to 2. That seems like a
reasonable default to me but we can always add an option to change it.
> 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.).
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. If we agree on that then there is no reason for -1.
Jarek
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
Re: svn commit: r992877 - in /axis/axis2/java/core/trunk: ./
modules/adb-codegen/test-resources/testsuite/ modules/adb-codegen/test/org/apache/axis2/schema/particlemaxoccurs/
modules/kernel/src/org/apache/axis2/jsr181/ modules/kernel/src/org/apache/a
Posted by Jarek Gawor <jg...@gmail.com>.
On Wed, Sep 15, 2010 at 7:57 AM, Amila Suriarachchi
<am...@gmail.com> wrote:
>
>> Modified:
>> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
>> URL:
>> http://svn.apache.org/viewvc/axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java?rev=992877&r1=992876&r2=992877&view=diff
>>
>> ==============================================================================
>> ---
>> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
>> (original)
>> +++
>> axis/axis2/java/core/trunk/modules/transport/http/src/org/apache/axis2/transport/http/AbstractHTTPSender.java
>> Sun Sep 5 19:38:56 2010
>> @@ -25,12 +25,13 @@ import org.apache.axiom.om.OMOutputForma
>> import org.apache.axis2.AxisFault;
>> import org.apache.axis2.Constants;
>> import org.apache.axis2.context.MessageContext;
>> -import org.apache.axis2.context.ConfigurationContext;
>> import org.apache.axis2.context.OperationContext;
>> +import org.apache.axis2.context.ConfigurationContext;
>> import org.apache.axis2.description.TransportOutDescription;
>> import org.apache.axis2.i18n.Messages;
>> import org.apache.axis2.transport.MessageFormatter;
>> import org.apache.axis2.transport.TransportUtils;
>> +import org.apache.axis2.util.JavaUtils;
>> import org.apache.axis2.wsdl.WSDLConstants;
>> import org.apache.commons.httpclient.Credentials;
>> import org.apache.commons.httpclient.Header;
>> @@ -49,6 +50,8 @@ import org.apache.commons.httpclient.Use
>> import org.apache.commons.httpclient.auth.AuthPolicy;
>> import org.apache.commons.httpclient.auth.AuthScope;
>> import org.apache.commons.httpclient.params.HttpMethodParams;
>> +import org.apache.commons.httpclient.params.HttpConnectionManagerParams;
>> +import org.apache.commons.httpclient.params.HttpClientParams;
>> import org.apache.commons.httpclient.protocol.Protocol;
>> import org.apache.commons.logging.Log;
>> import org.apache.commons.logging.LogFactory;
>> @@ -510,21 +513,16 @@ public abstract class AbstractHTTPSender
>>
>> HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER);
>> if (connManager == null) {
>> log.trace("Making new ConnectionManager");
>> - connManager = new
>> MultiThreadedHttpConnectionManager();
>> - /*
>> - * Commented out for now as bugs in other parts of
>> Axis2 cause test failures when
>> - * proper connection reuse is enabled.
>> - */
>> - //
>> configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
>> - // connManager);
>> -
>> + connManager = new
>> MultiThreadedHttpConnectionManager();
>> +
>> configContext.setProperty(HTTPConstants.MULTITHREAD_HTTP_CONNECTION_MANAGER,
>> + connManager);
>> }
>
> -1 on this change.
>
> This tries to solve the problem by introducing another problem. Now since
> configuration context is set to use one MultiThreadedHttpConnectionManager
> it can only make two simultaneous connections for one host.
It's a change in behavior. Connection caching is now done by default
and by default MultiThreadedHttpConnectionManager limits the number of
connections in the pool for the same host to 2. That seems like a
reasonable default to me but we can always add an option to change it.
> 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.).
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. If we agree on that then there is no reason for -1.
Jarek
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org