Caching Defaults changes don't persist

Description

On a new GeoServer install:

  1. Go to Caching Defaults page

  2. Check "Direct Integration"

  3. Click "Submit"

  4. Restart Tomcat

  5. Go to Welcome Page

  6. Go to Caching Defaults page

Direct Integration won't be checked...

It looks like the change never makes it to the gwc-gs.xml file, which still reads:

<directWMSIntegrationEnabled>false</directWMSIntegrationEnabled>

Environment

Tomcat WAR on Windows 10

Activity

Show:
Andrea Aime
July 30, 2016, 8:58 AM

Hi Mike, commenting on Jira is like talking to yourself, there is no one reading the messages past the ticket creation one. I'd recommend to discuss on the devel or user list instead.
That said, no, I am not aware of similar issues (or this one in particular, for what is worth). I don't have a GS handy locally, but I tried with http://demo.geo-solutions.it/geoserver/ which is the current day's nightly build, and checking the changes via the resources REST api, e.g., "http://demo.geo-solutions.it/geoserver/rest/resource/gwc-gs.xml", which returns the files in the data directory. It appears that I can turn on and off the direct integration, and the changes appear to be persisted.
Could it be a local problem in your installation? Maybe windows specific?

Torben Barsballe
September 7, 2016, 11:58 PM

So, this seems to be Windows-specific. It looks like the error is occuring at https://github.com/geoserver/geoserver/blob/master/src/gwc/src/main/java/org/geoserver/gwc/config/GWCConfigPersister.java#L111, which doesn't check the return value of renameTo. When the rename fails (as may occur when dealing with windows file locking), rename returns false and persisting the configuration silently fails.

FileSystemResource.renameTo should really be using https://github.com/geoserver/geoserver/blob/bf0345d228111c15aeff6f7c1bc87b4ed230af96/src/main/src/main/java/org/geoserver/data/util/IOUtils.java#L485 rather than just File.rename to rename the file in order for the rename to work on windows.

Torben Barsballe
September 8, 2016, 12:11 AM

Unfortunately, FileSystemResource is in gs-platform and IOUtils is in gs-main (which depends upon gs-platform) so this is a bit more complicated. I feel like IOUtils should perhaps be top level (gs-platform), but it depends on XStreamPersistor, which is also part of gs-main, so I see why it is where it is. Perhaps splitting up IOUtils is the correct route here?

Either way, the IOUtils.rename implementation should be being used wherever we try to rename a file in GeoServer.

Torben Barsballe
September 8, 2016, 10:00 PM

Fixed on 2.9.x by copying IOUtils.rename into FileSystem resource: https://github.com/geoserver/geoserver/pull/1813
Fixed on master by moving IOUtils to gs-platform (see ): https://github.com/geoserver/geoserver/pull/1812

Some argument could be made for changing the behavior of FileSystemResouce.renameTo to actually throw an exception upon error, but this is a substantial API change an is as such unlikely to happen. The GWCConfigPersister class that is responsible for saving the configuration doesn't actually check the return value of renameTo - it looks like it is expecting an exception (I wonder if this behavior changed during the ReosourceStore work?). A breif look at the call heirachy for renameTo suggests that several other calls also ignore the return value (Some do actually check it but it is about 50-50).

Andrea Aime
February 15, 2017, 11:47 AM

Mass closing all resolved issues not modified in the last 4 weeks

Fixed

Assignee

Torben Barsballe

Reporter

Mike Pumphrey

Triage

None

Fix versions

Affects versions

Components

Priority

Medium
Configure