xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: Major issue with image loading in FOP 0.95beta
Date Tue, 06 May 2008 08:14:03 GMT
On 05.05.2008 23:39:15 Jean-François El Fouly wrote:
> Andreas Delmelle a écrit :
> > For now, you also spoke about the requests "suffocating" the server. 
> > Do you mean that there are also a lot /more/ requests, or only that 
> > they take longer to process on the FOP-side? If you also have an 
> > increase in the total number of requests, this could mean that the 
> > image-loading framework (unnecessarily?) tries to access the same 
> > images multiple times, which may already provide a pointer as to where 
> > to start looking in the code.
> >
> No, but the behaviour looks very different in the server traces.
> FOP 0.94: a sequence of : one request / one response / one request / one 
> response etc.
> with constant (server) response time seen in the server logs.
> Same application with FOP 0.95beta: seems to launch a whole bunch of 
> requests at the same time, say 5..10.15.. requests for different images 
> seen at the same time in the logs. And more a few seconds later.
> Now the way we interpret the SVN server logs is that the corresponding 
> responses are consumed slower and slower and the SVN server response 
> time traced in the logs is growing in a linear way until it reaches the 
> server timeout (300 s = 5 min. was the default). Then the SVN server 
> supposes nobody's listening to an answer and somehow closes the 
> connection. And then FOP on the other side crashes immediately.
> Looks somehow like someone very hungry ordering 10 plates at the same 
> time in a restaurant and eating slowly. Until the waiter gives up. (If 
> you forgive me the comparison.)

I've just re-read that and it suddenly made me think: could it be that
you produce really large FO documents (not many smaller ones) with many
images and the effect here is simply the timeout of the HTTP connection because
it is kept open after preloading the image? I'll add a system property
to the image loader framework so you can disable the stream reusage.
That could work around the problem. For a longer-term solution I see two
1. Add a hint to fo:external-graphic that a URL is dynamic and that the
stream should be reused. Otherwise, it is closed immediately and
reopened when the full image is read. That idea is not new but never got
2. Add some intelligence to the stream cache so it closes the stream if
it is not rerequested within a given time frame to avoid timeouts.

Jeremias Maerki

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

View raw message