[Axis2] unable to turn off Axiom OMElement caching in client

["Gordon, Gary" <Ga...@softwareagusa.com>]

(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.

 

Re: [Axis2] unable to turn off Axiom OMElement caching in client

[Ajith Ranabahu <aj...@gmail.com>]

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 <Ga...@softwareagusa.com> 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: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org