cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko (JIRA)" <j...@apache.org>
Subject [jira] Commented: (COCOON-1658) Somewhere output is held...
Date Wed, 26 Oct 2005 12:58:59 GMT
    [ http://issues.apache.org/jira/browse/COCOON-1658?page=comments#action_12355965 ] 

Vadim Gritsenko commented on COCOON-1658:
-----------------------------------------

(where is reply button in jira?)

> So, my question is why is the buffer right now set to "unlimited"?
> Is there any specific caveat for this?

If you are using caching pipeline then complete response will have to be buffered in any case.
For non caching pipelines, complete response will have to be buffered if serializer requires
content length to be set. For all other cases... I think this outputBuffer is not really needed.

> 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


Mime
View raw message