On Wed, Mar 2, 2011 at 1:55 PM, Roger Bedell <[email protected]> wrote:
> > Some more information about the WFS SocketTimeout. (read timeout) we've > been seeing: > > This appears to be something newish, definitely not a good thing, plus very > hard to reproduce or characterize. I have two mostly identical servers, one > with the latest nightly of 2.1.x, and the other with 1.7.6, both hitting the > same PostGIS database on another machine over the same network. The 2.1.x > machine is actually a faster machine with more RAM. > > Using a recent uDig, (1.2.1), I set up a map with a variety of WFS layers, > some large, some small. The 1.7.6 always (well mostly, except after long > periods of inactivity when it gets connection timeouts) works fine, never > any read timeouts. The 2.1.x gets these timeouts on random layers, sometimes > works fine, sometimes fails. What is interesting, is that the timeout occurs > fairly quickly, within about 6 seconds after I hit refresh. It doesn't seem > to matter the size of the layer, small ones seem to time out will similar > frequency to large ones. > > I'm not seeing anything strange in the geoserver log, no errors. > > This is really weird, and I don't have any clue how to proceed to fix it. > Anyone have any ideas on what to try? Any way to increase the read timeout > value? > > Update - I turned on Loose BBox and Estimated Extends, and it seems to be a > little better. What is "Estimated Extends" anyway? > I don't see how using "estimated extents" can help solving a parsing issue for data coming from a client. > > However, now I'm seeing this error in uDig: (again, inconsistently, and no > errors...): > > "Could not find element handler for http://www.opengis.net/gml: null as a > child of MultiPolygonPropertyType." > This sound completely unrelated? > > Attached is a uDig project that should show the issue. > > Perhaps it isn't sending everything back right? > > Any ideas on how to debug this? Or things to try? > Not really no. Try to identify the kind of client that generates the failing issue, then try to isolate the specific type of request that makes it fail. I've just never seen it, so it might be related to the kind of requests, the operating system, or the specific client being used. Honestly don't know. It's also odd that there have been two reports about this... Cheers Andrea -- ------------------------------------------------------- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 mob: +39 333 8128928 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf -------------------------------------------------------
------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________ Geoserver-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-users
