You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by pa...@gsk.com on 2005/01/14 18:18:29 UTC
Axis - Out OF Memory problem
Hi,
Are there any know issues/bugs with Axis 1.1 related to XML parsing that
might lead to Out of Memory problem. The JVM is going out of memory
consistently now and our analysis is getting zeroed down to Axis framework
classes. Is anyone aware of any open bug or has faced something similar ?
Re: Axis - Out OF Memory problem
Posted by Peter Molettiere <pi...@axonstudios.net>.
Yeah I made and filed one of those when I first reported the bug.
--Peter
On Jan 17, 2005, at 11:21 AM, Davanum Srinivas wrote:
> Peter,
>
> If possible, We'd like a test case with large object graphs to
> reproduce the problem...So that we can make sure we can recreate the
> problem and fix it as well.
>
> thanks,
> dims
>
>
> On Mon, 17 Jan 2005 10:44:09 -0800, Peter Molettiere
> <pi...@axonstudios.net> wrote:
>>
>> Not sure what you'd like me to do. The method we're using to deal with
>> serializing large graphs of objects through axis is clearly outlined
>> in
>> my previous posts. If there's something in particular you'd like us to
>> look at, let me know.
>>
>> Last night as I was falling asleep I realized I didn't mention another
>> possibility, though, so I may as well mention that here, too.
>> Basically, if you're having trouble serializing large graphs of
>> objects, then you can try re-writing your application to issue many
>> small requests where you used to issue a single large request. The
>> most
>> common recommendation seen is in response to people trying to
>> serialize
>> large result sets. In that case it's pretty easy to send X rows, and
>> request the next X rows in another request.
>>
>> Our application hasn't been so easily tamed, since we're serializing
>> java object graphs, usually trees. We've talked about implementing a
>> serialization scheme which would allow us to request any subtree of
>> depth N from any given node, which would allow us to fetch our tree
>> with a series of separate calls, but we've had a lot of other more
>> important tasks, and the heap size and gc tweaks I've already
>> mentioned
>> are working well enough for us at the moment.
>>
>> The other method we've been considering, since interop isn't much of a
>> requirement for us, is to implement a simple XML-RPC mechanism using
>> standard XML serialization and plain vanilla HTTP servlets.
>>
>> --Peter
>>
>> On Jan 15, 2005, at 7:24 AM, Davanum Srinivas wrote:
>>
>>> Peter,
>>>
>>> anyway you can help us tune latest axis cvs?
>>>
>>> thanks,
>>> dims
>>>
>>>
>>> On Fri, 14 Jan 2005 14:04:31 -0800, Peter Molettiere
>>> <pi...@axonstudios.net> wrote:
>>>>
>>>> On Jan 14, 2005, at 1:29 PM, pawan.v.udernani@gsk.com wrote:
>>>>> Your mail provides a great deal of information. But, now I feel
>>>>> trapped. Thanks anyways.
>>>>
>>>> /shrug/
>>>>
>>>> Try these, in this order:
>>>>
>>>> 0) Use the latest axis distro
>>>> 1) Use xerces 2.6.2
>>>> 2) Up your heap size: -Xmx768M -Xms128M -XX:+UseConcMarkSweepGC
>>>>
>>>> if the above don't work, then
>>>>
>>>> 3) Write your own SOAP engine.
>>>>
>>>> That's about the shape of it, I think.
>>>>
>>>> --
>>>> Peter Molettiere
>>>> Senior Engineer
>>>> Truereq, Inc.
>>>> http://www.truereq.com/
>>>>
>>>>
>>>
>>>
>>> --
>>> Davanum Srinivas - http://webservices.apache.org/~dims/
>>>
>> --
>> Peter Molettiere
>> Senior Engineer
>> Truereq, Inc.
>> http://www.truereq.com/
>>
>>
>
>
> --
> Davanum Srinivas - http://webservices.apache.org/~dims/
>
--
Peter Molettiere
Senior Engineer
Truereq, Inc.
http://www.truereq.com/
Re: Axis - Out OF Memory problem
Posted by Davanum Srinivas <da...@gmail.com>.
Nishant,
please create a bug report.
thanks,
dims
On 18 Jan 2005 16:18:31 +0530, Nishant Kumar <ni...@itellix.com> wrote:
> One small question
> In the ArrayDeserializer class there is an inner class
> ArrayListExtension.
> In the second constructor of this class, the one which takes length as
> parameter, why do we create such a large array when the array we
> normally use is of very small size. why don't we create an array of size
> length.
>
> thanks,
> nishant
>
> On Tue, 2005-01-18 at 09:49, Peter Molettiere wrote:
> > We find that it's a straight 10 to 1 ratio between the in-memory
> > representation and the memory used to serialize it, and this holds true
> > for pretty much any size message. It's not a problem when you're
> > dealing with 1 or 2 M of in-memory representation, since that runs to
> > only 10 or 20M during serialization. I don't remember what the default
> > heap size is off the top of my head, but it only takes a 7M in memory
> > representation to exceed a 64M heap. Obviously 32 is even easier to
> > break. This is the source of the common advice "raise your heap size"
> > in response to all the messages posted to this list claiming out of
> > memory exceptions during serialization.
> >
> > If you look back at my original jira bug posting, there's a test case
> > which will let you configure a tree of arbitrary width and depth. Make
> > a big one, and watch memory use during serialization in a profiler.
> > Checkpoint it before and watch for the high water mark, and you'll see
> > what I'm talking about.
> >
> > That bug was about memory leaks, and those seem to be mostly fixed.
> > Anything left seems small enough that we can get 2 month up times now,
> > which we're happy with. If you GC after you serialize you see gobs of
> > memory being released.
> >
> > --Peter
> >
> > On Jan 17, 2005, at 11:25 AM, pawan.v.udernani@gsk.com wrote:
> >
> > >
> > > Hi,
> > >
> > > Does anyone has an idea how "large" are we talking about ? Do we have
> > > any data that says that it fails for certain size of objects, in terms
> > > of bytes or Kbytes ? If yes, I can compare it to the size of data that
> > > our webservice client consumes as of now.
> > >
> > >
> > > Thanks,
> > >
> > > Pawan.
> > >
> > >
> > >
> > >
> > >
> > >
> > > "Davanum Srinivas" <da...@gmail.com>
> > >
> > > 17-Jan-2005 14:21
> > >
> > > Please respond to axis-dev@ws.apache.org; Please respond to
> > > dims@apache.org
> > >
> > >
> > >
> > >
> > > To
> > > axis-dev@ws.apache.org
> > >
> > > cc
> > >
> > > Subject
> > > Re: Axis - Out OF Memory problem
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Peter,
> > >
> > > If possible, We'd like a test case with large object graphs to
> > > reproduce the problem...So that we can make sure we can recreate the
> > > problem and fix it as well.
> > >
> > > thanks,
> > > dims
> > >
> > >
> > > On Mon, 17 Jan 2005 10:44:09 -0800, Peter Molettiere
> > > <pi...@axonstudios.net> wrote:
> > > >
> > > > Not sure what you'd like me to do. The method we're using to deal
> > > with
> > > > serializing large graphs of objects through axis is clearly
> > > outlined in
> > > > my previous posts. If there's something in particular you'd like us
> > > to
> > > > look at, let me know.
> > > >
> > > > Last night as I was falling asleep I realized I didn't mention
> > > another
> > > > possibility, though, so I may as well mention that here, too.
> > > > Basically, if you're having trouble serializing large graphs of
> > > > objects, then you can try re-writing your application to issue many
> > > > small requests where you used to issue a single large request. The
> > > most
> > > > common recommendation seen is in response to people trying to
> > > serialize
> > > > large result sets. In that case it's pretty easy to send X rows, and
> > > > request the next X rows in another request.
> > > >
> > > > Our application hasn't been so easily tamed, since we're serializing
> > > > java object graphs, usually trees. We've talked about implementing a
> > > > serialization scheme which would allow us to request any subtree of
> > > > depth N from any given node, which would allow us to fetch our tree
> > > > with a series of separate calls, but we've had a lot of other more
> > > > important tasks, and the heap size and gc tweaks I've already
> > > mentioned
> > > > are working well enough for us at the moment.
> > > >
> > > > The other method we've been considering, since interop isn't much
> > > of a
> > > > requirement for us, is to implement a simple XML-RPC mechanism using
> > > > standard XML serialization and plain vanilla HTTP servlets.
> > > >
> > > > --Peter
> > > >
> > > > On Jan 15, 2005, at 7:24 AM, Davanum Srinivas wrote:
> > > >
> > > > > Peter,
> > > > >
> > > > > anyway you can help us tune latest axis cvs?
> > > > >
> > > > > thanks,
> > > > > dims
> > > > >
> > > > >
> > > > > On Fri, 14 Jan 2005 14:04:31 -0800, Peter Molettiere
> > > > > <pi...@axonstudios.net> wrote:
> > > > >>
> > > > >> On Jan 14, 2005, at 1:29 PM, pawan.v.udernani@gsk.com wrote:
> > > > >>> Your mail provides a great deal of information. But, now I feel
> > > > >>> trapped. Thanks anyways.
> > > > >>
> > > > >> /shrug/
> > > > >>
> > > > >> Try these, in this order:
> > > > >>
> > > > >> 0) Use the latest axis distro
> > > > >> 1) Use xerces 2.6.2
> > > > >> 2) Up your heap size: -Xmx768M -Xms128M -XX:+UseConcMarkSweepGC
> > > > >>
> > > > >> if the above don't work, then
> > > > >>
> > > > >> 3) Write your own SOAP engine.
> > > > >>
> > > > >> That's about the shape of it, I think.
> > > > >>
> > > > >> --
> > > > >> Peter Molettiere
> > > > >> Senior Engineer
> > > > >> Truereq, Inc.
> > > > >> http://www.truereq.com/
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > > --
> > > > > Davanum Srinivas - http://webservices.apache.org/~dims/
> > > > >
> > > > --
> > > > Peter Molettiere
> > > > Senior Engineer
> > > > Truereq, Inc.
> > > > http://www.truereq.com/
> > > >
> > > >
> > >
> > >
> > > --
> > > Davanum Srinivas - http://webservices.apache.org/~dims/
> > >
> > >
> > >
> > --
> > Peter Molettiere
> > Senior Engineer
> > Truereq, Inc.
> > http://www.truereq.com/
> >
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Axis - Out OF Memory problem
Posted by Nishant Kumar <ni...@itellix.com>.
One small question
In the ArrayDeserializer class there is an inner class
ArrayListExtension.
In the second constructor of this class, the one which takes length as
parameter, why do we create such a large array when the array we
normally use is of very small size. why don't we create an array of size
length.
thanks,
nishant
On Tue, 2005-01-18 at 09:49, Peter Molettiere wrote:
> We find that it's a straight 10 to 1 ratio between the in-memory
> representation and the memory used to serialize it, and this holds true
> for pretty much any size message. It's not a problem when you're
> dealing with 1 or 2 M of in-memory representation, since that runs to
> only 10 or 20M during serialization. I don't remember what the default
> heap size is off the top of my head, but it only takes a 7M in memory
> representation to exceed a 64M heap. Obviously 32 is even easier to
> break. This is the source of the common advice "raise your heap size"
> in response to all the messages posted to this list claiming out of
> memory exceptions during serialization.
>
> If you look back at my original jira bug posting, there's a test case
> which will let you configure a tree of arbitrary width and depth. Make
> a big one, and watch memory use during serialization in a profiler.
> Checkpoint it before and watch for the high water mark, and you'll see
> what I'm talking about.
>
> That bug was about memory leaks, and those seem to be mostly fixed.
> Anything left seems small enough that we can get 2 month up times now,
> which we're happy with. If you GC after you serialize you see gobs of
> memory being released.
>
> --Peter
>
> On Jan 17, 2005, at 11:25 AM, pawan.v.udernani@gsk.com wrote:
>
> >
> > Hi,
> >
> > Does anyone has an idea how "large" are we talking about ? Do we have
> > any data that says that it fails for certain size of objects, in terms
> > of bytes or Kbytes ? If yes, I can compare it to the size of data that
> > our webservice client consumes as of now.
> >
> >
> > Thanks,
> >
> > Pawan.
> >
> >
> >
> >
> >
> >
> > "Davanum Srinivas" <da...@gmail.com>
> >
> > 17-Jan-2005 14:21
> >
> > Please respond to axis-dev@ws.apache.org; Please respond to
> > dims@apache.org
> >
> >
> >
> >
> > To
> > axis-dev@ws.apache.org
> >
> > cc
> >
> > Subject
> > Re: Axis - Out OF Memory problem
> >
> >
> >
> >
> >
> >
> >
> > Peter,
> >
> > If possible, We'd like a test case with large object graphs to
> > reproduce the problem...So that we can make sure we can recreate the
> > problem and fix it as well.
> >
> > thanks,
> > dims
> >
> >
> > On Mon, 17 Jan 2005 10:44:09 -0800, Peter Molettiere
> > <pi...@axonstudios.net> wrote:
> > >
> > > Not sure what you'd like me to do. The method we're using to deal
> > with
> > > serializing large graphs of objects through axis is clearly
> > outlined in
> > > my previous posts. If there's something in particular you'd like us
> > to
> > > look at, let me know.
> > >
> > > Last night as I was falling asleep I realized I didn't mention
> > another
> > > possibility, though, so I may as well mention that here, too.
> > > Basically, if you're having trouble serializing large graphs of
> > > objects, then you can try re-writing your application to issue many
> > > small requests where you used to issue a single large request. The
> > most
> > > common recommendation seen is in response to people trying to
> > serialize
> > > large result sets. In that case it's pretty easy to send X rows, and
> > > request the next X rows in another request.
> > >
> > > Our application hasn't been so easily tamed, since we're serializing
> > > java object graphs, usually trees. We've talked about implementing a
> > > serialization scheme which would allow us to request any subtree of
> > > depth N from any given node, which would allow us to fetch our tree
> > > with a series of separate calls, but we've had a lot of other more
> > > important tasks, and the heap size and gc tweaks I've already
> > mentioned
> > > are working well enough for us at the moment.
> > >
> > > The other method we've been considering, since interop isn't much
> > of a
> > > requirement for us, is to implement a simple XML-RPC mechanism using
> > > standard XML serialization and plain vanilla HTTP servlets.
> > >
> > > --Peter
> > >
> > > On Jan 15, 2005, at 7:24 AM, Davanum Srinivas wrote:
> > >
> > > > Peter,
> > > >
> > > > anyway you can help us tune latest axis cvs?
> > > >
> > > > thanks,
> > > > dims
> > > >
> > > >
> > > > On Fri, 14 Jan 2005 14:04:31 -0800, Peter Molettiere
> > > > <pi...@axonstudios.net> wrote:
> > > >>
> > > >> On Jan 14, 2005, at 1:29 PM, pawan.v.udernani@gsk.com wrote:
> > > >>> Your mail provides a great deal of information. But, now I feel
> > > >>> trapped. Thanks anyways.
> > > >>
> > > >> /shrug/
> > > >>
> > > >> Try these, in this order:
> > > >>
> > > >> 0) Use the latest axis distro
> > > >> 1) Use xerces 2.6.2
> > > >> 2) Up your heap size: -Xmx768M -Xms128M -XX:+UseConcMarkSweepGC
> > > >>
> > > >> if the above don't work, then
> > > >>
> > > >> 3) Write your own SOAP engine.
> > > >>
> > > >> That's about the shape of it, I think.
> > > >>
> > > >> --
> > > >> Peter Molettiere
> > > >> Senior Engineer
> > > >> Truereq, Inc.
> > > >> http://www.truereq.com/
> > > >>
> > > >>
> > > >
> > > >
> > > > --
> > > > Davanum Srinivas - http://webservices.apache.org/~dims/
> > > >
> > > --
> > > Peter Molettiere
> > > Senior Engineer
> > > Truereq, Inc.
> > > http://www.truereq.com/
> > >
> > >
> >
> >
> > --
> > Davanum Srinivas - http://webservices.apache.org/~dims/
> >
> >
> >
> --
> Peter Molettiere
> Senior Engineer
> Truereq, Inc.
> http://www.truereq.com/
>
Re: Axis - Out OF Memory problem
Posted by Peter Molettiere <pi...@axonstudios.net>.
We find that it's a straight 10 to 1 ratio between the in-memory
representation and the memory used to serialize it, and this holds true
for pretty much any size message. It's not a problem when you're
dealing with 1 or 2 M of in-memory representation, since that runs to
only 10 or 20M during serialization. I don't remember what the default
heap size is off the top of my head, but it only takes a 7M in memory
representation to exceed a 64M heap. Obviously 32 is even easier to
break. This is the source of the common advice "raise your heap size"
in response to all the messages posted to this list claiming out of
memory exceptions during serialization.
If you look back at my original jira bug posting, there's a test case
which will let you configure a tree of arbitrary width and depth. Make
a big one, and watch memory use during serialization in a profiler.
Checkpoint it before and watch for the high water mark, and you'll see
what I'm talking about.
That bug was about memory leaks, and those seem to be mostly fixed.
Anything left seems small enough that we can get 2 month up times now,
which we're happy with. If you GC after you serialize you see gobs of
memory being released.
--Peter
On Jan 17, 2005, at 11:25 AM, pawan.v.udernani@gsk.com wrote:
>
> Hi,
>
> Does anyone has an idea how "large" are we talking about ? Do we have
> any data that says that it fails for certain size of objects, in terms
> of bytes or Kbytes ? If yes, I can compare it to the size of data that
> our webservice client consumes as of now.
>
>
> Thanks,
>
> Pawan.
>
>
>
>
>
>
> "Davanum Srinivas" <da...@gmail.com>
>
> 17-Jan-2005 14:21
>
> Please respond to axis-dev@ws.apache.org; Please respond to
> dims@apache.org
>
>
>
>
> To
> axis-dev@ws.apache.org
>
> cc
>
> Subject
> Re: Axis - Out OF Memory problem
>
>
>
>
>
>
>
> Peter,
>
> If possible, We'd like a test case with large object graphs to
> reproduce the problem...So that we can make sure we can recreate the
> problem and fix it as well.
>
> thanks,
> dims
>
>
> On Mon, 17 Jan 2005 10:44:09 -0800, Peter Molettiere
> <pi...@axonstudios.net> wrote:
> >
> > Not sure what you'd like me to do. The method we're using to deal
> with
> > serializing large graphs of objects through axis is clearly
> outlined in
> > my previous posts. If there's something in particular you'd like us
> to
> > look at, let me know.
> >
> > Last night as I was falling asleep I realized I didn't mention
> another
> > possibility, though, so I may as well mention that here, too.
> > Basically, if you're having trouble serializing large graphs of
> > objects, then you can try re-writing your application to issue many
> > small requests where you used to issue a single large request. The
> most
> > common recommendation seen is in response to people trying to
> serialize
> > large result sets. In that case it's pretty easy to send X rows, and
> > request the next X rows in another request.
> >
> > Our application hasn't been so easily tamed, since we're serializing
> > java object graphs, usually trees. We've talked about implementing a
> > serialization scheme which would allow us to request any subtree of
> > depth N from any given node, which would allow us to fetch our tree
> > with a series of separate calls, but we've had a lot of other more
> > important tasks, and the heap size and gc tweaks I've already
> mentioned
> > are working well enough for us at the moment.
> >
> > The other method we've been considering, since interop isn't much
> of a
> > requirement for us, is to implement a simple XML-RPC mechanism using
> > standard XML serialization and plain vanilla HTTP servlets.
> >
> > --Peter
> >
> > On Jan 15, 2005, at 7:24 AM, Davanum Srinivas wrote:
> >
> > > Peter,
> > >
> > > anyway you can help us tune latest axis cvs?
> > >
> > > thanks,
> > > dims
> > >
> > >
> > > On Fri, 14 Jan 2005 14:04:31 -0800, Peter Molettiere
> > > <pi...@axonstudios.net> wrote:
> > >>
> > >> On Jan 14, 2005, at 1:29 PM, pawan.v.udernani@gsk.com wrote:
> > >>> Your mail provides a great deal of information. But, now I feel
> > >>> trapped. Thanks anyways.
> > >>
> > >> /shrug/
> > >>
> > >> Try these, in this order:
> > >>
> > >> 0) Use the latest axis distro
> > >> 1) Use xerces 2.6.2
> > >> 2) Up your heap size: -Xmx768M -Xms128M -XX:+UseConcMarkSweepGC
> > >>
> > >> if the above don't work, then
> > >>
> > >> 3) Write your own SOAP engine.
> > >>
> > >> That's about the shape of it, I think.
> > >>
> > >> --
> > >> Peter Molettiere
> > >> Senior Engineer
> > >> Truereq, Inc.
> > >> http://www.truereq.com/
> > >>
> > >>
> > >
> > >
> > > --
> > > Davanum Srinivas - http://webservices.apache.org/~dims/
> > >
> > --
> > Peter Molettiere
> > Senior Engineer
> > Truereq, Inc.
> > http://www.truereq.com/
> >
> >
>
>
> --
> Davanum Srinivas - http://webservices.apache.org/~dims/
>
>
>
--
Peter Molettiere
Senior Engineer
Truereq, Inc.
http://www.truereq.com/
Axis (org.apache.axis APIs in Sample Vs Pure JAX-RPC/SAAJ APIs)
Posted by Rajdeep Dua <du...@yahoo.com>.
Hi
A lot of samples and tests in axis use org.apache.axis
APIs directly instead of JAX RPC and SAAJ APIs
(javax.xml.rpc , javax.xml.soap )
Is there any particular reason for this?
My experience with other APIS and their impls always
was the the clients/test cases access the impls
through APIs and not directly their implementation
classes
Why are we not using
javax.xml.rpc.Service myService = new
org.apache.axis.Service();
javax.xml.rpc.Call myCall = myService.createCall()
etc.
rgds
Rajdeep
__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
Re: Axis - Out OF Memory problem
Posted by pa...@gsk.com.
Hi,
Does anyone has an idea how "large" are we talking about ? Do we have any
data that says that it fails for certain size of objects, in terms of
bytes or Kbytes ? If yes, I can compare it to the size of data that our
webservice client consumes as of now.
Thanks,
Pawan.
"Davanum Srinivas" <da...@gmail.com>
17-Jan-2005 14:21
Please respond to axis-dev@ws.apache.org; Please respond to
dims@apache.org
To
axis-dev@ws.apache.org
cc
Subject
Re: Axis - Out OF Memory problem
Peter,
If possible, We'd like a test case with large object graphs to
reproduce the problem...So that we can make sure we can recreate the
problem and fix it as well.
thanks,
dims
On Mon, 17 Jan 2005 10:44:09 -0800, Peter Molettiere
<pi...@axonstudios.net> wrote:
>
> Not sure what you'd like me to do. The method we're using to deal with
> serializing large graphs of objects through axis is clearly outlined in
> my previous posts. If there's something in particular you'd like us to
> look at, let me know.
>
> Last night as I was falling asleep I realized I didn't mention another
> possibility, though, so I may as well mention that here, too.
> Basically, if you're having trouble serializing large graphs of
> objects, then you can try re-writing your application to issue many
> small requests where you used to issue a single large request. The most
> common recommendation seen is in response to people trying to serialize
> large result sets. In that case it's pretty easy to send X rows, and
> request the next X rows in another request.
>
> Our application hasn't been so easily tamed, since we're serializing
> java object graphs, usually trees. We've talked about implementing a
> serialization scheme which would allow us to request any subtree of
> depth N from any given node, which would allow us to fetch our tree
> with a series of separate calls, but we've had a lot of other more
> important tasks, and the heap size and gc tweaks I've already mentioned
> are working well enough for us at the moment.
>
> The other method we've been considering, since interop isn't much of a
> requirement for us, is to implement a simple XML-RPC mechanism using
> standard XML serialization and plain vanilla HTTP servlets.
>
> --Peter
>
> On Jan 15, 2005, at 7:24 AM, Davanum Srinivas wrote:
>
> > Peter,
> >
> > anyway you can help us tune latest axis cvs?
> >
> > thanks,
> > dims
> >
> >
> > On Fri, 14 Jan 2005 14:04:31 -0800, Peter Molettiere
> > <pi...@axonstudios.net> wrote:
> >>
> >> On Jan 14, 2005, at 1:29 PM, pawan.v.udernani@gsk.com wrote:
> >>> Your mail provides a great deal of information. But, now I feel
> >>> trapped. Thanks anyways.
> >>
> >> /shrug/
> >>
> >> Try these, in this order:
> >>
> >> 0) Use the latest axis distro
> >> 1) Use xerces 2.6.2
> >> 2) Up your heap size: -Xmx768M -Xms128M -XX:+UseConcMarkSweepGC
> >>
> >> if the above don't work, then
> >>
> >> 3) Write your own SOAP engine.
> >>
> >> That's about the shape of it, I think.
> >>
> >> --
> >> Peter Molettiere
> >> Senior Engineer
> >> Truereq, Inc.
> >> http://www.truereq.com/
> >>
> >>
> >
> >
> > --
> > Davanum Srinivas - http://webservices.apache.org/~dims/
> >
> --
> Peter Molettiere
> Senior Engineer
> Truereq, Inc.
> http://www.truereq.com/
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Axis - Out OF Memory problem
Posted by Davanum Srinivas <da...@gmail.com>.
Peter,
If possible, We'd like a test case with large object graphs to
reproduce the problem...So that we can make sure we can recreate the
problem and fix it as well.
thanks,
dims
On Mon, 17 Jan 2005 10:44:09 -0800, Peter Molettiere
<pi...@axonstudios.net> wrote:
>
> Not sure what you'd like me to do. The method we're using to deal with
> serializing large graphs of objects through axis is clearly outlined in
> my previous posts. If there's something in particular you'd like us to
> look at, let me know.
>
> Last night as I was falling asleep I realized I didn't mention another
> possibility, though, so I may as well mention that here, too.
> Basically, if you're having trouble serializing large graphs of
> objects, then you can try re-writing your application to issue many
> small requests where you used to issue a single large request. The most
> common recommendation seen is in response to people trying to serialize
> large result sets. In that case it's pretty easy to send X rows, and
> request the next X rows in another request.
>
> Our application hasn't been so easily tamed, since we're serializing
> java object graphs, usually trees. We've talked about implementing a
> serialization scheme which would allow us to request any subtree of
> depth N from any given node, which would allow us to fetch our tree
> with a series of separate calls, but we've had a lot of other more
> important tasks, and the heap size and gc tweaks I've already mentioned
> are working well enough for us at the moment.
>
> The other method we've been considering, since interop isn't much of a
> requirement for us, is to implement a simple XML-RPC mechanism using
> standard XML serialization and plain vanilla HTTP servlets.
>
> --Peter
>
> On Jan 15, 2005, at 7:24 AM, Davanum Srinivas wrote:
>
> > Peter,
> >
> > anyway you can help us tune latest axis cvs?
> >
> > thanks,
> > dims
> >
> >
> > On Fri, 14 Jan 2005 14:04:31 -0800, Peter Molettiere
> > <pi...@axonstudios.net> wrote:
> >>
> >> On Jan 14, 2005, at 1:29 PM, pawan.v.udernani@gsk.com wrote:
> >>> Your mail provides a great deal of information. But, now I feel
> >>> trapped. Thanks anyways.
> >>
> >> /shrug/
> >>
> >> Try these, in this order:
> >>
> >> 0) Use the latest axis distro
> >> 1) Use xerces 2.6.2
> >> 2) Up your heap size: -Xmx768M -Xms128M -XX:+UseConcMarkSweepGC
> >>
> >> if the above don't work, then
> >>
> >> 3) Write your own SOAP engine.
> >>
> >> That's about the shape of it, I think.
> >>
> >> --
> >> Peter Molettiere
> >> Senior Engineer
> >> Truereq, Inc.
> >> http://www.truereq.com/
> >>
> >>
> >
> >
> > --
> > Davanum Srinivas - http://webservices.apache.org/~dims/
> >
> --
> Peter Molettiere
> Senior Engineer
> Truereq, Inc.
> http://www.truereq.com/
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Axis - Out OF Memory problem
Posted by Peter Molettiere <pi...@axonstudios.net>.
Not sure what you'd like me to do. The method we're using to deal with
serializing large graphs of objects through axis is clearly outlined in
my previous posts. If there's something in particular you'd like us to
look at, let me know.
Last night as I was falling asleep I realized I didn't mention another
possibility, though, so I may as well mention that here, too.
Basically, if you're having trouble serializing large graphs of
objects, then you can try re-writing your application to issue many
small requests where you used to issue a single large request. The most
common recommendation seen is in response to people trying to serialize
large result sets. In that case it's pretty easy to send X rows, and
request the next X rows in another request.
Our application hasn't been so easily tamed, since we're serializing
java object graphs, usually trees. We've talked about implementing a
serialization scheme which would allow us to request any subtree of
depth N from any given node, which would allow us to fetch our tree
with a series of separate calls, but we've had a lot of other more
important tasks, and the heap size and gc tweaks I've already mentioned
are working well enough for us at the moment.
The other method we've been considering, since interop isn't much of a
requirement for us, is to implement a simple XML-RPC mechanism using
standard XML serialization and plain vanilla HTTP servlets.
--Peter
On Jan 15, 2005, at 7:24 AM, Davanum Srinivas wrote:
> Peter,
>
> anyway you can help us tune latest axis cvs?
>
> thanks,
> dims
>
>
> On Fri, 14 Jan 2005 14:04:31 -0800, Peter Molettiere
> <pi...@axonstudios.net> wrote:
>>
>> On Jan 14, 2005, at 1:29 PM, pawan.v.udernani@gsk.com wrote:
>>> Your mail provides a great deal of information. But, now I feel
>>> trapped. Thanks anyways.
>>
>> /shrug/
>>
>> Try these, in this order:
>>
>> 0) Use the latest axis distro
>> 1) Use xerces 2.6.2
>> 2) Up your heap size: -Xmx768M -Xms128M -XX:+UseConcMarkSweepGC
>>
>> if the above don't work, then
>>
>> 3) Write your own SOAP engine.
>>
>> That's about the shape of it, I think.
>>
>> --
>> Peter Molettiere
>> Senior Engineer
>> Truereq, Inc.
>> http://www.truereq.com/
>>
>>
>
>
> --
> Davanum Srinivas - http://webservices.apache.org/~dims/
>
--
Peter Molettiere
Senior Engineer
Truereq, Inc.
http://www.truereq.com/
Re: Axis - Out OF Memory problem
Posted by Davanum Srinivas <da...@gmail.com>.
Peter,
anyway you can help us tune latest axis cvs?
thanks,
dims
On Fri, 14 Jan 2005 14:04:31 -0800, Peter Molettiere
<pi...@axonstudios.net> wrote:
>
> On Jan 14, 2005, at 1:29 PM, pawan.v.udernani@gsk.com wrote:
> > Your mail provides a great deal of information. But, now I feel
> > trapped. Thanks anyways.
>
> /shrug/
>
> Try these, in this order:
>
> 0) Use the latest axis distro
> 1) Use xerces 2.6.2
> 2) Up your heap size: -Xmx768M -Xms128M -XX:+UseConcMarkSweepGC
>
> if the above don't work, then
>
> 3) Write your own SOAP engine.
>
> That's about the shape of it, I think.
>
> --
> Peter Molettiere
> Senior Engineer
> Truereq, Inc.
> http://www.truereq.com/
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: Axis - Out OF Memory problem
Posted by Peter Molettiere <pi...@axonstudios.net>.
On Jan 14, 2005, at 1:29 PM, pawan.v.udernani@gsk.com wrote:
> Your mail provides a great deal of information. But, now I feel
> trapped. Thanks anyways.
/shrug/
Try these, in this order:
0) Use the latest axis distro
1) Use xerces 2.6.2
2) Up your heap size: -Xmx768M -Xms128M -XX:+UseConcMarkSweepGC
if the above don't work, then
3) Write your own SOAP engine.
That's about the shape of it, I think.
--
Peter Molettiere
Senior Engineer
Truereq, Inc.
http://www.truereq.com/
Re: Axis - Out OF Memory problem
Posted by pa...@gsk.com.
Your mail provides a great deal of information. But, now I feel trapped.
Thanks anyways.
"Peter Molettiere" <pi...@axonstudios.net>
14-Jan-2005 14:31
Please respond to axis-dev@ws.apache.org
To
axis-dev@ws.apache.org
cc
"'dims@apache.org'" <di...@apache.org>, pawan.v.udernani@gsk.com
Subject
Re: Axis - Out OF Memory problem
> On Jan 14, 2005, at 9:18 AM, pawan.v.udernani@gsk.com wrote:
> Are there any know issues/bugs with Axis 1.1 related to XML parsing
> that might lead to Out of Memory problem. The JVM is going out of
> memory consistently now and our analysis is getting zeroed down to
> Axis framework classes. Is anyone aware of any open bug or has faced
> something similar ?
I brought up issues with Axis memory usage during serialization a while
ago, and several people posted to the list that they found leaks and
fixed them. I suspect there are still more, however, since our
application still runs into OOM errors. The situation is much improved
though: our uptime now runs to several months, where it used to only
get about a week.
Note that there are memory leaks in various xerces implementations. We
found upgrading xerces to 2.6.2 helped us out a lot.
There is also a separate issue: axis' pathological memory use during
serialization and deserialization. We see more than a 10 to 1 ratio of
memory use to encoded xml message size. So ser/deser in axis of a 30M
xml message easily uses more than 300M of memory during serialization.
For small messages this usually isn't noticed, but as your message size
grows, it becomes very onerous.
This does seem to be mostly released once serialization is done. This
can mostly be avoided by installing lots of RAM, setting your max heap
size very large, and using the concurrent mark and sweep gc algorithm.
We use:
-Xmx768M -Xms128M -XX:+UseConcMarkSweepGC
This algorithm does help to free some memory while axis is
(de)serializing, since it lets the collector run without completely
halting user code while it runs.
That approach only delays the inevitable, though. For our latest
project, I sat down to write a custom serializer hoping to be able to
deal with some of these issues, but after looking through the axis
source, it seemed to me that this pathological memory use issue is a
by-product of the axis architecture. Axis simply wasn't designed to
pass large messages.
The serialization/deserialization architecture requires both a large
object graph to represent the message structure, and another large
graph of (de)serializers. None of these are lightweight objects. We
also see an enormous number of char[]s created during serialization --
several orders of magnitude more than any other type.
I may be completely wrong, though, as I'm sure I haven't fully grokked
the axis serialization source, and there is precious little
documentation on it. The best I've found is the "encoding subsystem"
and "message model subsystem" here:
http://ws.apache.org/axis/java/architecture-guide.html.
There is nothing else to help you write your own serialization
mechanism, aside from a note in the Users' Guide
(http://ws.apache.org/axis/java/user-guide.html) suggesting a look at
the source for the Bean, Array, and other (De)Serializers.
That said, I did manage to get my own (de)serializer classes written,
although it took a couple weeks of pain and suffering in the debugger
to figure out why it didn't work the first time around. I haven't
actually benchmarked it yet to see how it performs, but I don't expect
it to do much better than the axis code, since it is plugged into that
architecture.
I think you'd need to write your own SerializationContext, which is a
substantial undertaking. When you also take into consideration that
most people seem to be writing services which pass small messages, you
can see why there hasn't been much attention paid to this memory use
issue.
--
Peter Molettiere
Senior Engineer
Truereq, Inc.
http://www.truereq.com/
Re: Axis - Out OF Memory problem
Posted by Peter Molettiere <pi...@axonstudios.net>.
> On Jan 14, 2005, at 9:18 AM, pawan.v.udernani@gsk.com wrote:
> Are there any know issues/bugs with Axis 1.1 related to XML parsing
> that might lead to Out of Memory problem. The JVM is going out of
> memory consistently now and our analysis is getting zeroed down to
> Axis framework classes. Is anyone aware of any open bug or has faced
> something similar ?
I brought up issues with Axis memory usage during serialization a while
ago, and several people posted to the list that they found leaks and
fixed them. I suspect there are still more, however, since our
application still runs into OOM errors. The situation is much improved
though: our uptime now runs to several months, where it used to only
get about a week.
Note that there are memory leaks in various xerces implementations. We
found upgrading xerces to 2.6.2 helped us out a lot.
There is also a separate issue: axis' pathological memory use during
serialization and deserialization. We see more than a 10 to 1 ratio of
memory use to encoded xml message size. So ser/deser in axis of a 30M
xml message easily uses more than 300M of memory during serialization.
For small messages this usually isn't noticed, but as your message size
grows, it becomes very onerous.
This does seem to be mostly released once serialization is done. This
can mostly be avoided by installing lots of RAM, setting your max heap
size very large, and using the concurrent mark and sweep gc algorithm.
We use:
-Xmx768M -Xms128M -XX:+UseConcMarkSweepGC
This algorithm does help to free some memory while axis is
(de)serializing, since it lets the collector run without completely
halting user code while it runs.
That approach only delays the inevitable, though. For our latest
project, I sat down to write a custom serializer hoping to be able to
deal with some of these issues, but after looking through the axis
source, it seemed to me that this pathological memory use issue is a
by-product of the axis architecture. Axis simply wasn't designed to
pass large messages.
The serialization/deserialization architecture requires both a large
object graph to represent the message structure, and another large
graph of (de)serializers. None of these are lightweight objects. We
also see an enormous number of char[]s created during serialization --
several orders of magnitude more than any other type.
I may be completely wrong, though, as I'm sure I haven't fully grokked
the axis serialization source, and there is precious little
documentation on it. The best I've found is the "encoding subsystem"
and "message model subsystem" here:
http://ws.apache.org/axis/java/architecture-guide.html.
There is nothing else to help you write your own serialization
mechanism, aside from a note in the Users' Guide
(http://ws.apache.org/axis/java/user-guide.html) suggesting a look at
the source for the Bean, Array, and other (De)Serializers.
That said, I did manage to get my own (de)serializer classes written,
although it took a couple weeks of pain and suffering in the debugger
to figure out why it didn't work the first time around. I haven't
actually benchmarked it yet to see how it performs, but I don't expect
it to do much better than the axis code, since it is plugged into that
architecture.
I think you'd need to write your own SerializationContext, which is a
substantial undertaking. When you also take into consideration that
most people seem to be writing services which pass small messages, you
can see why there hasn't been much attention paid to this memory use
issue.
--
Peter Molettiere
Senior Engineer
Truereq, Inc.
http://www.truereq.com/