[Geoserver-devel] RC3 release blocked by a number of issues

GeoServer GeoServer Developer
1

Hi,
I was doing the usual “manual testing script” at http://docs.geoserver.org/latest/en/developer/release-testing-checklist/index.html
and found a number of issues, some of which are serious:

https://jira.codehaus.org/browse/GEOS-5283
https://jira.codehaus.org/browse/GEOS-5284
https://jira.codehaus.org/browse/GEOS-5285
https://jira.codehaus.org/browse/GEOS-5286
https://jira.codehaus.org/browse/GEOS-5287

Now, I don’t understand how we got to RC3 with some of the above in the wild,
all I can think of is that the manual release testing script has never been used
in the previous RCs.

https://jira.codehaus.org/browse/GEOS-5283 makes GeoServer installed via the
bin package (and by extension probably the win/osx installers) go OOM after
just a handful of WCS demo requests.
The OOM is due to permgen exhaustion, WCS makes GS load quite a bit
of EMF classes and so on, it’s something that one would not see by just running
WMS requests

http://jira.codehaus.org/browse/GEOS-5284 seems to be locking the WFS schemas
class pretty good trying to access some network resource, when that happens
any attempt to save the configuration in GeoServer fails because that results in
the WFS schemas being reset, but they are locked so that won’t happen and
the installation is toast.
Fixing the demo request is easy, but the underlying issue is grave, we should have
some timeout mechanism in the schema fetching subsystem when some incoming
request links to schema urls that fails to respond (and keeps you hanging instead
or returning a HTTP error code).
I think we’ve been over this before, but I guess this time we have a better perspective
on how dangerous this problem is.
This one is related, I guess we need to register a custom uri handler that can set
timeouts on the input streams by default too.
http://jira.codehaus.org/browse/GEOS-4854
Wondering, can URI handers be sorted somehow? We’d need the WFS one for
DFT, but also a general one that can timeout in some given time.

https://jira.codehaus.org/browse/GEOS-5285 is actually a side effect of the previous
one, once I’ve restarted GeoServer it started responding, the issue here is that
this one uses gt-xsd to parse the SLD 1.1 provided, and needs the schema cache too,
which is locked…

https://jira.codehaus.org/browse/GEOS-5286 is trivial but annoying, it’s the very first
preview we have in the list, not a very good first impression.

https://jira.codehaus.org/browse/GEOS-5287 is the usual KML issues, in some new
sauce I guess.

Jody is helping me fix the startup scripts for https://jira.codehaus.org/browse/GEOS-5283,
I can have a look at some of the others too, not sure I can fix GEOS-5284 by myself though

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

2

On Sat, Aug 25, 2012 at 11:06 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
I was doing the usual “manual testing script” at http://docs.geoserver.org/latest/en/developer/release-testing-checklist/index.html
and found a number of issues, some of which are serious:

https://jira.codehaus.org/browse/GEOS-5283
https://jira.codehaus.org/browse/GEOS-5284
https://jira.codehaus.org/browse/GEOS-5285
https://jira.codehaus.org/browse/GEOS-5286
https://jira.codehaus.org/browse/GEOS-5287

5283 and 5286 fixed, 5285 happened to be a side effect of GEOS-5284.
Looking into GEOS-5284 now, although I guess that would have to be solved
at the GeoTools level to make sure all xsd based parser behave properly

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

3

On Sat, Aug 25, 2012 at 12:42 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Sat, Aug 25, 2012 at 11:06 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
I was doing the usual “manual testing script” at http://docs.geoserver.org/latest/en/developer/release-testing-checklist/index.html
and found a number of issues, some of which are serious:

https://jira.codehaus.org/browse/GEOS-5283
https://jira.codehaus.org/browse/GEOS-5284
https://jira.codehaus.org/browse/GEOS-5285
https://jira.codehaus.org/browse/GEOS-5286
https://jira.codehaus.org/browse/GEOS-5287

5283 and 5286 fixed, 5285 happened to be a side effect of GEOS-5284.
Looking into GEOS-5284 now, although I guess that would have to be solved
at the GeoTools level to make sure all xsd based parser behave properly

I’ve attached a patch and some explanation of what I’ve found out here:
https://jira.codehaus.org/browse/GEOS-5284

Some review would be appreciated.

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

4

