Return-Path: Delivered-To: apmail-ws-axis-user-archive@www.apache.org Received: (qmail 70221 invoked from network); 23 Feb 2004 19:01:20 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 23 Feb 2004 19:01:20 -0000 Received: (qmail 61209 invoked by uid 500); 23 Feb 2004 19:01:00 -0000 Delivered-To: apmail-ws-axis-user-archive@ws.apache.org Received: (qmail 61147 invoked by uid 500); 23 Feb 2004 19:00:59 -0000 Mailing-List: contact axis-user-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-user@ws.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-user@ws.apache.org Received: (qmail 61137 invoked from network); 23 Feb 2004 19:00:59 -0000 Received: from unknown (HELO mail.ecb.int) (193.96.201.2) by daedalus.apache.org with SMTP; 23 Feb 2004 19:00:59 -0000 Received: (from smtpd@localhost) by mail.ecb.int (8.12.8/8.12.8) id i1NJ12oQ017361 for ; Mon, 23 Feb 2004 20:01:02 +0100 (MET) Received: from exchange-tmp.masq(193.96.201.190), claiming to be "int-mail-gw.ecb.de" via SMTP by mail.ecb.int, id smtpdAAAxOai5H; Mon Feb 23 20:00:53 2004 Received: from cemexc24.ecb01.ecb.de ([10.20.201.24]) by int-mail-gw.ecb.de with Microsoft SMTPSVC(5.0.2195.5329); Mon, 23 Feb 2004 20:00:53 +0100 Received: from cimexc21.ecb01.ecb.de ([10.20.200.21]) by cemexc24.ecb01.ecb.de with Microsoft SMTPSVC(5.0.2195.5329); Mon, 23 Feb 2004 20:00:53 +0100 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FA3F.5C083918" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: RE: Axis 1.1 Memory leaks Date: Mon, 23 Feb 2004 20:00:53 +0100 Message-ID: <71C090BD7F12FB4BABB006C9260DEBFB1446FA@cimexc21.ecb01.ecb.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Axis 1.1 Memory leaks Thread-Index: AcP6PRwaKe0tOc7OTyiDmgn/XTkMxAAADOag From: To: X-OriginalArrivalTime: 23 Feb 2004 19:00:53.0129 (UTC) FILETIME=[5C154F90:01C3FA3F] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N This is a multi-part message in MIME format. ------_=_NextPart_001_01C3FA3F.5C083918 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I actually found a solution to the memory inefficiency problem. It is kind of tricky, so this mail will be a little verbose... 1) *Original* interface exposed as webservice: public String doSomething(ExecutionArgumentTO to) { ... } where ExecutionArgumentTO is a pojo exposing an attribute private String myDocument public getMyDocument ... public setMyDocument ... plus other informations related to the document (ok, the pojo is much = more complex than this, but this is for sake of simplicity). If the document to set was very big (more than 2Mb), axis was failing = with an OutOfMemoryError on the server side. It means that the envelope was correctly sent, but axis had problem to = parse and extract the document. This issue was taking place using both style "document" or "rpc". Using this approach the produced document (the envelope), was = incorporating my document *inside* the envelope body. 2) *New* interface exposed as webservice: public String doSomething(ExecutionArgumentTO to) { ... } where ExecutionArgumentTO is a pojo exposing an attribute private javax.activation.DataHandler myDocument public getMyDocument ... public setMyDocument ... As you can see, the only difference reside in having changed the type of = the document. Using the=20 DataHandler object as wrapper for a document, produce a different = message. The document, infact, is external to the soap message. I have something like this: =09 blah blah ------=3D_Part_0_12621140.1077561773549=20 Content-Type: application/octet-stream=20 Content-Transfer-Encoding: binary=20 Content-Id: <437D716EBC3F696DECEB3A5CFE4EB5B4> .......the 2.8 MB documents.... In other words, using DataHandler as type does the magic to = automatically use attachments istead of embedded xml. The generated message is, infact, equal to the one generated using the = /samples/attachments directory. I hope it makes sense :), Luciano -----Original Message----- From: Nelson Minar [mailto:nelson@monkey.org] Sent: Monday 23 February 2004 19:44 To: axis-user@ws.apache.org Subject: RE: Axis 1.1 Memory leaks >the problem that I'm experiencing is related to some (known?) Axis = problem to >handle large xml documents. Understood. Does anyone have a simple benchmark that shows how much memory Axis consumes as a function of the size of the SOAP messages? >In fact, I'm sending back and forth binary files or large xml files >(2.5Mb) without using the SAAJ specification or the code used in the >/sample/attachemnt folder of Axis1.1 distrib. I suspect you'll find many SOAP environments have a hard time with this. If you're sending giant data, attachments are likely to be more efficient. But attachments have interop troubles, and they're not objects. I'd like to be able to send arrays of 100,000 complex objects and have them available to my server demarshalled. Barring that, I'd like to know what the practical limits are. Any e-mail message from the European Central Bank (ECB) is sent in good = faith but shall neither be binding nor construed as constituting a = commitment by the ECB except where provided for in a written agreement. This e-mail is intended only for the use of the recipient(s) named = above. Any unauthorised disclosure, use or dissemination, either in = whole or in part, is prohibited. If you have received this e-mail in error, please notify the sender = immediately via e-mail and delete this e-mail from your system. ------_=_NextPart_001_01C3FA3F.5C083918 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Axis 1.1 Memory leaks

