Hazelcast/JDBConfig clustering issues caused by HTTP 302 response and unique wicket resource IDs
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)?
Mass closing all resolved issues not modified in the last 4 weeks
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
Reopening based on testing from Ami:
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?
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:
This is also true when modifying layers, deleting workspaces, etc..