it's a cloud VM so I'm installing monitoring agents to see what happen to the ram usage (and when) then I'll check the dumps...
you don't want to have to parse a SLD in your proxy to figure out how many layers it has inside, I believe :-D
Hehe, nope this isn't a good idea and that would also impact performance. My proposal is meant as a temporal solution which assumed that the "fantastic client" will request via HTTP GET. I could also imagine to extent the request limit settings in the WMS configuration of Geoserver (https://docs.geoserver.org/stable/en/user/services/wms/configuration.html) but suppose this is a rarely needed requirement.
(well, add 1GB for the rest of GeoServer)
I set that even if it's also on the controlflow, anyhow it will probably not help so much, the estimated size of the rendered image is rarely reached the problem in this case is the number of touched resources and something which is not going well with the memory management which grows rapidly (i'm over geoserver 2.18.0 + adoptjdk11 and 'all' the 'recommended' settings for production).
@jnh5y for the JTS upgrade for geoserver - it has some failure
geoserver/geoserver#5258
geotools/geotools#3617
GeoWebCache/geowebcache#982
Does this need to be done in conjunction with GT and GWC prs? I think you have a CI integration build showing the combo is successful.
re-running it
Gotta continue my streak of 1 line PRs:)
Is there anything for the upgrade instructions, perhaps how to enable/disable overlay ng ?
2 replies
Getting fairly inconsistent results attempting to build and test GeoServer with Java 17. But at least one dependency sticks out as especially problematic and that is cglib-nodep used in core stuff like GetFeature.java. cglib appears stagnant and depends on asm 7. Asm added JDK 17 support in version 9.
Issue has been filed since April - cglib/cglib#191.
Looks like the only place cglib is used is in GetFeature.java (https://github.com/geoserver/geoserver/blob/f732201d424c0aaf9545b2d0858016ea636450d5/src/wfs/src/main/java/org/geoserver/wfs/GetFeature.java#L705-L717) so perhaps that can be reworked.
a rework might need to rewrite the EMF generated classes.... which requires goat killing, the right moon, and the right version of Eclipse, and someone willing to use that abomination
4 replies
(not Eclipse per se, I'm talking about the EMF code generator)
which implies minimum version of Tomcat to use GeoServer to be 10 I believe
and a bunch of import changes, at a minimum
upgrading spring also brings an upgrade of spring-security, which we are strongly tied to, even on the internals... might be annoying
I was also reading about wicket using cglib and having troubles.. wicket upgrades have been very painful so far
As for Jetty, 10 is required.
And well, didn't expect this to be easy :D
or maybe there is a newer cglib in the works with fixes? who knows
I opened a geoserver/geoserver#5259 that depends on a recently merged geotools change geotools/geotools#3620, and I'm not sure how to get the workflow to use the most recent gt-xml SNAPSHOT artifact. Can anyone give me a hint how to re-run the workflows with updated artifacts? Thanks!
Me too, but the artifacts seem to be old e.g.: https://repo.osgeo.org/repository/snapshot/org/geotools/gt-xml/26-SNAPSHOT/gt-xml-26-20210818.092924-109.jar
I was able to reproduce the build error on my machine by building with gt-xml artifacts from the snapshot repo instead of my locally built repo. It seems the osgeo snapshot repo is not up to date with the geotools code, so there's nothing to be done on the geoserver side that will change that. I can just wait until the osgeo repo is updated. Thanks for your help!
the thing is, the biulds are not failing locally, nor in the PR checks
just on the build server
Daniele sent a mail the other day about disk space being exhausted, I could not follow up yet
If I was looking to make a coverage provider, do I really need the RenderedImage part of https://docs.geotools.org/stable/javadocs/org/geotools/coverage/grid/GridCoverage2D.html ? I have a DTED parser, and looking at whether I can just present the whole world as a coverage without needing the image.
you might want to look at the Gtopo30 module I just removed, it's likely pretty close to what you need