-
Notifications
You must be signed in to change notification settings - Fork 404
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WPS exports fail for all file formats except CSV - GeoServer #7932
Comments
@DavidQuartz did you already check MS is performing a correct request? Can we effectively exclude bugs MS side for this? If yes please explain why. Assuming there is no bug MS side with the request, we have to provide to devops some sample of requests here to make them able to directly reproduce the issue by performing them (eg. some CURL requests with different formats that are not working along with the one using CSV that is working instead). |
@tdipisa the bug on MS side related to download so far concerns exports of layers with spatial filters. The fix is provided here. However, downloading a layer without any filters applied should not be affected by the bug. I will include 3 cURL examples (Shapefile, Geojson, and CSV) cURL request for a shapefile -- unsuccessful
cURL for Geojson --unsuccesful
cURL for CSV -- successful
|
I investigated a bit the shapefile download. It's succeding on the GeoServer side but MS is throwing an error. Not sure why @tdipisa @DavidQuartz Looks like a problem with the Getstatus call. Manually copy-pasting the link in the browser works but in the developer tools the request is failing: Nothing besides the exception in tthe logs to my eyes |
@tdipisa the download process is failing randomly, in some cases also the CSV format is failing. Test done client side:
all test are still failing but if we try to open the same execution status in a different tab the response seems succeful. |
@allyoucanmap can you effectively exclude a problem client side then? Should we ask the GeoServer team for an investigation WPS side? It seems yes to me, please confirm. |
yes, I confirm that a server side investigation is needed |
@taba90 I will get in touch with you for this according to the current schedule, there's no immediate rush with this. |
Could reproduce, and then asked @randomorder support to debug, modifying the web.xml so that we get HTTP request, as seen by GeoServer, logged. Unfortunately we cannot make progress on the actual topic of this issue one until the GeoFence issue is solved, because it prevents all access to data due to the rule database not being available.... @randomorder is still looking into it... |
Ok geoserver is starting now. We are still investigating |
@randomorder managed to get GetFence work, resuming investigation. |
Thank you @randomorder @aaime. I'm moving the issue in Blocked for the MapStore board then. I'm looking forward to receiving news on this. |
Found where the issue is... and it's been epic, required debugging Tomcat own source code! Here is what happens:
General problem: we should not be using HTTPServletRequest in a background thread, its state is valid only as long as the original request is in flight. I have searched in Tomcat for a setting that would make it stop recyling the requests, and found one, but it just stops recyling of the "request facade", and when enabled, caused the asynch process to just fail with:
The quick fix is to make LanguageURLMangler (written by Yalin) to stop using the HttpServletRequest, and use the Request rawKvp instead (which is detached from the original HTTP request). However, mind, this could come up in the future in different shapes... to make sure we won't get bitten, we should be doing a deep copy of HttpServletRequest while we pass Dispatcher.REQUEST down to the asynch execution pool (which... is not trivial). @simboss shall I go for the quick fix? The quick fix is a matter of hours, including backports, a fuller fix with deep cloning of the HTTP request is likely 1-2 days. |
@ElenaGallo a fix have been provided for this issue in GS-STABLE. Can you please retest it with MS DEV and close the issue if all is working properly? |
@tdipisa it's not clear to me if, what and where the fix has been done. The epic is closed but the underlying (Geoserver) issues are still in backlog. What do you mean with "a fix has been provided for GS-STABLE"? #8052 references geoserver/geoserver#5832 which reports that the fix has been backported to 2.21.x. |
@giohappy I've missed the fact that the issue was converted into an epic by @nmco. Anyway, as far as I understand (correct me if I'm wrong @nmco), issues connected to this epic (as well as the overall problem) are related to GeoServer and not to MS so these issues should not be there. MS is not the good place to host GS issues :) @nmco let me know anyway if I've missed something in the process. |
Description
CSV file export is currently the only option which does not fail in wps downloads. For the other file formats, a response like this is returned from geoserver
How to reproduce
Expected Result
The export is successful
Current Result
The export fails
Browser info
(use this site: https://www.whatsmybrowser.org/ for non expert users)Other useful information
This issue may be from the backend.
Geoserver version: 2.20 SNAPSHOT
The text was updated successfully, but these errors were encountered: