Hi Bruce,Ah ha. I think I got it, at least for the repeating "dodsC". Can you move all your catalogs out from under the content/thredds/dodsC directory? I would make a new subdirectory and put them under that (and don't forget to change the link in your content/thredds/catalog.xml). The problem is that the dodsC directory matches the OPeNDAP servlet path which seems to be causing some confusion. The various servlets are mapped to url paths in the web.xml file like this
<servlet-mapping> <servlet-name>NetcdfDODS</servlet-name> <url-pattern>/dodsC/*</url-pattern> </servlet-mapping>The url pattern is the section of the URL that follows right after "/thredds". There are a number of servlet mappings and they all need to be avoided. Here's the full list from the TDS web.xml file: "ldm", "dodsC", "dqc", "fileServer", "ncServer", "obsServer", "wcs", "cataloggen", "catalog", "catalogServices", "cdmValidate", "modelInventory", "DLwriter", "view".
Not sure about the rest. Let's try not using the "dodsC" directory for your catalogs with the 3.10 server and see how far that gets us.
Ethan Bruce Flynn wrote:
Hi again Ethan,I'm sorry, but I'm having continuous problems getting this server running correctly. I noticed some errors when upgrading to thredds.war 3.10. After upgrading you have to click on the root catalog links twice, and an extra dodsC is generated in the URL. For example, with the root catalog appearing as in the tar file I sent you, there are 2 links on the root page:Shelevs/-- link to the actual data archiveSSEC XSAN Users Access/-- link to generated for "user friendly" access to archive The url in the address bar is "http://sands01:8080/thredds/catalog.html";. If you click on the "SSEC..." link the url changes to "http://sands01:8080/thredds/dodsC/catalog.html"; while the page does not change at all(ie. the links are the same as above). And all subsequent urls, as you traverse the catalogs, display "http://sands01:8080/thredds/dodsC/dodsC/.../... <http://sands01:8080/thredds/dodsC/catalog.html>" which has an extra dodsC. The Shelves links, generated by a datasetScan element, seem to work fine. This may be because the Shelves catalog tree does not contain any OpenDAP services. This just started happening after upgrading. My root catalog has not changed from what was in the tar and the rest of the non-leaf catalogs just contain catalog refs, so I reinstalled the thredds.war version 3.8 and the problem disappeared. I was reading the change log and saw that there were some changes dealing with dataRoots and I thought that for once the problem may not be me ... maybe.I also tried you suggestion below because it's just disheartening to see all those errors in the logs and I still get the errors below:...2006-06-15T20:43:25.850 +0100 [ 42502][ 1] ERROR - thredds.servlet.DataRootHandler2 - already have dataRoot =<Shelves/0af2/7a0e/0af27a0e-0412-4f7d-9cf2-f6d92cbb97cb> mapped to directory= </Volumes/gulf1/Shelves/0af2/7a0e/0af27a0e-0412-4f7d-9cf2-f6d92cbb97cb/> 2006-06-15T20:43:26.083 +0100 [ 42735][ 1] ERROR - thredds.servlet.DataRootHandler2 - already have dataRoot =<Shelves/e2d6/4f35/e2d64f35-5315-44d4-8def-28f40a260523> mapped to directory= </Volumes/gulf1/Shelves/e2d6/4f35/e2d64f35-5315-44d4-8def-28f40a260523/>...Each datasetRoot is now generated from a UUID so there should be no duplication of the datasetRoot path or location attributes so I'm a little confused.I hope I'm making sense. I thought it might help if you had access to the TDS server I'm working on so I talked to our network guys and they say that if you were willing to give the ip address you're working from they could punch a hole through the firewall to give you access.Bruce On Jun 12, 2006, at 6:23 PM, Ethan Davis wrote:Hi Bruce,I suspect that with your upgrade to TDS 3.10 that you will still get the error messages you listed but that the TDS should work as desired. As I mentioned, the TDS keeps track of a datasetScan/datasetRoot for each unique path. If it finds a duplicate, it writes the error message (it will be a warning in our next release) and continues. Doesn't look like the duplication should cause any trouble.From your content/thredds/catalog.xml <datasetScan dirLocation="/Volumes/gulf1/Shelves/" path="Shelves" name="Shelves" serviceName="other">From your content/thredds/dodsC/Modeled_Data/Fulldisk8km/Profiles/Oct05/2003_0624_1800/catalog.xml<service name="group" base="" serviceType="Compound" ><service name="dods" base="/thredds/dodsC/" serviceType="OpenDAP" /> <service name="http" base="/thredds/fileServer/" serviceType="HTTPServer" /> <datasetRoot path="Shelves" dirLocation="/Volumes/gulf1/Shelves/"/></service> ...<dataset name="8km_0624_2003.1800utc_10_3.nc" ID="aa057bd8-2104-44ee-bef7-51859bac9627-8km_0624_2003.1800utc_10_3.nc" >...<access urlPath="Shelves/aa05/7bd8/aa057bd8-2104-44ee-bef7-51859bac9627/8km_0624_2003.1800utc_10_3.nc" serviceName="group" /></dataset>One thing you could do to get rid of this duplication ... If all the access urlPaths in each catalog are the same except for the final dataset name, you could put the whole thing in your datasetRoot path. So, in the above example you could instead have:<service name="group" base="" serviceType="Compound" ><service name="dods" base="/thredds/dodsC/" serviceType="OpenDAP" /> <service name="http" base="/thredds/fileServer/" serviceType="HTTPServer" /> <datasetRoot path="Shelves/aa05/7bd8/aa057bd8-2104-44ee-bef7-51859bac9627" dirLocation="/Volumes/gulf1/Shelves/aa05/7bd8/aa057bd8-2104-44ee-bef7-51859bac9627/"/></service> ...<dataset name="8km_0624_2003.1800utc_10_3.nc" ID="aa057bd8-2104-44ee-bef7-51859bac9627-8km_0624_2003.1800utc_10_3.nc" >...<access urlPath="Shelves/aa05/7bd8/aa057bd8-2104-44ee-bef7-51859bac9627/8km_0624_2003.1800utc_10_3.nc" serviceName="group" /></dataset> But I think the only advantage would be cleaning up your log files. Hope this makes sense. Ethan -- Ethan R. Davis Telephone: (303) 497-8155 Software Engineer Fax: (303) 497-8690UCAR Unidata Program Center E-mail: address@hidden <mailto:address@hidden>P.O. Box 3000Boulder, CO 80307-3000 http://www.unidata.ucar.edu/--------------------------------------------------------------------------- =============================================================================== To unsubscribe thredds, visit: http://www.unidata.ucar.edu/mailing-list-delete-form.html ===============================================================================
-- Ethan R. Davis Telephone: (303) 497-8155 Software Engineer Fax: (303) 497-8690 UCAR Unidata Program Center E-mail: address@hidden P.O. Box 3000 Boulder, CO 80307-3000 http://www.unidata.ucar.edu/ ---------------------------------------------------------------------------