[
https://issues.apache.org/jira/browse/WICKET-3357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987216#action_12987216
]
Peter Ertl edited comment on WICKET-3357 at 1/26/11 4:09 PM:
-------------------------------------------------------------
>From the two invocation of IResourceStream's constructor the the first one is
>from WicketFilter to invoke resourceStream.getLastModified(). This is required
>to support the 'If-Modified-Since' http request header. The second invocation
>is while creating the actual http response containing the resource data.
None of these calls can be omitted without breaking the current behavior of
wicket 1.4.
In wicket 1.5 things are handled different and the problem does not exist
anymore.
The possible theoretical approaches to solve this in 1.4 would be either
- cache the resource stream: this would be too expensive as instances of
resource streams can be huge (like megabytes of data)
- refactor IResource to access getLastModified() without resource creation:
this is not possible without breaking the current API of 1.4. That would
contradict the concept of "drop-in-replacements" within one wicket minor
release and is unacceptable.
So you can only solve that issue by
- defer expensive actions to the invocation of IResourceStream.getInputStream()
- in case of using AbstractResourceStreamWriter (@Brad: like in your
quickstart) this would instead be in
AbstractResourceStreamWriter.write(OutputStream)
- add some custom caching
- switch to wicket 1.5
I would suggest switching to 1.5 if you can since we have a good number of
improvements to offer in 1.5 in that case. Especially you could avoid repeated
creation of your (expensive) resource. By using our new resource caching
support a public cache, proxy server or the browser cache could store your
resource effectively. You can still invalidate the resource easily without
having stale caches. So your resource would be served from the cache on the
subsequent request and does not even hit the java application server.
was (Author: pete):
From the two calls to IResourceStream.getResourceStream() the first one is
from WicketFilter to invoke resourceStream.getLastModified(). This is required
to support the 'If-Modified-Since' http request header. The second call is the
actual request of the resource data generating the http response.
None of these calls can be omitted without breaking the current behavior of
wicket 1.4.
In wicket 1.5 things are handled different and the problem does not exist
anymore.
The possible theoretical approaches to solve this in 1.4 would be either
- cache the resource stream: this would be too expensive as instances of
resource streams can be huge (like megabytes of data)
- refactor IResource to access getLastModified() without resource creation:
this is not possible without breaking the current API of 1.4. That would
contradict the concept of "drop-in-replacements" within one wicket minor
release and is unacceptable.
So you can only solve that issue by
- defer expensive actions to the invocation of IResourceStream.getInputStream()
- in case of using AbstractResourceStreamWriter (@Brad: like in your
quickstart) this would instead be in
AbstractResourceStreamWriter.write(OutputStream)
- add some custom caching
- switch to wicket 1.5
I would suggest switching to 1.5 if you can since we have a good number of
improvements to offer in 1.5 in that case. Especially you could avoid repeated
creation of your (expensive) resource. By using our new resource caching
support a public cache, proxy server or the browser cache could store your
resource effectively. You can still invalidate the resource easily without
having stale caches. So your resource would be served from the cache on the
subsequent request and does not even hit the java application server.
> Resource getResourceStream called twice with single request
> -----------------------------------------------------------
>
> Key: WICKET-3357
> URL: https://issues.apache.org/jira/browse/WICKET-3357
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4.15
> Environment: Tomcat on Windows 7. Jetty on Ubuntu Linux..
> Reporter: Brad Grier
> Assignee: Peter Ertl
> Fix For: 1.5-RC2
>
> Attachments: myproject.zip
>
>
> getResourceStream is being called multiple times for Resource subclasses used
> to create dynamic images and/or textual data. This can be extremely
> inefficient depending on the work required to generate the resource. In my
> case, it presents a more serious problem because data inserted in the
> overriden getResourceStream method is duplicated in the database.
> The attached quickstart creates a dynamic image in getResourceStream. The
> method is called twice for a single request.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
