On 06.05.2008 10:14:03 Jeremias Maerki wrote: > 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.
I've done that now: http://svn.apache.org/viewvc?rev=653704&view=rev Jean-Fraçois, please download XG Commons Trunk, build it and switch to it. Then set -Dorg.apache.xmlgraphics.image.loader.impl.AbstractImageSessionContext.no-source-reuse=true (system property). Hopefully, this will change something. Please let me know if it does. > 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]