I actually found a solution to the memory inefficiency = problem.
It is kind of tricky, so this mail will be a little = verbose...

1)
*Original* interface exposed as webservice:
        public = String doSomething(ExecutionArgumentTO to) { ... }

where ExecutionArgumentTO is a pojo exposing an = attribute
        private = String myDocument
        public = getMyDocument ...
        public = setMyDocument ...

plus other informations related to the document (ok, = the pojo is much more complex than this, but this is
for sake of simplicity).
If the document to set was very big (more than 2Mb), = axis was failing with an OutOfMemoryError on the server side.
It means that the envelope was correctly sent, but = axis had problem to parse and extract the document.
This issue was taking place using both style = "document" or "rpc".
Using this approach the produced document (the = envelope), was incorporating my document *inside* the envelope = body.

2)
*New* interface exposed as webservice:
        public = String doSomething(ExecutionArgumentTO to) { ... }

where ExecutionArgumentTO is a pojo exposing an = attribute
        private = javax.activation.DataHandler myDocument
        public = getMyDocument ...
        public = setMyDocument ...

As you can see, the only difference reside in having = changed the type of the document. Using the
DataHandler object as wrapper for a document, produce = a different message. The document, infact, is
external to the soap message. I have something like = this:

<soapenv:Envelope ... >
 <soapenv:Body>
       =20
    <mydocument = href=3D"cid:437D716EBC3F696DECEB3A5CFE4EB5B4"/>
    <databaseId = xsi:nil=3D"true"/>
    <fileName>blah = blah</datasetFileName>

</soapenv:Body>
</soapenv:Envelope>
------=3D_Part_0_12621140.1077561773549
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
Content-Id: = <437D716EBC3F696DECEB3A5CFE4EB5B4>
.......the 2.8 MB documents....

In other words, using DataHandler as type does the = magic to automatically use attachments istead of embedded xml.
The generated message is, infact, equal to the one = generated using the /samples/attachments directory.

I hope it makes sense :),
Luciano


-----Original Message-----
From: Nelson Minar [mailto:nelson@monkey.org]
Sent: Monday 23 February 2004 19:44
To: axis-user@ws.apache.org
Subject: RE: Axis 1.1 Memory leaks


>the problem that I'm experiencing is related to = some (known?) Axis problem to
>handle large xml documents.

Understood. Does anyone have a simple benchmark that = shows how much
memory Axis consumes as a function of the size of the = SOAP messages?

>In fact, I'm sending back and forth binary files = or large xml files
>(2.5Mb) without using the SAAJ specification or = the code used in the
>/sample/attachemnt folder of Axis1.1 = distrib.

I suspect you'll find many SOAP environments have a = hard time with
this. If you're sending giant data, attachments are = likely to be more
efficient. But attachments have interop troubles, and = they're not
objects. I'd like to be able to send arrays of = 100,000 complex objects
and have them available to my server demarshalled. = Barring that, I'd
like to know what the practical limits are.

 

Any e-mail message from the European Central = Bank (ECB) is sent in good faith but shall neither be binding nor = construed as constituting a commitment by the ECB except where provided = for in a written agreement.
This e-mail is intended only for the use = of the recipient(s) named above. Any unauthorised disclosure, use or = dissemination, either in whole or in part, is prohibited.
If you have = received this e-mail in error, please notify the sender immediately via = e-mail and delete this e-mail from your = system.

------_=_NextPart_001_01C3FA3F.5C083918--