Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 911 invoked from network); 25 Sep 2007 16:26:28 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 25 Sep 2007 16:26:28 -0000 Received: (qmail 72933 invoked by uid 500); 25 Sep 2007 16:26:12 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 72882 invoked by uid 500); 25 Sep 2007 16:26:12 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 72843 invoked by uid 99); 25 Sep 2007 16:26:11 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Sep 2007 09:26:11 -0700 X-ASF-Spam-Status: No, hits=-2.0 required=10.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of robinsona@us.ibm.com designates 32.97.110.154 as permitted sender) Received: from [32.97.110.154] (HELO e36.co.us.ibm.com) (32.97.110.154) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Sep 2007 16:28:24 +0000 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e36.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l8PGPlf1030151 for ; Tue, 25 Sep 2007 12:25:47 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l8PGGFig465400 for ; Tue, 25 Sep 2007 10:25:47 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l8PG9QGA026365 for ; Tue, 25 Sep 2007 10:09:26 -0600 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l8PG9PWO026355 for ; Tue, 25 Sep 2007 10:09:25 -0600 In-Reply-To: <60708f4b0709190119n3f42b405t1f6e4efafbd9528@mail.gmail.com> Subject: Re: [axis2] Revisiting the Proposal for fixing out-of-memory error JIRA axis2-2968 To: axis-dev@ws.apache.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Ann Robinson Date: Tue, 25 Sep 2007 11:09:24 -0500 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 7.0.2FP2HF51 | June 19, 2007) at 09/25/2007 10:09:25 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=09BBF9F2DFCB80F08f9e8a93df938690918c09BBF9F2DFCB80F0" Content-Disposition: inline X-Virus-Checked: Checked by ClamAV on apache.org --0__=09BBF9F2DFCB80F08f9e8a93df938690918c09BBF9F2DFCB80F0 Content-type: text/plain; charset=US-ASCII Amila, Thanks for the comments and the postings to the JIRA. To answer your question about the WSDL definition wrapper: The problem is having a solution that will work in all WSDL cases (including the imports, includes, ?wsdl, etc), and not impact the customer's setup or API usage. Also, not every server environment will be resource constrained - for those server environments, it would be nice to avoid the processing overhead. So, I was thinking of having a configuration parameter to control how the in-memory copy of the WSDL definition is handled on the AxisService object. For example, given a configuration parameter named ReduceWSDLMemoryCache (or something similar), then the WSDL definition wrapper could query the configuration parameter. If the configuration setting is "True", then the wrapper takes the steps to reduce the memory used by the WSDL defintion. For now, that would be serializing the WSDL definition object if it can be. When the updates to WSDL4J are available, then the wrapper could take advantage of new APIs or steps provided by WSDL4J. I will post a patch to the JIRA with the configuration parameter and the updates to the WSDL definition wrapper soon for review. - Ann --0__=09BBF9F2DFCB80F08f9e8a93df938690918c09BBF9F2DFCB80F0 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Amila,
Thanks for the comments and the postings to the JIRA.

To answer your question about the WSDL definition wrapper:

The problem is having a solution that will work in all WSDL cases (including the imports,
includes, ?wsdl, etc), and not impact the customer's setup or API usage. Also, not every server
environment will be resource constrained - for those server environments, it would be nice to
avoid the processing overhead.

So, I was thinking of having a configuration parameter to control how the in-memory copy of the
WSDL definition is handled on the AxisService object.

For example, given a configuration parameter named ReduceWSDLMemoryCache (or something similar),
then the WSDL definition wrapper could query the configuration parameter. If the configuration
setting is "True", then the wrapper takes the steps to reduce the memory used by the WSDL
defintion. For now, that would be serializing the WSDL definition object if it can be. When the
updates to WSDL4J are available, then the wrapper could take advantage of new APIs or steps
provided by WSDL4J.

I will post a patch to the JIRA with the configuration parameter and the updates to the WSDL
definition wrapper soon for review.

- Ann --0__=09BBF9F2DFCB80F08f9e8a93df938690918c09BBF9F2DFCB80F0--