On Sat, Aug 25, 2012 at 12:42 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Sat, Aug 25, 2012 at 11:06 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
I was doing the usual “manual testing script” at http://docs.geoserver.org/latest/en/developer/release-testing-checklist/index.html
and found a number of issues, some of which are serious:

https://jira.codehaus.org/browse/GEOS-5283
https://jira.codehaus.org/browse/GEOS-5284
https://jira.codehaus.org/browse/GEOS-5285
https://jira.codehaus.org/browse/GEOS-5286
https://jira.codehaus.org/browse/GEOS-5287

5283 and 5286 fixed, 5285 happened to be a side effect of GEOS-5284.
Looking into GEOS-5284 now, although I guess that would have to be solved
at the GeoTools level to make sure all xsd based parser behave properly

Ok, got a grip on GEOS-5287 as well, it’s partly due to my GE configuration
but still GeoServer’s behavior is imho wrong (or at least GE does not like it).

When buidilng a superoverlay GS always builds two to four network links
to the childs of the current tile, and it does so blindly, without checking if
these requests will result in any data.

What happens when a superoverlay request comes in and finds no data to
paint? You get back a HTTP 204, which was used to communicate GWC
to stop seeding that area.

Unfortunately if GE is setup to report network errors it will handle that 204
as an error, and you’ll get continuous popups telling you an error occurred.

Long story short, this has been there forever, I just happened to have GE
configured the right way to spot the problem (this setup is quite useful to
debug apps serving data to GE, otherwise you don’t get to know what
happened, so while not being common in the general population it probably
is for whoever is developing apps serving data to GE).

What options do we have? I guess, develop yet another utility method telling
us if a certain tile has at least one feature inside, and generate the network
link only in such case.
Going to look into this, should not be too hard.

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

5

On Sat, Aug 25, 2012 at 4:22 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

What options do we have? I guess, develop yet another utility method telling
us if a certain tile has at least one feature inside, and generate the network
link only in such case.
Going to look into this, should not be too hard.

Here is a simple patch, could use a review:
https://jira.codehaus.org/browse/GEOS-5287

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

6

https://jira.codehaus.org/browse/GEOS-5236 is a blocker. We are stuck on
2.1.3 till its fixed, let alone 2.2

Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents.

7

On Sun, Aug 26, 2012 at 11:40 PM, Phil Scadden <p.scadden@anonymised.com> wrote:

https://jira.codehaus.org/browse/GEOS-5236 is a blocker. We are stuck on
2.1.3 till its fixed, let alone 2.2

Phil, it does not work like that. SDE is an extension, not core, it cannot block a release,
a true blocker is a bug that affects the majority of users.

The SDE connector, like other connectors to commercial only software, often get
improvements only based on commercial contracts, I don’t see people trying to fix
it in their weekend or late at night after dinner, there is just no driver from an open
source developer point of view: for PostGIS, maybe, but not for SDE
(for the record I’ve spent a couple of hours looking at that one during a weekend,
but it was not enough, just recorded my findings in the ticket).

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

8

On Mon, Aug 27, 2012 at 4:08 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

On Sun, Aug 26, 2012 at 11:40 PM, Phil Scadden <p.scadden@anonymised.com> wrote:

https://jira.codehaus.org/browse/GEOS-5236 is a blocker. We are stuck on
2.1.3 till its fixed, let alone 2.2

Phil, it does not work like that. SDE is an extension, not core, it cannot
block a release,
a true blocker is a bug that affects the majority of users.

The SDE connector, like other connectors to commercial only software, often
get
improvements only based on commercial contracts, I don't see people trying
to fix
it in their weekend or late at night after dinner, there is just no driver
from an open
source developer point of view: for PostGIS, maybe, but not for SDE
(for the record I've spent a couple of hours looking at that one during a
weekend,
but it was not enough, just recorded my findings in the ticket).

Agreed.
It should be fixed now nevertheless. Phil, could you confirm with
tonight's nightly and close the ticket or comment on it?

Cheers,
Gabriel

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

9

Thanks for that fix Gabriel. I am looking at getting it going now on our
test server. And sorry if I came across too strong there, I really do
appreciate your efforts and also that support needs to be paid for. We
are stuck with SDE for moment (though connectivity improvements from
arcMap to POSTGIS in 10 might change that) but we are also stuck with
SDE 9.3. Windows7 + Novell + arcMap10 is a terrible combination but
rare enough that fixes are glacially slow and we cant move SDE to 10
till everyone is off arcMap9.3.

Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents.