[
http://issues.apache.org/jira/browse/AXIS-1771?page=comments#action_12420925 ]
Peter Molettiere commented on AXIS-1771:
----------------------------------------
I don't know. I just saw your comment, Tony, and noticed that there are six
comments from dims on the day of my last post, and that he closed the issue the
next day. I wasn't aware the issue had been updated.
About the time I posted relative performance graphs for ObjectOutputStream, we
stopped using Axis in favor of that solution. If I'm reading dims comment
correctly ("Axis takes 8 times slower consistently as compared to the
ObjectOutputStream option."), then I'd say we did the right thing for our
application. If ObjectOutputStream uses less memory and is faster to boot, that
suits us better, as we don't require strict SOAP interoperability.
Be aware, too, that this issue is mainly problematic when serializing large
messages with Axis. If you're in the 90% use case, that is, serializing small
messages, you probably won't notice.
> Excessive Memory Use During Serialization/Deserialization
> ---------------------------------------------------------
>
> Key: AXIS-1771
> URL: http://issues.apache.org/jira/browse/AXIS-1771
> Project: Apache Axis
> Type: Bug
> Components: Basic Architecture
> Versions: 1.2RC2
> Environment: JDK 1.4.2, Mac OS X, Linux, Windows
> Reporter: Peter Molettiere
> Assignee: Venkat Reddy
> Priority: Blocker
> Attachments: MTC_venkat.java, MemoryTesterClient.java,
> MemoryTesterClient.java, SOAPmsg_multiref_false.xml,
> SOAPmsg_multiref_true.xml, SerializationContext.java.diff,
> axis-memory-use.gif, memory-use-test.tgz, memory-use-test.tgz, recursion.png
>
> Axis uses pathological amounts of memory during the
> serialization/deserialization process.
> We see about a 30 to 1 ratio of memory used during (de)serialization to
> in-memory representation of the objects being (de)serialized. So ser/deser in
> axis of a 2M graph of objects uses 288M of memory! Further, the memory used
> seems to scale linearly with the size of the object graph being serialized.
> The memory used does seem to be released once serialization is done, so this
> isn't a leak.
> Using the attached example code, (based on the code used to demonstrate
> AXIS-1423) you can see this behavior. The test automatically runs with a max
> heap size of 1024M, and runs out of memory serializing a 28M object graph.
> As provided, it generates the following output:
> Buildfile: build.xml
> build:
> [javac] Compiling 1 source file to /Users/pietro/Work/Axis Memory
> Test/build/classes
> run:
> [java] - Unable to find required classes (javax.activation.DataHandler
> and javax.mail.internet.MimeMultipart). Attachment support is disabled.
> [java] Created tree with 5 levels and 3 children at each level
> [java] Axis used 13 MBytes to serialize 230 KBytes, a ratio of 30.0
> [java] GC freed 13 MBytes
> [java] Created tree with 5 levels and 4 children at each level
> [java] Axis used 71 MBytes to serialize 1 MBytes, a ratio of 31.0
> [java] GC freed 71 MBytes
> [java] Created tree with 5 levels and 5 children at each level
> [java] Axis used 288 MBytes to serialize 2 MBytes, a ratio of 51.0
> [java] GC freed 287 MBytes
> [java] Created tree with 5 levels and 6 children at each level
> [java] Axis used 671 MBytes to serialize 11 MBytes, a ratio of 29.0
> [java] GC freed 675 MBytes
> [java] Created tree with 5 levels and 7 children at each level
> [java] Out of Memory serializing 28 MBytes tree.
> [java] Java Result: 1
> BUILD SUCCESSFUL
> Total time: 2 minutes 51 seconds
> Note that the ratios are halved from the reported values, since it includes
> both serialization and deserialization of the object graph. So axis uses
> 30.5M to serialize a 1M message, and another 30.5M to deserialize it,
> resulting in the reported 71M reported above. Also, notice that the ratio
> stays close to 30 to 1 regardless of object graph size. This is the linear
> scaling I mention above.
> Note also, that if you tweak the code to generate very small object graphs,
> you see extremely high ratios, but I would expect this due to simple one-time
> overhead to operate on very small amounts of data. That's why I start with
> the graph size that I do.
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
