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.
Greetings Phil, Thank you for your reports on experimenting with TDS 5! A lot has changed in the underlying libraries, and it's been quite the process to try to get it out the door. First, the issues about the messages/stack traces in serverStartup.log. NetCDF-Java will look for the netCDF-C library on startup, and if it's found, the TDS will be able to return netCDF-4 files from the NetcdfSubset Service. The logging of that search process in TDS 5 is much more verbose than it was in TDS 4.x, and includes things like dumping the classpath to help with debugging where netCDF-Java searched for the C library. Unless you want NCSS to be able to return netCDF-4 files, the messages related to netCDF-C in serverStartup.log are harmless (I'll be toning those down shortly). Next, the WMS service issues. We've bumped the version of the WMS service bundled with TDS 5 from 1.x to 2.x. A lot changed with respect to how we integrate with that, and there are a few places where our usage of the underlying library isn't quite smoothed out. In this case, the message you see is related to the TDS not using the dataset cache provided with the server quite yet. The code in the WMS service is trying to release the file from its cache, but it wasn't in there to begin with. These are also mostly harmless, but highlight one of the final remaining integration points that needs to be hooked up. The fact that you only see these on Linux and not Windows is surprising, as I've seen them from time to time in the logs on my windows machine. I've experienced the slowness as well, but it's been limited to the first WMS call made to the server after startup. I believe the way we have the service integrated into the TDS effectively delays the bootstrap process of the WMS server until the first call, and that spinup time is quite noticeable. Once I've made it past that first call, however, the server responds pretty fast. Again, another integration point that needs smoothed out before the final release (but concerning when you experience it, for sure!). Cheers, Sean On Thu, Aug 13, 2020 at 5:49 PM Phil Scadden <P.Scadden@xxxxxxxxxx> wrote: > Despite this error, I find that Thredds beta is largely working. > > > > Viewing a dataset (which is rather slow) produces lots of these warnings: > > WARN - uk.ac.rdg.resc.edal.dataset.cdm.NetcdfDatasetAggregator - Dataset > /var/www/mnt/nzpm/PBE_Data/Thredds/gw/hpm_outputs20200810_6.nc is not in > active dataset list but has been asked to be released! This is not harmful > in itself but may indicate a coding error whereby a dataset has been marked > to be released from the cache multiple times. > > > > Only on linux, not on windows. > > > > > > > > *From:* thredds <thredds-bounces@xxxxxxxxxxxxxxxx> *On Behalf Of *Phil > Scadden > *Sent:* Thursday, 13 August 2020 16:31 > *To:* thredds@xxxxxxxxxxxxxxxx > *Subject:* [thredds] libnetcdf.so reported missing when changing from 4.6 > to 5 beta on linix > > > > 4.6 was working well on linux but after experimenting for a week with > thredds 5.0 beta on my local windows machine, I tried installing on our > development linux server and got odd results. Looking at the > serverStartup.log I see the libnetcdf.so missing message in the stack > dumps. What has changed between 4 and 5 that would be causing this error? > > > > > > ________________________________________________ > > Ngā mihi, Nā Phil Scadden > > Te Aroturuki Matepā Aronuku me te Pūtaiao Raraunga > > GNS Science Ltd 764 Cumberland St, Private Bag 1930, > > Dunedin, New Zealand Ph +64 3 4799663, 027 3463185 > > > > “Whāia te iti kahurangi ki te tūohu koe me he maunga teitei” > > > > Notice: This email and any attachments are confidential and may not be > used, published or redistributed without the prior written consent of the > Institute of Geological and Nuclear Sciences Limited (GNS Science). If > received in error please destroy and immediately notify GNS Science. Do not > copy or disclose the contents. > Notice: This email and any attachments are confidential and may not be > used, published or redistributed without the prior written consent of the > Institute of Geological and Nuclear Sciences Limited (GNS Science). If > received in error please destroy and immediately notify GNS Science. Do not > copy or disclose the contents. > _______________________________________________ > NOTE: All exchanges posted to Unidata maintained email lists are > recorded in the Unidata inquiry tracking system and made publicly > available through the web. Users who post to any of the lists we > maintain are reminded to remove any personal information that they > do not want to be made public. > > > thredds mailing list > thredds@xxxxxxxxxxxxxxxx > For list information or to unsubscribe, visit: > https://www.unidata.ucar.edu/mailing_lists/ >
thredds
archives: