I also guess that REST API reseed and direct file system delete are 
probably quite safe way to go especially if you do not use GeoWebCache 
quota.

In our system, we use time dimension parameter when reseeding and 
therefore folder names have hash-postfix. I think direct deletion is 
safer way to keep cache clean by checking creation times of folders and 
by removing folders that are too old. If REST API truncate queries are 
used, there is a possibility that some of time specific truncate queries 
may be skipped, for example if GeoServer is not available for some time 
period, and then those tiles are not removed from cache. Therefore, 
direct deletion seems to be more reliable way to go in this case.

Ville Karppinen

On 01/21/2015 02:28 PM, Rahkonen Jukka (MML) wrote:
> Hi,
>
> I believe also that if disk quota is in use it may get out of sync. Another 
> side effect could be that "Seed - generate missing tiles" process does not 
> know which tiles exist and which not.  However, from my experience the REST 
> truncate process is not reliable. It does not necessarily remove all the 
> tiles at  least if truncate is used together with bounding boxes. If 
> truncation fails GWC does not send any feedback about it and feedback comes 
> when some end user gets  old image tiles mixed with new ones. Therefore we 
> delete tiles nowadays always directly from the file system and then reseed 
> (generate all tiles) with reasonably sized REST jobs or just let the tiles 
> born on-the-fly if the service is not in a heavy load.
>
> I have been thinking that someday I should study more deeply what happens 
> with the truncate + bounding box jobs but it is not so easy to solve the 
> secret of the tiling schema and directory/file names. Before the study I 
> should know exactly which files a truncate job should delete so that I could 
> check if they were really deleted. Until that I play safely and delete and 
> reseed 5 times more than necessary.
>
> -Jukka Rahkonen-
>   
> Ville Karppinen wrote:
>
>> GeoServer provides GeoWebCache REST API that may be used to truncate 
>> existing cached tile folders ( 
>> http://docs.geoserver.org/stable/en/user/geowebcache/rest/seed.html ).
>> If I have a local access to the tile cache folders, is it ok to handle 
>> truncating by simply deleting some of the folders by using my own scripts 
>> instead of using REST API. In other words, can bypassing the REST API to 
>> clean tile cache have some unwanted side effects? Only potential thing that 
>> comes into my mind is GeoWebCache Disk Quota service ( 
>> http://docs.geoserver.org/stable/en/user/geowebcache/rest/diskquota.html
> ). For example, is there a possibility that some quota counter becomes out of 
> sync if deletion is not done via REST API?
>
>> Best regards,
> --
> Ville Karppinen
> [email protected]
>
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Geoserver-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-users


------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Reply via email to