[xep-support] Re: How often does XEP.BAT use my graphic-URL?

[Vladyslav Sivyakov]

Hello Fritz,

Your media server controls the expiration policy of your media files. 
The HTTP "Expires:" header is in charge of telling the HTTP client when 
the file is to be re-requested.

I've failed check it myself because mrq12.it2media.de:8081 may not be 
accessible from the outside, but could it be that the HTTP server 
returns a bogus "Expires:" header (e.g. if it has a wrongly set system 
clock) or does not return it at all?

To verify, please simply call the following and see the console output:

curl -D - 
http://mrq12.it2media.de:8081/mr/v01/~~~200/mediafile/id/41511906/filetype/pdf?mimetype=true

Best regards,
Vladyslav Y. Sivyakov, RenderX.

On 03.08.2020 10:19, Kirch Fritz wrote:
>
> Hello Vladyslav,
>
> thank you for your quick answer, but let us concentrate on the small 
> example fo-file!
>
> It has only 1 external-graphic.
>
> I can understand, that throughout the formatting process, XEP has to 
> retrieve various information about the external resource.
>
> But referring to my small example, why does this retrieval process 
> read the one and only graphic file 3 times?
>
> Are there any reasons why the rendering process doesnt use the TMPDIR 
> for caching purposes?
>
> Please apologize my perseverance in getting an answer, but my media 
> server is called 100.000 times a day for providing graphic files.
>
> If there is a small chance to reduce the number of calls, I will be happy.
>
> Fritz
>
> *Von:*Xep-support <xep-support-bounces at renderx.com> *Im Auftrag von 
> *Vladyslav Sivyakov
> *Gesendet:* Freitag, 31. Juli 2020 21:02
> *An:* xep-support at renderx.com
> *Betreff:* [xep-support] Re: How often does XEP.BAT use my graphic-URL?
>
> Hello Fritz,
>
> Throughout the formatting process, XEP retrieves various information 
> about the external resources, like dimensions.
>
> Caching the entire content is problematic because in large documents, 
> the total size of external resources would make the Java environment 
> on a formatting machine quickly run out of memory.
>
> There is a standard solution for that -- XML Catalogs. You make a 
> local copy of frequently-used resources and configure a Catalog 
> Resolver do the job. Simple ones simply return local files (file:) 
> instead of those located on remote (http:) computers, but nothing 
> prevents from implementing your own sophisticated one that has some 
> timed-cache strategy and periodically refreshed entities.
>
> A typical usage is when you're developing DocBook documents, and each 
> rendering process takes an http hit to docbook.sourceforge.net. Of 
> course, this makes rendering slow, and you may want to improve it. 
> Here's more details:
>
> http://www.renderx.com/reference.html#URI_Resolution
>
> http://www.renderx.com/reference.html#using_catalogs_for_docbook
>
> https://www.oasis-open.org/committees/entity/spec-2001-08-06.html
>
> Alternatively, a caching proxy could be a solution, but it may be an 
> overhead and depend on your needs.
>
> Best regards,
> Vladyslav Y. Sivyakov, RenderX.
>
> On 31.07.2020 09:44, Kirch Fritz wrote:
>
>     Hi RenderX-Support Team, hi Kevin
>
>     in my FO-file (see below and in appendix) you can find excatly one
>     call of <fo:external-graphic> with a url to my graphic file.
>
>     When I use XEP.BAT to render FO into XEPOUT intermediate format,
>     my server protocoll told me, that there are 3 calls fetching the
>     pdf-graphic from my server.
>
>     I am wondering, why there are 3 calls?
>
>     With the processing instruction xep-out-embed-images:
>
>         FO -> XEP calls my media server  3 times    and    XEP -> PDF
>     calls my media server 0 times
>
>     Without the processing instruction xep-out-embed-images:
>
>         FO -> XEP calls my media server  2 times    and    XEP -> PDF
>     calls my media server 4 times
>
>     How can I minimize the number of calls to my media server?
>
>     Fritz Kirch
>
>     IT2media GmbH & Co KG
>
>     Nuremberg, Germany
>
>
> _______________________________________________
> (*) To unsubscribe, please visit http://lists.renderx.com/mailman/options/xep-support
> (*) By using the Service, you expressly agree to these Terms of Service http://w
> ww.renderx.com/terms-of-service.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.renderx.com/pipermail/xep-support/attachments/20200805/9a591d44/attachment.html>