Both are read only backends, i.e. they can't be used in renderd, but only in mod_tile
ro_http_proxy is a proxy storage backend that retrieves tiles from a remote http tile server
ro_composite is a storage backend that composits two tiles before passing them up.
Although ro_composite can composite tiles from any two storage backends, conceptually it only
works well, if at least one set of tiles are static non updating tiles, as the updating logic
does not allow for requesting rendering updates for both tilesets
- automatically find apxs in addition to apxs2. This should make it easier to configure on more systems
- include freetype2.m4. Otherwise ./autogen.sh already fails with missing macro.
- fail if no C++ compiler was found
Storage backends might not be fully thread safe when reusing the same context, like for example the memcached storage backend,
therefore initialise a separate storage backend / context per thread rather than per process.
Unfortunately there is no way to do this in Apache 2.2. So there you will need to use mpm prefork for non thread safe backends
Remove hard coded references to the spherical mercator projection and
replace them with something a little more generic. It is still necessary
to add code to support new projections, but it is limited to a few configuration numbers
This initial commit supports spherical mercator and plate carree.
This commit also makes the tile size configurable. The default remains at 256 px.
So far, (meta)tiles could only be stored and retrieved from a locally mounted posix filesystem. Although, the posix
filesystem API is it self a plugable storage layer into which one can mount many different filsystems, from temporary
filesystems to network filesystems, as mod_tile installations scale up to multi-server environments this might not be sufficient and one
may want to use other storage layers.
This patch therefore abstracts all storage calls out into a separate API that can be implemented by various storage backends to fit the needs of different
installations.
Three storage backends are included in this commit:
- file backend: This is the equivalent of what existed before in mod_tile / renderd. This uses a posix filesystem to store (meta)tiles
- memcached: This stores tiles in a memcached store
- rados: This stores tiles in a rados / ceph cluster
The memcached and rados backends should currently still be considered as experimental
There are also other refactoring and cleanups in this commit
The following errors appeared on Ubuntu builds:
cc1: warning: command line option '-ftemplate-depth=300' is valid for C++/ObjC++ but not for C [enabled by default]
In file included from store.h:9:0,
from store.c:21:
render_config.h:6:1: error: expected identifier or '(' before '/' token
render_config.h:15:1: error: stray '#' in program
...
As I don't know why this broke, or how to fix it, I am reverting this patch for now. It also only triggeres after a make distclean
So far mod_tile could only connect to renderd via a unix domain socket.
Renderd was already able to accept tile rendering requests on tcp sockets
to enable it to be distributed accross multiple servers. With adding this
feature to mod_tile, it is now possible to have renderd on a different server
than mod_tile.
If multiple IPs are registered to the renderd dns entry, it supports a simple
form of automatic fail over, although a more sophisticated solution is likely
necessary for proper high availability setups.
based expiry
With a set back of 20 years rather than to a specific date,
the actual render time gets preserved and can be checked in
e.g. mod_tiles tile status
Add a warning to the status page that neither create time nor access time might be accurate.
Create time is manipulated by the tile expiry process, and atime is often disabled on the filesytem via noatime
for performance reasons.
Adds a munin graph to monitor the average time it takes to retrieve a served tile
from disk. This can be useful to check if the underlying disk system is fast enough
to handle the load of serving tiles. It does not include time required for pontential
rendering on the fly, nor the time to deliver the tile over the network.
