cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Corin Moss" <>
Subject RE: Issue in XMLByteStreamInterpreter with large files
Date Tue, 09 Mar 2004 08:41:51 GMT
Hi All,

I've made some interesting progress on this issue.   It seems on closer
inspection, that these errors are actually caused by badly formed XML
documents.  The errors are somewhat generic in nature.  What is really
interesting is that the XML documents are only badly formed when cached
(they seem to be fine at generation time.)

I have an RDF tree which is made up of a series of more granular RDF
documents.  At the highest level (an aggregate of ~100 documents) I see
a broken document.  When I go down to the specific RDF:Description block
which is broken and call the generating XSP directly, it is fine.  When
I go to the "middle"  I see a broken document.  The structure is
represented like this:

-1st tier, cached aggregation of lower tiers
    -2nd tier, cached aggregation of lower tiers
        -3rd tier - individual "record"
        -3rd tier - individual "record"
        -3rd tier - individual "record"
    -2nd tier, cached aggregation of lower tiers
        -3rd tier - individual "record"
        -3rd tier - individual "record"

In this example tiers 1 and 2 are invalid documents, but 3 is always
valid.  What seems to be happening is the the 2nd tier is caching a
broken document, and the 1st tier is then caching the 2nd tier, which is
of course broken.  When I clear the cache for this key - it will (in
most cases) then be fine on subsequent re-generation.

After tracing back through some classes, I've that the outputBufferSize
attribute of a pipeline might have some effect here, so I tuned it to be
10k.  The issue is now all but gone, (so far ;) and pipeline requests
are up to 5 times faster to generate.

I shall keep investigating - but I'd appreciate any comments on my
findings so far, I'd be happy to clarify anything :)



 ---Original Message-----
From: Corin Moss 
Sent: Tuesday, 9 March 2004 5:27 p.m.
Subject: Issue in XMLByteStreamInterpreter with large files

Hi All, 
I've recently run into a brand new issue related to the above class,
seemingly when it's used in conjunction with the TraxTransformer (in my
case Xalan.)
What seems to be happening is that the deserialize method is not being
passed a byte array (it's throwing the "XMLDeserializer needs byte array
for deserialization" error.)
This is usually recrea  table for the lifetime of the Cocoon instance,
in most cases as soon as Tomcat is restarted the problem disappears.
However, on some occasions, repeated re-requests of the pipeline _can_
result in a successful generation.
This is a fairly large document (>1MB), with many name-spaces defined.
I'm using v1.5 of the class, which supports long character events, but
doesn't have the license changes - although I'm sure that's not causing
an issue ;)
The really interesting part, is that this error is thrown BEFORE we ever
put the document through Xalan in the pipeline, although I guess that
there could be an internal Cocoon process which is using Xalan for
something and then throwing this error.
Has anyone else seen this particular problem? 

Corin Moss 
Lead Developer 
TVNZ Interactive 
+64 9 916 7367 
+64 21 403 054 

CAUTION: This e-mail and any attachment(s) contains information
that is intended to be read only by the named recipient(s). It
may contain information that is confidential, proprietary or the
subject of legal privilege. This information is not to be used by
any other person and/or organisation. If you are not the intended
recipient, please advise us immediately and delete this e-mail
from your system. Do not use any information contained in it.

For more information on the Television New Zealand Group, visit
us online at

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message