[MapProxy] Error: No such file or directory: .lck

[Pestereva, Anna]

Attila,

thank you for the suggestion! I can't see anything abnormal in our servers
utilization metrics though.. Also the errors don't seem to depend on a
single data source or even single kind of source or cache config, which
makes it quite confusing..
Will see if updating Mapproxy version will have a positive effect.

Anna

On Tue, Jul 26, 2016 at 5:38 AM, BERÉNYI Attila <aberenyi at gislab.hu> wrote:

> Hi there,
>
> We've been fighting the same error for the last couple of days, and it
> turned out that the root cause is a data error (actually a character
> encoding issue in the labels) - basically this means that the lock issue in
> its own is not really helpful.
>
> You've mentioned that the data is coming from an NFS share - maybe worth
> checking the I/O rates?
>
> Cheers,
> Attila
>
> Pestereva, Anna <apestereva at aerialservicesinc.com> ezt írta (időpont:
> 2016. júl. 26., K, 0:45):
>
>> Well, so far the most sure fix has been to explicitly configure caches
>> with *disable_storage: true*. Although it is a relief to not see errors
>> without changing functionally for most layers (since cache is not stored
>> anyway for mixed format sources) - the original question remains open, why
>> would those errors appear in the first place? We'd prefer to store tiles
>> for caches/sources that support it.
>>
>> Also, would it be correct to say that it is the best practice to
>> explicitly disable storage for caches that don't save tiles anyway?
>>
>> On Fri, Jul 22, 2016 at 5:25 PM, Pestereva, Anna <
>> apestereva at aerialservicesinc.com> wrote:
>>
>>> A little more information if it can help anyone notice the
>>> reason/solution:
>>>
>>> - errors occur with caches based not on just mixed sources, but also
>>> with caches based on single wms source, where cache tiles are being
>>> physically saved to disk.
>>> - errors occur only with the most frequently used caches
>>> - configuring and using a new cache with all the same settings, but a
>>> new name, helps temporarily. For some time any errors stop, but after the
>>> popular layer is used a bit, errors start appearing again although at a
>>> slower rate than before.
>>>
>>> Will be glad to hear any thoughts!
>>> Thanks!
>>>
>>> --
>>> *Anna Pestereva, GISP | Application Developer & Cartographer*
>>> *Aerial Services, Inc. (ASI) *
>>> <http://aerialservicesinc.com/photoblogmetry/>
>>>
>>
>>
>>
>> --
>> *Anna Pestereva, GISP | Application Developer & Cartographer*
>> *Aerial Services, Inc. (ASI) *
>> _______________________________________________
>> MapProxy mailing list
>> MapProxy at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapproxy
>
> --
> BERÉNYI Attila, PhD
> ügyvezető
>
> GISLab Consulting Kft.
> H-1031 Budapest, Kadosa utca 59.
>
> M: +36 20 457 1800
> W: http://gislab.hu
>



-- 
*Anna Pestereva, GISP | Application Developer & Cartographer*
*Aerial Services, Inc. (ASI) *
<http://aerialservicesinc.com/photoblogmetry/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapproxy/attachments/20160726/1b9519ed/attachment.html>