Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] OutOfMemoryError

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <wolfgang.hoschek AT mac.com>
  • To: Elliotte Harold <elharo AT metalab.unc.edu>
  • Cc: xom-interest AT lists.ibiblio.org, m AT lhaza.com
  • Subject: Re: [XOM-interest] OutOfMemoryError
  • Date: Fri, 20 Jan 2006 16:16:37 -0800

On Jan 20, 2006, at 3:09 PM, Elliotte Harold wrote:

Wolfgang Hoschek wrote:

I guess there's no SAX property that would force the underlying parser to limit character() chunks to <= X bytes. So no guarantee can be given that an OOM error can be avoided. Even if there's no error with parser X today, it might be different with a different parser, or with a different version.

The limits of Java set a theoretical limit of 2.1 GB per call. In practice I've never seen a parser go over 64K per call.

Plus, what about very large base64 comment nodes?

XOM makes one Comment object per SAX comment() invocation. In this case XOM would split the comment up into multiple pieces. The problem here is that it's pretty much impossible to distinguish between two adjacent comments and one long comment; at least without a lot of knowledge about exactly how much text the parser is likely to stuff in a comment.

I still believe that such an unusual use case is best dealt with by a custom SAX content handler, rather than at the XOM level. Too much additional complexity for too little additional value.

Possibly. So far only one person has asked for this. If two people ask for it, I get a little more interested. However this does look like a plausible use case; and it does bother me that XOM can't handle it and SAX can. This contrasts with implausible cases like element names that are two large for a String, which neither XOM nor SAX can handle.

Your points about MIME multiparts are well-taken. However there's work underway to expose these through XOP (not a typo) as an XML document in which the binary parts are base-64 encoded on the fly. I'd like to be able to handle this.

I presume that's going to come in the form of an (optional) byte based SAX signature such as

void bytes(byte[] src, int offset, int length)

or similar. With a fallback to the character version if no byte handler is present. Right?

Wolfgang.




Archive powered by MHonArc 2.6.24.

Top of Page