[
https://issues.apache.org/jira/browse/WICKET-4113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13131553#comment-13131553
]
Adam Pierzchała edited comment on WICKET-4113 at 10/20/11 12:27 PM:
--------------------------------------------------------------------
Unfortunately, your fix will not work for files that exceed buffer size. At
least on Tomcat and with liferay 5.2.3
What I managed to trace is that response is wrapped several times. Before
calling include(request, response) on request dispatcher in WicketPorltet, the
wrappers look like that:
-response = com.liferay.portal.servlet.AbsoluteRedirectsResponse
--reponse = org.tuckey.web.filters.urlrewrite.UrlRewriteWrappedResponse
---response = org.apache.catalina.connector.ResponseFacade
inside include(request,response) method, ResponseFacade is wrapped with yet
another one wrapper - org.apache.catalina.core.ApplicationHttpResponse, and
after include(...) this wrapper is removed. If file is small enough, flush()
will not be called in include method, so the content type will be set correctly
when entering responseState.flushAndClose(); few lines below in WicketPortlet.
But in case when file is bigger than buffer size, flush() is called inside
include(...) method, which means that ApplicationHttpResponse wrapper will
ignore all attempts to set headers.
Sorry, my response looks quite complicated, please tell me if I'm not clear
somewhere
was (Author: apierzch):
Unfortunately, with your fix will not work for files that exceed buffer
size. At least on Tomcat and with liferay 5.2.3
What I managed to trace is that response is wrapped several times. Before
calling include(request, response) on request dispatcher in WicketPorltet, the
wrappers look like that:
-response = com.liferay.portal.servlet.AbsoluteRedirectsResponse
--reponse = org.tuckey.web.filters.urlrewrite.UrlRewriteWrappedResponse
---response = org.apache.catalina.connector.ResponseFacade
inside include(request,response) method, ResponseFacade is wrapped with yet
another one wrapper - org.apache.catalina.core.ApplicationHttpResponse, and
after include(...) this wrapper is removed. If file is small enough, flush()
will not be called in include method, so the content type will be set correctly
when entering responseState.flushAndClose(); few lines below in WicketPortlet.
But in case when file is bigger than buffer size, flush() is called inside
include(...) method, which means that ApplicationHttpResponse wrapper will
ignore all attempts to set headers.
Sorry, my response looks quite complicated, please tell me if I'm not clear
somewhere
> Whole response is cached in memory
> ----------------------------------
>
> Key: WICKET-4113
> URL: https://issues.apache.org/jira/browse/WICKET-4113
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.18
> Reporter: Adam Pierzchała
> Priority: Critical
>
> In class {{org.apache.wicket.protocol.http.portlet.WicketResponseState}}
> there is used {{CharArrayWriterBuffer}} and {{ByteArrayOutputStream}} to
> cache in memory whole response.
> This creates issues with Java heap space when downloading big files:
> {noformat}
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:70)
> at
> org.apache.wicket.protocol.http.portlet.WicketResponseState$1.write(WicketResponseState.java:439)
> at java.io.OutputStream.write(OutputStream.java:99)
> {noformat}
> I think there should be used stream implementation that caches big data
> amounts on disk e.g. {{org.apache.cxf.io.CachedOutputStream}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
