TransWikia.com

GeoServer GeoWebCache seeding dies prematurely

Geographic Information Systems Asked by user3657279 on May 4, 2021

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 in geowebcache.xml:

<gridSet>
            <name>EPSG:2236</name>
            <srs><number>2236</number></srs>
            <extent>
                <coords>
                    <double>306826.6397</double>
                    <double>36279.6630</double>
                    <double>982215.8007</double>
                    <double>2363339.4629</double>
                </coords>
            </extent>
            <resolutions>
                <double>8192</double>
                <double>4096</double>
                <double>2048</double>
                <double>1024</double>
                <double>512</double>
                <double>256</double>
                <double>128</double>
                <double>64</double>
                <double>32</double>
                <double>16</double>
                <double>8</double>
                <double>4</double>
                <double>2</double>
                <double>1</double>
                <double>0.5</double>
                <double>0.25</double>
                <double>0.125</double>
                <double>0.0625</double>
                <double>0.03125</double>            
            </resolutions>
            <metersPerUnit>0.3048</metersPerUnit>
            <tileHeight>256</tileHeight>
            <tileWidth>256</tileWidth>
        </gridSet>

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

localhost*.log    
catalina*.log     
etc 

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

5 Answers

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.

Correct answer by user3657279 on May 4, 2021

Have a look at this GeoServer Documentation JVM Considerations.

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

Answered by bydos on May 4, 2021

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.

Answered by Paul Grambauer on May 4, 2021

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.

Answered by Himavant Mulugu on May 4, 2021

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:
<context-param>
  <!-- milliseconds between each retry upon a backend request failure -->
  <param-name>GWC_SEED_RETRY_WAIT</param-name>
  <param-value>500</param-value>
</context-param>
  • 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.

Answered by PeterS on May 4, 2021

Add your own answers!

Ask a Question

Get help from others!

© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP