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 archive
SSEC 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-8690
UCAR Unidata Program Center E-mail:
edavis@xxxxxxxx <mailto:edavis@xxxxxxxx>
P.O. Box 3000
Boulder, 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: edavis@xxxxxxxx
P.O. Box 3000
Boulder, CO 80307-3000 http://www.unidata.ucar.edu/
---------------------------------------------------------------------------
