There is a Denial of Service attack you can make against Axis by sending a huge array size in the SOAP request. Then we used to allocate all that memory, which is bad.
I believe I changed this a year or more ago to prevent this D.O.S. We will grow the memory if needed. If the code doesn't check the passed in size against the default size, then this would be a bug... I don't have the code in front of me, check the revision history in CVS. Tom Jordahl Macromedia Server Development -----Original Message----- From: Nishant Kumar [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 18, 2005 5:49 AM To: axisdev Subject: Re: Axis - Out OF Memory problem 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, [EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> > > > > 17-Jan-2005 14:21 > > > > Please respond to [email protected]; Please respond to > > [EMAIL PROTECTED] > > > > > > > > > > To > > [email protected] > > > > 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 > > <[EMAIL PROTECTED]> 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 > > > > <[EMAIL PROTECTED]> wrote: > > > >> > > > >> On Jan 14, 2005, at 1:29 PM, [EMAIL PROTECTED] 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/ >
