NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
My best guess is that you are seeing some kind of thread-safety issue in our code. But apparently triggered or made more likely by client abort exceptions ??
what is this exception: "When the capabilites document with 0 byte size is fetched, the earlier mentioned exception is thrown." ?
On 3/16/2010 9:05 AM, Jonathan Blower wrote:
Hi Heiko, Ethan, I've been trying to figure out what might be going on here - thanks for your great diagnosis Heiko. I'm not sure what can be done in the THREDDS/WMS code to prevent this, but I've modified some code in the ncWMS WmsController class to attempt to catch exceptions that are thrown when clients disconnect: http://www.resc.rdg.ac.uk/trac/ncWMS/browser/branches/tds-refactor-2010- 01-09/src/java/uk/ac/rdg/resc/ncwms/controller/WmsController.java#L250 Heiko - you mentioned that it's possible that poor exception handling could cause a tomcat thread to be left in an invalid state. I can't reproduce your problem reliably so I can't test this myself, but I wonder if you could find out whether this is happening in your setup? The VisualVM tool (http://java.sun.com/javase/6/docs/technotes/guides/visualvm/) can give a thread dump from your running Tomcat system - perhaps you could run this when an error occurs and see if anything is suspicious? Ethan - are you able to reproduce Heiko's problem? Cheers, Jon -----Original Message----- From: Ethan Davis [mailto:edavis@xxxxxxxxxxxxxxxx] Sent: 05 March 2010 23:32 To: Heiko Klein Cc: Jonathan Blower; thredds@xxxxxxxxxxxxxxxx Subject: Re: [thredds] ncWMS GetCapabilities return sometimes empty document Hi Heiko, That is great. Thanks. I'm a bit swamped through next week but I will jump on this the following week before I get to some other WMS work. Thanks, Ethan On 3/5/2010 4:44 AM, Heiko Klein wrote:Hi, finally, I managed to generate a simple case how to reproduce thiserror:a) start tomcat b) abort fetching some maps (3-4 times on a tomcat with 10thredds/HTTP1.1 connector), i.e. call GET'http://localhost:8081/thredds/wms/data/met.no/hirlam12/wam_nsea.fc.2009 0604.nc?REQUEST=GetMap&LAYERS=significant_wave_height&PALETTE=redblue&SE RVICE=WMS&FORMAT=image/png&VERSION=1.3.0&CRS=EPSG:4326&BBOX=-30,-60,30,9 0&WIDTH=400&HEIGHT=400&STYLES=BOXFILL/ncview'/dev/nulland abort this call before it is finished. (Ctrl-C) c) get some 'getCapabilities' documents: while [ 1 ]; do GET'http://localhost:8081/thredds/wms/data/met.no/hirlam12/wam_nsea.fc.2009 0604.nc?service=WMS&version=1.3.0&request=GetCapabilities'testCap.xml; ls -l testCap.xml; done... -rw-r--r-- 1 heikok heikok 172126 2010-03-05 12:11 testCap.xml -rw-r--r-- 1 heikok heikok 172126 2010-03-05 12:11 testCap.xml -rw-r--r-- 1 heikok heikok 172126 2010-03-05 12:11 testCap.xml -rw-r--r-- 1 heikok heikok 0 2010-03-05 12:11 testCap.xml -rw-r--r-- 1 heikok heikok 172126 2010-03-05 12:11 testCap.xml -rw-r--r-- 1 heikok heikok 172126 2010-03-05 12:11 testCap.xml When the capabilites document with 0 byte size is fetched, the earlier mentioned exception is thrown. Since step b) is the crucial step to reproduce the 0 byte document, I guess there is somewhere a badly caughtClientAbortException/IOExceptionwhen writing to the responses OutputStream, leaving a tomcat-thread in an invalid state. We can solve this problem currently by adding a proxy in front of thredds (apache mod_proxy) which seems to swallow all client-connection-aborts before they reach tomcat. Best regards, Heiko On 2010-02-19 16:54, Heiko Klein wrote:Hi, I'm still trying to track down this problem, so here a short update: The ncWMS/TDS crashes seems to be connected to concurrency: Theproblemoccurs when reloading the wms-client (openlayers in firefox), thatmeansGetCapabilites and GetMap are run in parallel. We're downloadingtiles,so reloading will fetch one capability doc + approx 12 maps. * If I configure tomcat to only use one thread, and use the default 'HTTP/1.1' connector, the problem disappears (but response-times are very slow). * Using 4 threads + 'HTTP/1.1', the problem appears very fast. (oneortwo reloads) * Using the 'Nio' connector and 4 threads, the problem appears, butnotso fast (3-4 reloads) * Using the 'Nio' connector with only one thread, is about the sameasNio with several threads. Best regards, Heiko _______________________________________________ thredds mailing list thredds@xxxxxxxxxxxxxxxx For list information or to unsubscribe, visit:http://www.unidata.ucar.edu/mailing_lists/_______________________________________________ thredds mailing list thredds@xxxxxxxxxxxxxxxx For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
thredds
archives: