Note that this behaviour can be turned off by disabling LDCache in the Marmotta configuration (or fine-tuning it so that resources matching certain regular expressions are black-listed).
Sebastian Sergio Fernández <wik...@apache.org> schrieb am Mo., 29. Aug. 2016 um 18:11 Uhr: > I forgot to say Marmotta _only_ considers "local" resources under > http://host.to/marmotta/resource/... > > On Aug 29, 2016 18:09, "Sergio Fernández" <wik...@apache.org> wrote: > >> Frans, do yor resources have a non-lical URI? That would explain the >> issue, sincd Marmotta would try to find more information out there. >> >> Besides disabling LDCaxhe, you can customize the configuration ( >> http://marmotta.apache.org/platform/ldcache-module.html) to ignore your >> fake URI. >> >> On Aug 29, 2016 17:48, "Frans Knibbe" <frans.kni...@geodan.nl> wrote: >> >>> Hello, >>> >>> I have done some test, to see if can find out what caused the long wait >>> time for first time requests. Here are some findings: >>> >>> - The first time requests always seem to take 60 seconds and a bit >>> (e.g. 60.232 seconds). So every time it is suspiciously close to a full >>> minute. >>> - The subsequent requests take less than a second (e.g. 0.109 >>> seconds). >>> - The effect still occurs when I restart Marmotta between first and >>> subsequent requests. >>> - I tried turning off versioning (*versioning.enabled*). That did >>> not seem to have an effect on response times. The response headers did >>> still include timegate and timemap links, which I don't understand. >>> - Of the settings that can be changed using the admin web UI, I saw >>> the setting *ld_cache.so_timeout *is the only thing set to 60 >>> seconds (60000 miliseconds), which could somehow have to do with the >>> delay >>> of a bit more than 60 seconds for a first request. To test that, I tried >>> changing the value of 60000 to something else. But I was not able to save >>> the change because of an error: cannot store content: TypeError: >>> value.getValue(...).split is not a function. >>> - Disabling ldcache altogether (*ldcache.enabled*) did solve the >>> problem. >>> >>> So I was able to solve the issue by disabling caching of remote >>> resources. That was unexpected, because all resources I requested where not >>> remote but local. But perhaps the problem lies with the way in which local >>> and remote resources are discerned, I do have some URI rewriting configured >>> (I wrote about that in another thread). >>> >>> The Linked Data Caching Module looks like a useful Marmotta component, >>> it would be a pity if I can not use it. >>> >>> Would it make sense or be useful if I log my findings in the issue >>> tracker? Or can everything be easily explained? >>> >>> Greetings, >>> Frans >>> >>> >>> >>> On 23 August 2016 at 11:03, Frans Knibbe <frans.kni...@geodan.nl> wrote: >>> >>>> Hello, >>>> >>>> I wonder if the following can be explained... I run Marmotta 3.3.0 with >>>> a PostgreSQL 9.5 data store. I notice that when I request a certain >>>> resource the first time it takes a long time (more than a minute) to >>>> produce the reply. Subsequent requests for the same resource are resolved >>>> quickly (less than a second). Perhaps I should mention that resource >>>> requests are rewritten to {BASE}/resource?uri=<resource URI>. >>>> >>>> If I recall correctly, the effect was less or absent when I used the >>>> default H2 data store. >>>> >>>> Is some kind of caching going on? It seems that the effect is not >>>> caused by browser caching or by PostgreSQL's cache. >>>> >>>> Is there something I could do to remedy the effect? >>>> >>>> Greetings, >>>> Frans >>>> >>> >>>
