I am using GeoServer 2.6 Final War File in Tomcat. I am setting up GeoWebCache and I am attempting to seed a table from Oracle that has about 600,000 records. (I used the Oracle NG provider to create the Data Source).
I select the following options from GeoServer under

"Tile Layers" >> "Seed/Truncate" for that layer:
  • Number of tasks to use: 01
  • Type of operation: Seed - generate missing tiles
  • Grid Set: EPSG:2236
  • Format: image/png
  • Zoom start: 00
  • Zoom stop: 18

I then click on Submit and see the following:

Id|Layer   |Status |Type|Estimated # of tiles|Tiles completed|Time elapsed |Time remaining|Tasks     
49|sf:MV0_1|RUNNING|SEED|2,857,446           |-1             |Estimating...|Estimating... |(Task 1 of 1)

Then I click on "Refresh list" and in about 10 seconds it is no longer there...I was trying to look in the logs folder and found no logging in:

C:\Program Files\Apache Software Foundation\Tomcat 8.0\logs

which is where GeoServer is installed.

Why is the seeding not working?

Here is the gridset 2236 defined in geowebcache.xml:


Answering a question from comments:

"Does the preview of the integrated GWC show maps for you?"

I click on "Tile Layers", Then select the "EPSG: 2236 / png" to preview the cached tile. I get some tiles that display. (Only the ones generated before the process dies as mentioned above)

Answering another question from comments:

"You need to make sure that your Gridset in GeoWebCache matches what you have setup on the Layer in GeoServer."

Yes, the layer matches the gridset in GeoWebCache:

Data>>Layers>>Edit Layer>>Tile Caching>>Available Gridsets

One item shows:

Available gridsets 
Gridset: EPSG:2236
Published zoom levels: min/max
Cached zoom levels: min/max
Grid subset bounds: Dynamic

Also under "Tile Caching">>"Caching Defaults">>Default Cached Gridsets, I have only:

Gridset: EPSG:2236 
CRS : EPSG:2236
Tile Dimensions: 256 x 256 
Zoom levels: 19
Disk Usage: 465.63 MB

Also under "Tile Caching">>"Disk Quota", disk quota is enabled and set to 1.953 GB.

Answering a question from comments:

"Do you have write permission for the logging folder?"

Yes, other log data is being updated in that folder such as :

C:\Program Files\Apache Software Foundation\Tomcat 8.0\logs


Answering a question from comments:

"Browse the folder and see if the images are stored? I remember that Geoserver couldn't read my folder size once, so I didn't think the images were cached but they were there when I browsed to the directory. Perhaps this is similar?"

Yes, there are some images maybe a handful which are created just before the seed tasks die. They are in the

C:\Program Files\Apache Software Foundation\Tomcat8.0\webapps\geoserver\data\gwc\

folder under subfolders.

I also want to mention that there is another oracle spatial table (setup under another layer) with same layout but with only 1300 records and that one does complete normally.

I found the error in the geoserver.log that is causing the gwc to stop:

org.geoserver.platform.ServiceException: This requested used more time than allowed and has been forcefully stopped. Max rendering time is 60.0s

  • Seeding process does not tell too much about how it is going. What you see can happen if there is nothing to seed (cache is seeded already) or if GWC believes so. I suppose that cache is not full in your case. Reseed feels somehow more reliable for me. Try with reseed and use for example 4 threads. It is also good to increase the reliability by splitting seeding to smaller bounding boxes so that the task finishes before all the threads die. – user30184 Oct 20 '14 at 19:28
  • Unfortunately, I already tried those options including choosing either "seed or reseed" and choosing up to 10 tasks to use. I just tried it again right now with 4 tasks and all 4 disappeared in less than 30 seconds. – user3657279 Oct 20 '14 at 19:47
  • 1
    Does the preview of the integrated GWC show maps for you? I mean the ones that can be opened from localhost:8080/geoserver/gwc/demo? Check especially your custom EPSG:2236 gridset. – user30184 Oct 20 '14 at 19:53
  • 1
    Most likely it is a GridSet Issue, you need to make sure that your Gridset in GeoWebCache matches what you have setup on the Layer in GeoServer. You might like to include the relevant layer excerpt from the GeoWebCache xml file and a screenshot of your Geoserver Layer Page Setup .. – Mark Cupitt Oct 21 '14 at 1:02
  • do you have write permission for the logging folder? – Ian Turton Oct 21 '14 at 7:57

I found the answer to the issue, although there is no available solution. It is a known bug where GeoWebCache stops forcefully. It looks like there is no current solution for bug # GEOS-6278:


If a solution is available in the future for GeoWebCache, I will update this post.


I know this is an old thread, but probably it can help others who reach here. One more reason for GWC dying prematurely (or not showing any status at all upon clicking refresh) is when you have data level security or user roles or service level security. Disabling them worked like a charm for us and we enabled them again after suffiecient caching. We are running GeoServer Version 2.13.1 and GeoWebCache Version 1.13.1.


Have a look at this GeoServer Documentation JVM Considerations.

The options could be edited into "startup.bat" file located in (C:\GeoServer_Installation_Folder\bin).


Probably already found this....but incase someone else sees the post... Make sure you set the WMS global timeout to something larger than 60secs (default). GWC requests the tiles from the WMS service, which needs to have sufficient time to render your data to an image.


With reference to GWC bug: https://osgeo-org.atlassian.net/browse/GEOS-6278

According to information found on the Boundless website, there are 3 parameters that can be set to control Seed Failure Tolerance:

  • GWC_SEED_RETRY_COUNT : specifies how many times to retry a failed request for each tile being seeded. Use 0 for no retries, or any higher number. Defaults to 0, meaning no retries are performed. It also means that the defaults to the other two variables do not apply at least you specify a higher value for GWC_SEED_RETRY_COUNT.
  • GWC_SEED_RETRY_WAIT : specifies how much to wait before each retry upon a failure to seed a tile, in milliseconds. Defaults to 100ms
  • GWC_SEED_ABORT_LIMIT : specifies the aggregated number of failures that a group of seeding threads should reach before aborting the seeding operation as a whole. This value is shared by all the threads launched as a single thread group; so if the value is 10 and you launch a seed task with four threads, when 10 failures are reached by all or any of those four threads the four threads will abort the seeding task. The default is 1000.

These environment variables can be set in a number of ways:

  • As a Java environment variable: for example java -DGWC_SEED_RETRY_COUNT=5 ...
  • As a Servlet context parameter in the web application’s WEB-INF/web.xml configuration file. for example:
  <!-- milliseconds between each retry upon a backend request failure -->
  • As a System environment variable: export GWC_SEED_ABORT_LIMIT=2000; (or for Tomcat, use the Tomcat’s CATALINA_OPTS in Tomcat’s bin/catalina.sh as this: CATALINA_OPTS=”GWC_SEED_ABORT_LIMIT=2000 GWC_SEED_RETRY_COUNT=2

Because the default for GWC_SEED_RETRY_COUNT is 0, the seeding thread dies if it encounters any errors such as the Max rendering time you describe above.

I successfully set this parameter to a large number and now seeding completes as expected.

  • Those same parameters are now available in the seeding form, on a job by job basis (have been for a year or so, the Boundless site is getting more and more outdated, not sure they are keeping up with the GeoServer evolution). – Andrea Aime Jan 26 at 8:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.