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
ville.karppinen@anonymised.com
------------------------------------------------------------------------------
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
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
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
ville.karppinen@anonymised.com
------------------------------------------------------------------------------
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
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users