Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <590278274.1130353135931.JavaMail.jira@ajax.apache.org>
Date: Wed, 26 Oct 2005 20:58:55 +0200 (CEST)
From: "Pier Fumagalli (JIRA)" <jira@apache.org>
To: dev@cocoon.apache.org
Subject: [jira] Closed: (COCOON-1658) Somewhere output is held...
In-Reply-To: <1795906409.1130257195847.JavaMail.jira@ajax.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ http://issues.apache.org/jira/browse/COCOON-1658?page=all ]
     
Pier Fumagalli closed COCOON-1658:
----------------------------------

    Resolution: Invalid

For some odd reason, I never saw the prominent documentation in the Cocoon sitemap:

If not specified, the value of the outputBufferSize parameter is -1. This will cause Cocoon to buffer all output until processing has finished before sending it to the client...

> Somewhere output is held...
> ---------------------------
>
>          Key: COCOON-1658
>          URL: http://issues.apache.org/jira/browse/COCOON-1658
>      Project: Cocoon
>         Type: Bug
>   Components: * Cocoon Core
>     Versions: 2.1.8-dev (Current SVN)
>     Reporter: Pier Fumagalli
>     Priority: Critical

>
> Cocoon standard, as of right now, built without any blocks.
> I modify the default sitemap adding one simple entry:
>     <map:match pattern="bigtest">
>       <map:generate src="bigtest.xml"/>
>       <map:serialize type="xml"/>
>     </map:match>
> The file "bigtest.xml" is a 100Mb XML file that I simply want to generate and serialize (minimal test, no transformers that can do anything weird).
> I then open my terminal and do a "curl http://localhost:8888/bigtest > /dev/null", to have an idea of the thrughput for this file.
> Apparently, the output is held for roughly 25 seconds, nothing comes out, no bytes are serialized. All of a sudden, the entire 100 megabytes are serialized in one big lump (and it takes 5 seconds to do so).
> This happens if the pipeline is configured as being "caching" or "noncaching" (nothing changes).
> In the first 25 seconds, the JVM running Cocoon uses 100% of my processor (so, it's doing something), and the TOP shows something _really_ strange.
> My JVM grows of roughly 200 megabytes in size (note, I start Cocoon, post the big request, close cocoon).
> This is a trace from my TOP:
>   PID COMMAND      %CPU   TIME   #TH #PRTS #MREGS RPRVT  RSHRD  RSIZE  VSIZE
> -----------------------------------------------------------------------------
> 12498 java         0.1%  0:03.01  19   357   240  25.1M  28.7M  25.4M   735M
> 12498 java        87.2%  0:06.22  19   403   242  54.2M+ 28.7M  55.1M+  735M-
> 12498 java        75.7%  0:10.88  19   403   242  78.3M  28.7M  79.2M   735M
> 12498 java        80.2%  0:14.78  19   403   242   129M  28.7M   130M   735M
> 12498 java        84.3%  0:19.77  19   403   242   168M+ 28.7M   169M+  735M
> 12498 java        77.4%  0:23.67  19   403   242   231M  28.7M   232M   735M
> 12498 java        40.7%  0:27.92  19   403   242   231M+ 28.7M   232M+  735M+
> 12498 java         0.1%  0:28.18  20   408   245   231M  28.7M   232M   735M
> Something tells me that we are indeed caching all the content in a big char[] (100 megabytes of US-ASCII text are 200 megabytes when stored in a char[]).
> Any clue on where this can happen? It's impairing our ability to serve bigger feeds (aka, 2 gigs! :-P)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira