Calling DescribeFeatureType causes 100% CPU-bound in deegree3 webapp

[GoogleCodeExporter]

What steps will reproduce the problem?
1. run the webapps/deegree3 webapp (no data in DB needed)
2. go to OGC client console in browser
3. select "General" | "DescribeFeatureType"

What is the expected output? What do you see instead?
XML output from DescribeFeatureType. Instead the process hangs with CPU to 
100%. This was reproducable on both Linux+Mac, with and without data in PostGIS 
(inspire_blob db). 

Please use labels and text to provide additional information.
This did not happen before, but today (28 sep 2010 10:45) when using the latest 
deegree3 snapshots. I am attaching the entire Maven build/run output here. The 
webapp config files used can be found in SVN (webapps/deegree3).

This issue prevents me to put the services in production for ESDIN testing 
since I have to restart the server.

Original issue reported on code.google.com by jus...@gmail.com on 28 Sep 2010 at 9:05

Attachments:

• deegree3-output.txt

[GoogleCodeExporter]

Markus is this something that looks familiar or you can look into ?

Original comment by jus...@gmail.com on 28 Sep 2010 at 11:11

[GoogleCodeExporter]

Running in debugger. It seems to be an endless loop in class 
DescribeFeatureTypeHandler, method determineRequiredNamespaces() line 407
(var "add" always seems non-empty)

// add dependent namespaces
Set<String> add = findUnhandledNs( set );
while ( !add.isEmpty() ) {
    set.addAll( add );
    add = findUnhandledNs( set );
}

Original comment by jus...@gmail.com on 28 Sep 2010 at 11:25

• Changed state: Started

[GoogleCodeExporter]

Thanks for the analysis. I am aware of this problem. Actually, I am currently 
adding support for custom output formats which involves restructuring of the 
relevant code paths. This will solve two issues:

1. It will be possible to configure the root element for GetFeature responses 
(e.g. gml:FeatureCollection instead of wfs:FeatureCollection)
2. It will add configuration options for the returned schema 
(DescribeFeatureType responses). This will finally allow to validate the 
responses of the INSPIRE-WFS, as the generic reexporting of the schema proves 
to be more troublesome than I expected.

Original comment by mar...@beefcafe.de on 28 Sep 2010 at 6:41

[GoogleCodeExporter]

Thanks. Ok this is good to hear, I was about to ask about how to configure the 
GetFeature container format. Any timeframe ?

Original comment by jus...@gmail.com on 29 Sep 2010 at 10:29

[GoogleCodeExporter]

Should be done in the next days. BTW, sorry for the current inconveniences 
concerning stability, but a lot is happening behind the scenes. I would suggest 
to switch dependency from 3.0-SNAPSHOT to a tagged build (3.0-pre10?) as soon 
as an acceptable status has been reached. This way, we can minimize the impact 
of day-to-day changes in deegree 3 on the project.

Original comment by mar...@beefcafe.de on 29 Sep 2010 at 8:00

[GoogleCodeExporter]

Was fixed and verified so can be closed.

Original comment by jus...@gmail.com on 16 Nov 2010 at 10:42

• Changed state: Verified