Hi Ajith, Thanks for the tip, which is perfect except for one little problem. I now seem to be able to handle 30 MB payloads (although I need to do some memory profiling to verify for sure). The only problem is that setParent() is not exposed as a method in the OMElement interface. I need to cast to the concrete impl class as such:
OMElement oe = builder.getDocumentElement(); org.apache.axiom.om.impl.llom.OMElementImpl oei = (org.apache.axiom.om.impl.llom.OMElementImpl) oe; oei.setParent(null); So either the setParent() method needs to be added to the interface or a fix needs to be made somewhere else in the internal processing of the payload. I prefer the first option (perhaps in addition to the second). I think a bug submission needs to be made to JIRA, but I'll defer to you if you prefer. Regards, Gary -----Original Message----- From: Ajith Ranabahu [mailto:[EMAIL PROTECTED] Sent: Thursday, June 29, 2006 9:42 AM To: [email protected] Subject: Re: [Axis2] unable to turn off Axiom OMElement caching in client Hi Gary, Hmm... this seems like an issue we need to look into. I'm not sure whether the caching flag is useful any more (it is a left over from one of the previous features AFAIK). Just try this and see whether it works. Just before return oe, add a statement oe.setParent(null); that should avoid any building of the tree Ajith On 6/29/06, Gordon, Gary <[EMAIL PROTECTED]> wrote: > > > > > (Reposting earlier message but with [Axis2] in subject line hoping someone > else will read this). > > > > For a ServiceClient, you must produce an OMElement for the SOAP body, but I > don't see a way to write a client that doesn't build the whole OM object > tree for the payload. I run out of memory for a large payload. If I set > caching to false as follows, the Axiom code infinite loops: > > > > public OMElement getPayload(InputStream is) throws XMLStreamException { > > XMLInputFactory xif = XMLInputFactory.newInstance(); > > XMLStreamReader reader = xif.createXMLStreamReader(is); > > StAXOMBuilder builder = new StAXOMBuilder(reader); > > builder.setCache(false); > > OMElement oe = builder.getDocumentElement(); > > return oe; > > } > > > > This is caused by the following sequence of calls in Axiom, wherein the > document element is never set to a non-null value because caching is on. > > > > OMDocumentImpl: > > public OMElement getOMDocumentElement() { > > while (documentElement == null) { > > parserWrapper.next(); > > } > > return documentElement; > > } > > > > StAXOMBuilder: > > public int next() throws OMException { > > try { > > if (done) { > > throw new OMException(); > > } > > int token = parser.next(); > > if (!cache) { > > return token; > > } > > > > ..etc. > > > > Now if I comment out the call to turn off caching, Axiom merrily goes along > and builds the entire OM tree, so I run out of memory for large documents. > This is because > > > > OMElement result = sender.sendReceive(payload); > > > > eventually calls: > > ServiceClient.fillSOAPEnvelope() > > > > which eventually leads to: > > OMElementImpl.detach(); > > > > The detach() causes the whole tree to be rendered as OMObjects. For a > similar server-side question that was asked, the Axis person suggested > looking at the OMDatasource test code, but looking at this seemed to yield > nothing relevant unless I'm missing something. > > > > Any suggestions on how to efficiently handle a large client-side payload > using Axiom? Is this a bug that should be submitted? > > > > > > Gary Gordon > > > > > > > > Gary Gordon > > R&D Fellow > > Software AG, Inc. > > -- Ajith Ranabahu --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
