# GeoServer GeoWebCache seeding dies prematurely

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 FilesApache Software FoundationTomcat 8.0logs

which is where GeoServer is installed.

Why is the seeding not working?

Here is the gridset 2236 defined ingeowebcache.xml:

 EPSG:2236 2236   306826.6397 36279.6630 982215.8007 2363339.4629  8192 4096 2048 1024 512 256 128 64 32 16 8 4 2 1 0.5 0.25 0.125 0.0625 0.03125 0.3048 256 256

"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)

"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.

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

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

C:Program FilesApache Software FoundationTomcat 8.0logs

localhost*.log catalina*.log etc

"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 FilesApache Software FoundationTomcat8.0webappsgeoserverdatagwc

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

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:

https://osgeo-org.atlassian.net/browse/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.

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:
  GWC_SEED_RETRY_WAIT 500
• 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 theMax rendering timeyou describe above.

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

Have a look at this GeoServer Documentation JVM Considerations.

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

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.