cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Igor Naumov (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (COCOON-2139) Corrupted XML content with cocoon: protocol and caching
Date Wed, 10 Oct 2007 20:19:51 GMT

    [ https://issues.apache.org/jira/browse/COCOON-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533860
] 

igorn edited comment on COCOON-2139 at 10/10/07 1:18 PM:
---------------------------------------------------------------

test.zip is a sample setup to reproduce the issue - https://issues.apache.org/jira/secure/attachment/12367517/test.zip

rawdata.xml is the initial data file, the specific behavior seems to depend on it's size and
structure.

sitemap defines two pipelines:
testData - cached pipeline that serves rawdata.xml 
result - XInclude operation to include cocoon:/testData result and then apply the filter to
show the effect.

The filtering looks for elements in the result that have non-numeric values, since all the
attributes in the source file are numeric.

Put the files into a cocoon instance (e.g. /test directory at the top level).
then open URL http://<your-server>:<port>/test/result
First time (when the cache is empty), it should return a single empty <filteredResult/>
tag.
This is the expected behavior.

Then refresh the page in the browser to hit it a second time. At this time several <stat>
elements are returned.
Check their attributes - some of them will have random non-numeric values.
Once you clear the cache, you will get a single empty <filteredResult/> tag first time
again, and some corrupted XML after that.


      was (Author: igorn):
    This is a sample setup to reproduce the issue.

rawdata.xml is the initial data file, the specific behavior seems to depend on it's size and
structure.

sitemap defines two pipelines:
testData - cached pipeline that serves rawdata.xml 
result - XInclude operation to include cocoon:/testData result and then apply the filter to
show the effect.

The filtering looks for elements in the result that have non-numeric values, since all the
attributes in the source file are numeric.

Put the files into a cocoon instance (e.g. /test directory at the top level).
then open URL http://<your-server>:<port>/test/result
First time (when the cache is empty), it should return a single empty <filteredResult/>
tag.
This is the expected behavior.

Then refresh the page in the browser to hit it a second time. At this time several <stat>
elements are returned.
Check their attributes - some of them will have random non-numeric values.
Once you clear the cache, you will get a single empty <filteredResult/> tag first time
again, and some corrupted XML after that.

  
> Corrupted XML content with cocoon: protocol and caching
> -------------------------------------------------------
>
>                 Key: COCOON-2139
>                 URL: https://issues.apache.org/jira/browse/COCOON-2139
>             Project: Cocoon
>          Issue Type: Bug
>          Components: * Cocoon Core
>    Affects Versions: 2.1.9
>            Reporter: Igor Naumov
>         Attachments: test.zip
>
>
> I ran into a very tricky and frustrating issue with caching pipelines using cocoon: protocol.
> It appears that when a result of a pipeline is retrieved from cache, the XML is "corrupted"
in a strange way (e.g. attributes have random values they are not expected to have).
> I am using Cocoon 2.1.9 under Jetty (local server), with Saxon 8. Other components used
in the sample setup are ExpiresCachingProcessingPipeline and XInclude.
> The test case is set up as follows (I will attach all the files or provide a link to
download):
> 1. A caching pipeline (using ExpiresCachingProcessingPipeline) returns a fairly large
XML document straight from a local file. 
> 2. Another pipeline (noncaching) is using XInclude to embed a result of the pipeline
#1 (through cocoon: URL) into the result document.
> 3. A simple XSL filter is applied at the end of pipeline #2 to show the damaged XML elements.
> When the pipeline #2 is called for the first time, everything works ok. At this time
pipeline #1 result is cached.
> When the pipeline #2 is called for the second time, the XML returned by cocoon: URL is
different from the first call - some attributes are changed with a random data which seems
to come form other places in the stream (like element names).
> XInclude may not be the primary suspect, I tried CInclude with similar effects. 
> Disabling caching on pipeline #1 seems to eliminate the problem, changing cocoon: protocol
to http: seems to fix it as well.
> The most frustrating part is that although the bug can be reproduced reliably with particular
sitemap and source files, the actual effect seems to depend on the source XML (less likely
to occur with smaller initial data sets).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message