Hazelcast/JDBConfig clustering issues caused by HTTP 302 response and unique wicket resource IDs

Description

Trying out 2.9 Beta2 with Hazelcast clustering I noticed that every UI request results with an HTTP 302 response and a unique ID appended to the URL.
when using a single instance this isn't that big of an issue, however when having multiple instances behind a load balancer this results with multiple redirects, which causes the UI to be unusable.(In most cases the browser will just give up).
In some cases this can also become an issue with a single instance behind a proxy.

Looking around I wasn't able to find the commit that added that change, but I'm guessing this was done as part of the wicket upgrade.

Anyone knows if this was this was done in response to a specific issue, or just as an artifact of the wicket upgrade?
Would it be possible to change this behavior back to something that resembles 2.8 (eg HTTP 200 and non unique IDs)?

Thanks,
Ami.

Environment

None

Activity

Show:
Andrea Aime
February 15, 2017, 11:47 AM

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

Niels Charlier
May 26, 2016, 7:02 AM
Edited

Jody, I consider this particular issue as resolved. The remaining unique IDs on POST requests are necessary.
Any remaining issues with the webui and clustering must be resolved in the clustering modules themselves.
See the discussion on the mailing list

Jody Garnett
May 20, 2016, 4:14 PM
Edited

Reopening based on testing from Ami:

Hey Niels,
Thank you for taking the time and working on this!

Just tested today's build and noticed that POSTs are still using unique wicket IDs, which causes various issues with the UI. Would it be possible to disable unique IDs for POST requests as well?

Thanks!

Ami.


Hey Niels,

Yes, as an example trying to create a store will have a POST that looks like this: geoserver/web/wicket/bookmarkable/org.geoserver.web.data.store.NewDataPage?20-1.IFormSubmitListener-storeForm, while it should look like this:
geoserver/web/wicket/bookmarkable/org.geoserver.web.data.store.NewDataPage?IFormSubmitListener-storeForm.

This is also true when modifying layers, deleting workspaces, etc..

Thanks,
Ami.

Jody Garnett
May 18, 2016, 11:57 PM

Merged https://github.com/geoserver/geoserver/pull/1589 to master, and cherry picked the commits to 2.9.x.

Niels Charlier
May 5, 2016, 9:50 AM
Fixed

Assignee

Niels Charlier

Reporter

Niels Charlier

Fix versions