Selecting style makes GeoServer constantly consume a CPU core

GeoServer GeoServer User
1

I believe I’ve stumbled on a bug in GeoServer. The following can be reproduced with GeoServer 2.27.1 and 2.27.2 (I haven’t tried other versions).

If I choose the following style for a layer, it makes GeoServer/Tomcat start working 100% on CPU core: A blue line with end arrows

The following screen recording shows how to reproduce it: https://troels.arvin.dk/gis/geoserver/stuck_thread_aug_2025/screen_recording_geoserver_java.webm :
For a layer, if I choose the style from the drop-down menu of available styles, GeoServer consumes a CPU core, even if I don’t save the layer update.
If it’s done several times, more CPU cores are being put in to 100% use. The only way to have the CPU cores back is to restart Tomcat.

If I enable stuck thread detection in Tomcat, then this is what I get:
https://troels.arvin.dk/gis/geoserver/stuck_thread_aug_2025/stuck_thread_detector_in_catalina_out.txt
A subsequent full thread dump: https://troels.arvin.dk/gis/geoserver/stuck_thread_aug_2025/full_thread_dump_in_catalina_out.txt

Tomcat version: 9.0.104 on Ubuntu Linux. I have tried both with Java 17 and Java 21; the problem can be reproduced with both.

So I guess something’s wrong with the style(?). But GeoServer validates the style OK, and it allows me to save the style. That does not create the run-away-CPU situation.
GeoServer also allows me to save the layer which is configured to use the style (i.e. when the CPU hog phenomenon is seen).

Should I report this as a GeoServer bug in OSGEO’s Jira?

2

Hi Troels,
yes, that looks like a bug in the legend production (that’s what heppens when you select a style, GeoServer tries to show you a legend).

I’m guessing the issue is here:

<CssParameter name="stroke-dasharray">
31
  <ogc:Div>
    <ogc:Literal>5000000</ogc:Literal>
    <ogc:Function name="env">
      <ogc:Literal>wms_scale_denominator</ogc:Literal>
    </ogc:Function>
  </ogc:Div>
</CssParameter>

When computing the legend outside of a WMS request, wms_scale_denominator is not set and the division might give odd results.
A quick fix might is to provide the env function with a second argument, a default value, so that the division is always well defined:

<ogc:Function name="env">
  <ogc:Literal>wms_scale_denominator</ogc:Literal>
  <ogc:Literal>1000000</ogc:Literal>
</ogc:Function>

Please also open a ticket in Jira with the sample style attached.

Cheers
Andrea

3

Thanks, the workaround works. Unfortunately, Projects - JIRA says I’m not allowed to add an “activity” to the project as “guest” (even though I’m logged in at atlassian.net), so I cannot submit a ticket about this.

4

Was that a pre-existing account or did you created it anew?
I believe you need to create an account on that specific Jira instance.

Filtering existing users by your name, and then surname, gave no results, I’m guessing it’s likely that the Jira instance is not recognizing you as its own user.

Cheers
Andrea

5

It was with an existing atlassian.net account.

I tried adding a new Atlassian account (using a browser in incognito mode). The new account (osgeo@troels.arvin.dk) works well at (for example) home.atlassian.com, but I’m still told that I’m not allowed to submit a new issue at Jira - JIRA :frowning_face:

6

Still unvailable as an OSGeo jira user.
Can you try signing-up here:

Cheers
Andrea

7

Unfortunately, it didn’t work for me following the link. It seems to keep insisting I need to log in, even though I’m already logged in. Re-logging in does not help. Have tried two very different browsers, have tried wiping user data in browser.

8

I have created a ticket for you:
https://osgeo-org.atlassian.net/browse/GEOS-11901

Cheers
Andrea

1 Like