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 possibilities: 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 realized. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
