[jira] Issue Comment Edited: (WICKET-3357) Resource getResourceStream called twice with single request

["Peter Ertl (JIRA)" <ji...@apache.org>]

    [ 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.