[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[THREDDS #SPQ-636224]: Offline gbx8 files causing ucar.ma2.InvalidRangeException in TDS 4.2.3

Hi Greg,

This may be a version mismatch between the netCDF-Java library you are using 
and the one TDS 4.2.3 uses. Though I think the version at the FTP location you 
give should match up.

There has been a lot of work on the GRIB part of netCDF-Java over the last few 
months. And there has also been a lot of work on the FMRC code recently.

Not being super familiar with that code, I'm going to leave this for one of our 
GRIB experts to answer. Unfortunately, they are both on vacation but one 
returns tomorrow and the other next week. So they should be able to get back to 
you soon.


Greg Williams wrote:
> We are running the latest version of the THREDDS data-server (4.2.2 and
> now 4.2.3 this week) and have a number of aggregated model-data
> collections (FMRCs) - including GFS model data, which is available as a
> collection of GRIB2 files (one for each forecast time) per
> reference/runtime.
> Defining an FMRC has always worked fine on all versions of TDS
> (including 4.1-series, 4.2.x, and now 4.2.3), and on startup/access the
> TDS automatically indexes the GRIB files to create a set of local *.gbx8
> files in it's cached area (under 'cache/cdm' by default).
> This takes some startup time (to recatalog and index the raw files from
> scratch), and of course the cache expires eventually so the indexing may
> have to be repeated multiple times in future.
> Lately, we've been creating offline index files, using the latest
> java-NetCDF version (4.2) available here:
> ftp://ftp.unidata.ucar.edu/pub/netcdf-java/v4.2/netcdfAll-4.2.jar
> ...and the command-line (for each GRIB2 file) of:
> java -Xmx128m -classpath netcdfAll-4.2.jar
> ucar.grib.grib2.Grib2WriteIndex gfs.t12z.pgrbf06 gfs.t12z.pgrbf06.gbx8
> This creates *.gbx8 files (offline) adjacent to the raw data-files, and
> the TDS seems happy to use those rather than make it's own index files
> in the THREDDS cache area.
> Unfortunately, we're now seeing an 'InvalidRangeException' like this:
> ucar.ma2.InvalidRangeException: Number of ranges in section (3) must
> be = 4
> ... triggered by any attempts to access the FMRCs.  No files or catalog
> definitions have changed - just the addition of local *.gbx8 files for
> these data.
> Is this an incompatibility between the standalone java-NetCDF release
> 4.2 and the same library components used within the latest TDS 4.2.3?
> Or in the command I used to create the offline index files?
> Can you recommend a better way to support offline indexes in this way?
> (I realise I should be able to simply delete all the offline-created
> *.gbx8 files and revert to the TDS-created ones, but I'm still
> interested in improving the startup and indexing time for large model
> collections).
> Thanks.
> Greg.
> ---
> 2011-01-19T13:15:28.798 +0000 [  66161567][    1851] ERROR - 
> thredds.server.opendap.NcSDArray -
>   NcSDArray read u_wind time(729,1,729) lat(62,1,94) lon(16,1,62) 
> ucar.ma2.InvalidRangeException:
>   Number of ranges in section (3) must be = 4
> at ucar.ma2.Section.fill(Section.java:144)
> at ucar.nc2.Variable.read(Variable.java:645)
> at ucar.nc2.dataset.VariableDS.reallyRead(VariableDS.java:546)
> at ucar.nc2.dataset.VariableDS._read(VariableDS.java:526)
> at ucar.nc2.Variable.read(Variable.java:645)
> at ucar.nc2.Variable.read(Variable.java:619)
> at thredds.server.opendap.NcSDArray.read(NcSDArray.java:114)
> at thredds.server.opendap.NcSDGrid.read(NcSDGrid.java:72)
> at opendap.dap.Server.SDGrid.serialize(SDGrid.java:532)
> at opendap.dap.Server.CEEvaluator.send(CEEvaluator.java:297)
> at 
> thredds.server.opendap.OpendapServlet.doGetDAP2Data(OpendapServlet.java:534)
> at thredds.server.opendap.OpendapServlet.doGet(OpendapServlet.java:222)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> [...]

Ticket Details
Ticket ID: SPQ-636224
Department: Support THREDDS
Priority: Normal
Status: Open

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.