Back to RasterLite2 doc index

---

WmsLite - a simple WMS server based on RasterLite2

The OGC WMS (Web Map Service) is a well known standard protocol specifically intended to support dynamic WEB publishing of geographic maps. The more recent version currently is 1.3.0, and the corresponding formal standard specifications are publicly available from here

WmsLite in its current implementation only supports a very limited subset of the WMS standard; anyway it's expected to be strictly standard compliant, and consequently should always be able to interact with many other sw components supplied by third-parties.

WmsLite does not require any external configuration; it will directly publish any Raster Coverage found within the target database currently connected, and any related detail is expected to be found within the same DB. All this makes elementary simple and immediate deploying a someway limited but absolutely genuine WMS server (i.e. for testing purposes).

Starting WmsLite

1. just open a Command Prompt window (aka Shell window on Linux and other Unix-like systems).
2. then launch the wmslite process by specifying the pathname of the DB-file you intend to publish.
   Please note: the obvious expectation is that such DB-file should contain at least one (and possibly more) Raster Coverages.
3. wmslite will check the DB-file for validity, and will then show few useful informations (version, list of Layers ready for publishing and alike).
4. Starting since this moment wmslite will silently listen on the localhost IP port 127.0.0.1:8080 for any incoming request. If such requests are valid accordingly to the WMS protocol, then the appropriate map will be serviced back to the client. In any other case some appropriate HTTP error will be returned.
5. Don't be worried if apparently wmslite does absolutely nothing; it effectively works, but it silently works on HTTP connections: just looking at the window doesn't reveal any activity symptom.
6. Please note well: you should never close the windows, because this will suddenly kill the server process. Anyway you could safely minimize the window without any adverse consequence.

Stopping WmsLite

1. The correct way to nicely terminate a running wmslite server is by pressing Ctrl/C
2. This way the server process will receive a termination request, and will consequently start a clean shutdown sequence.

Caveat: on Windows using the MSYS shell to run wmslite is a strongly discouraged option, because this shell seems unable to correctly handle Ctl/C thus leading to a dirty shutdown with consequent data losses.

Logging

SELECT * FROM wms_server_log;

1. wmslite will always attempt to create a table named wms_server_log on any DB-file being published.
2. this table acts as a classic logfile: every incoming request will be registered into a distinct row containing many potentially useful informations.
3. you could then eventually query this table e.g. for monitoring purposes.

multi-threading and journaling

1. wmslite is internally implemented as a multi-threaded server.
2. a separate thread will be spawned for each request to be processed, so multiple requests could eventually be serviced at the same time.
3. SQLite offers only a very limited support to multiple concurrent accesses on the same DB-file.
   Anyway supporting many concurrent readers and just a single writer at the same time is a safe and stable configuration.
4. accordingly to all this wmslite adopts the following access strategy to the DB-file:
   • as many reader threads will be spawned as required by the incoming requests to be serviced; such threads will always open the DB-file in read-only mode.
   • just a single writer thread will take care to update the wms_server_log at regular time intervals. (and this clearly explains why suddenly stopping the wmslite server never is a brilliant idea; because this way you'll probably irremediably lost many useful log events).
   • all connections to the DB-file will use the same shared cached and the journaling mode will be changed to WAL (Write Ahead Log), so to ensure optimal performances even under heavy concurrency.

Please note well: adopting the WAL mode implies a persistent change; any further connection to the same DB-file will always use WAL as the standard journaling mode.
Anyway in order to restore the usual default configuration you simply have to execute the following PRAGMA directive:

PRAGMA journal_mode=delete;
------
delete

syntax and optional arguments

$ wmslite -h

usage: wmslite ARGLIST ]
==============================================================
-db or --db-path      pathname  RasterLite2 DB path
-p or --ip-port       number    IP port number [default: 8080]

-cs or --cache-size    num      DB cache size (how many pages)
-dbg or --debug                 verbose debugging mode
$

1. -db pathname: specifying some DB-file path is the only mandatory argument.
2. -p port-number: sometimes the standard 8080 is already in use thus being unavailable. In such cases you could eventually choose some different IP port number.
3. -dbg: this option will enable the verbose debugging mode. In this case the URL corresponding to every incoming request will be immediately printed on the standard output file immediately before being processed.
   Such an option is potentially useful in order to easily identify the offending URL in the unlucky case of some nasty crash suddenly killing the server process.

---

Back to RasterLite2 doc index