[ 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
