xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeroen van der Vegt <jeroen.van.der.v...@technolution.nl>
Subject Re: Dynamic charts issues in batch PDF generation
Date Fri, 20 Jan 2006 14:28:25 GMT
I'm not sure I correctly understand the problem anymore, but this might 
be relevant:

Can't you let the JPEG servlet indicate that its output should not be 
cached? I use this code to disable various cache mechanism:

    private void setNoCache(HttpServletResponse resp) {
        resp.setDateHeader("Expires", 0 );



Op 19-1-2006 22:11, schreef Glen Mazza:
> Clay Leeds escribió:
>> On Jan 19, 2006, at 10:30 AM, Glen Mazza wrote:
>>> Jeremias Maerki wrote:
>>>> Or you need to simply make sure that the URLs are unique. You can  
>>>> use a
>>>> dummy parameter in the URL to fake uniqueness:
>>>> http://localhost/MyChartServlet?dummy=1234
>>> Hmmm...my guess is that for any servlet-related problem for which a  
>>> "dummy parameter to fake uniqueness" would solve it, that the  
>>> servlet itself can be rewritten to fix the problem instead.  (In  
>>> this case, have it coded to regenerate the image for every call,  
>>> with no dummy parameter needed.)  If I'm correct, I would refer the  
>>> questioner to the Sun Servlet forum for more assistance.
>>> Glen
>> In my experience (mainly coming from a background where the user- 
>> agent tends to be a web browser), if you call the same thing twice,  
>> there are a number of places where the object being served can be  
>> 'cached':
>> - server
>> - proxy
>> - client
> Oh.  My interpretation of the problem was that a different PDF 
> document *was* indeed being returned each time, but that the charts 
> within the PDF document were incorrectly not being regenerated to 
> account for the new data specific to each document.  If my assumption 
> was the case, that would tend to rule out caching at the client or the 
> proxy, because AFAIK they would just have a PDF document to cache (not 
> inner parts, such a graphics within the PDF).
> But if it is the case that the *same* PDF document is being sent each 
> time to the browser, then yes, the caching may be at the client or 
> proxy-level, and the URL modifying may be necessary.
> Glen
>> In some cases, the server itself also might have some sort of  
>> 'caching' system as well, which is external to the server.
>> If someone is calling a cacheable resource, I've found it safest to  
>> somehow modify the name (even slightly) to ensure there's no caching  
>> involved. IMO, this alleviates the potential of cacheability (making  
>> words up can be fun!).
>> Web Maestro Clay

To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org

View raw message