Thread priority seeding

[cholmes]

Part of this should likely be done at the GeoServer level, but it'd be really nice if you could do a seed while standing up a live server. Right now if you're in the process of seeding then it pretty much takes up all the resources, and every request has to just get in line, leading to slower user responses.

This is unfortunate - ideally you could do iterative caching as people browse the most popular areas while a thread runs through the whole tile set in the background. I'm not sure of the exact architecture, but ideally requests that are cacheable and made actively should have the highest priority, ones that aren't cacheable but are active are second, and ones that are seeding a cache are last. If we can do the thread priority in geoserver then perhaps tilecache just needs to append the proper thread hint to the WMS request.

Ok, this is probably more of a geoserver feature, but I'll leave it here since there would be a bit to be done in geowebcache.

[aaime]

Hum, not too sure this is easy.
First off, GeoWebCache should try to not fill the servlet container request queue (for example, if the container is set with 50 threads max, the cache should try to stay lower, eventually quite a bit lower, than that).
Besides that, in fact each servlet call is handled by a different thread, and the thread priority could in theory be changed by calling Thread.setPriority (http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#setPriority(int)), but since servlet threads are pooled, I'm not sure containers such as Weblogic will actually allow to change the thread priority. We'd also have to reset back the thread priority to the default before the request ends.

[arneke]

For starters I've set the priority lower on the seeding threads, probably won't make much of a difference (as noted above) because gwc will have plenty of breaks while transferring data or waiting for geoserver to respond.

The threads come from an executor pool, so they should not interfere with the rest.