Provide byte-range reading of remote datasets #1267

DennisHeimbigner · 2019-01-02T01:29:35Z

Fixes netcdf lib open in memory question #1251

Assume that you have the URL to a remote dataset
which is a normal netcdf-3 or netcdf-4 file.

This PR allows the netcdf-c to read that dataset's
contents as a netcdf file using HTTP byte ranges
if the remote server supports byte-range access.

Originally, this PR was set up to access Amazon S3 objects,
but it can also access other remote datasets such as those
provided by a Thredds server via the HTTPServer access protocol.
It may also work for other kinds of servers.

Note that this is not intended as a true production
capability because, as is known, this kind of access to
can be quite slow. In addition, the byte-range IO drivers
do not currently do any sort of optimization or caching.

An additional goal here is to gain some experience with
the Amazon S3 REST protocol.

This architecture and its use documented in
the file docs/byterange.dox.

There are currently two test cases:

nc_test/tst_s3raw.c - this does a simple open, check format, close cycle
for a remote netcdf-3 file and a remote netcdf-4 file.
nc_test/test_s3raw.sh - this uses ncdump to investigate some remote
datasets.

This PR also incorporates significantly changed model inference code
(see the superceded PR #1259).

It centralizes the code that infers the dispatcher.
It adds support for byte-range URLs

Other changes:

NC_HDF5_finalize was not being properly called by nc_finalize().
Fix minor bug in ncgen3.l
fix memory leak in nc4info.c
add code to walk the .daprc triples and to replace protocol=
fragment tag with a more general mode= tag.

Final Note:
Th inference code is still way too complicated. We need to move
to the validfile() model used by netcdf Java, where each
dispatcher is asked if it can process the file. This decentralizes
the inference code. This will be done after all the major new
dispatchers (PIO, Zarr, etc) have been implemented.

re: issue #1251 Assume that you have the URL to a remote dataset which is a normal netcdf-3 or netcdf-4 file. This PR allows the netcdf-c to read that dataset's contents as a netcdf file using HTTP byte ranges if the remote server supports byte-range access. Originally, this PR was set up to access Amazon S3 objects, but it can also access other remote datasets such as those provided by a Thredds server via the HTTPServer access protocol. It may also work for other kinds of servers. Note that this is not intended as a true production capability because, as is known, this kind of access to can be quite slow. In addition, the byte-range IO drivers do not currently do any sort of optimization or caching. An additional goal here is to gain some experience with the Amazon S3 REST protocol. This architecture and its use documented in the file docs/byterange.dox. There are currently two test cases: 1. nc_test/tst_s3raw.c - this does a simple open, check format, close cycle for a remote netcdf-3 file and a remote netcdf-4 file. 2. nc_test/test_s3raw.sh - this uses ncdump to investigate some remote datasets. This PR also incorporates significantly changed model inference code (see the superceded PR #1259). 1. It centralizes the code that infers the dispatcher. 2. It adds support for byte-range URLs Other changes: 1. NC_HDF5_finalize was not being properly called by nc_finalize(). 2. Fix minor bug in ncgen3.l 3. fix memory leak in nc4info.c 4. add code to walk the .daprc triples and to replace protocol= fragment tag with a more general mode= tag. Final Note: Th inference code is still way too complicated. We need to move to the validfile() model used by netcdf Java, where each dispatcher is asked if it can process the file. This decentralizes the inference code. This will be done after all the major new dispatchers (PIO, Zarr, etc) have been implemented.

WardF · 2019-01-02T01:37:55Z

This pull request introduces 2 alerts when merging bf2746b into b16ecea - view on LGTM.com

new alerts:

2 for Empty branch of conditional

Comment posted by LGTM.com

DennisHeimbigner · 2019-01-02T03:38:22Z

Ok, I fixed the alerts, but I am baffled by the appveyor complaint.
It looks like we have amismatch between a struct and the initializers for it.
But I cannot see the mismatch. Even a count of the fields seems to be ok.

DennisHeimbigner · 2019-01-02T19:38:56Z

Ok, so I compared the problem structure (in H5FDpublic.h) for versions 1.8.17
and 1.10.3, and they differ. So I need to do some conditionals depending on the
HDF5 version. My guess is that the change occurred between 1.8 and 1.10.

between HDF5 versions 1.8 and 1.10. So modify H5FDhttp.c to be conditional on the HDF5 major+minor version from H5public.h

WardF · 2019-01-28T19:21:23Z

Merged in modifications from master, seeing a failure in builds using mpicc. Going to add a single instance (non comprehensive for now) of parallel builds to travis to catch compilation errors, will follow up here with more info as I go back and sort it out.

WardF · 2019-01-29T00:20:49Z

Seeing failures in the following tests when running which mpicc provided by mpich.

The following tests FAILED:
	 46 - nc_test_run_pnetcdf_test (Failed)
	 47 - nc_test_tst_formatx_pnetcdf (Failed)
	 50 - nc_test_tst_small (Failed)
	 52 - nc_test_tst_norm (Failed)
	 54 - nc_test_tst_nofill (Failed)
	 68 - nc_test (Child aborted)
	136 - nc_test4_tst_atts3 (Failed)

Details available at http://cdash.unidata.ucar.edu/viewTest.php?onlyfailed&buildid=7195

DennisHeimbigner · 2019-01-29T19:28:25Z

I think I forgot to enable pnetcdf. Without pnetcdf, I get no failures.

WardF · 2019-01-31T23:28:49Z

I've updated the travis images so that the proper errors are being reported now.

So, fixed the following: 1. Forgot to check for NC_FORMATX_PNETCDF case in one of the switches in NC_infermodel. 2. Accidentally turned on both the NC_64BIT_OFFSET and the NC_64BIT_DATA mode flags.

DennisHeimbigner · 2019-02-01T21:47:10Z

Added fixes for the parallel case.

mathstuf · 2019-06-06T20:36:14Z

libdispatch/dinfermodel.c

+ conflictset(MF,model->format,NC_FORMAT_64BIT_DATA);
+ }
+ if(fIsSet(cmode,NC_NETCDF4)) {
+ conflictset(MF,model->format,NC_FORMAT_NETCDF4);


I'm looking at an issue where passing NC_NOWRITE | NC_64BIT_OFFSET | NC_NETCDF4 | NC_CLASSIC_MODEL flags worked in 4.6.2, but fails in 4.7.0 in this function. It seems to be detecting that we have the NC_FORMAT_64BIT_OFFSET as the format and then fails here because the format has already been set. Is this intended? Should it have worked before?

DennisHeimbigner · 2019-06-06T20:48:46Z

I would say that since NC_64BIT_OFFSET => classic format
that also specifying NC_NETCDF4 should be an error.

mathstuf · 2019-06-07T12:00:37Z

Thanks. Removing the NC_64BIT_OFFSET flag worked with the tests we have.

NetCDF 4.7.0 now detects this as an error because the mode is requesting a 64-bit offset format and a netcdf4 format and errors due to a conflicting format being requested. Upstream says that mixing these is an error. See: Unidata/netcdf-c#1267

DennisHeimbigner requested a review from WardF as a code owner January 2, 2019 01:29

Ignore lgtm alerts

b2e24ea

DennisHeimbigner and others added 8 commits January 2, 2019 13:18

Merge branch 'master' into byterange.dmh

84c2bc0

It turns out the the type H5FD_class_t was changed

a7fa2d8

between HDF5 versions 1.8 and 1.10. So modify H5FDhttp.c to be conditional on the HDF5 major+minor version from H5public.h

Fix typo

6e76972

Another typo (sigh\!)

fe3ba09

typos3

dc491f9

typeo4

8cd4502

typo5

ac2e6f9

Merge branch 'master' into byterange.dmh

b27c7d8

WardF added 2 commits January 28, 2019 12:23

Temporarily added a set of parallel tests to .travis.yml.

9df45bc

Corrected a logic error when compiling with parallel enabled.

c49f425

WardF added this to the 4.7.0 milestone Jan 29, 2019

Merge branch 'master' into byterange.dmh

3662c4f

DennisHeimbigner added 3 commits February 1, 2019 12:00

ckp

65e9a46

Made some mistakes in handling the PNETCDF case.

e4cb5c8

So, fixed the following: 1. Forgot to check for NC_FORMATX_PNETCDF case in one of the switches in NC_infermodel. 2. Accidentally turned on both the NC_64BIT_OFFSET and the NC_64BIT_DATA mode flags.

remove some debug statements

6723a38

WardF and others added 4 commits February 7, 2019 14:28

Merge branch 'master' into byterange.dmh

1fde39c

Merge branch 'master' into byterange.dmh

a1f080d

Merge branch 'master' into byterange.dmh

f19cac7

Forgot to distribute ncmodel.h

24510f2

DennisHeimbigner and others added 4 commits February 23, 2019 17:14

master merge

45a8a26

conflict resolution

959c213

Master merge, conflict resolution, cleanup

0c59e13

Merge branch 'master' into byterange.dmh

e2b31ff

WardF self-assigned this Mar 19, 2019

WardF modified the milestones: 4.7.0, 4.6.4 Mar 19, 2019

WardF merged commit 6b470b2 into master Mar 19, 2019

WardF deleted the byterange.dmh branch March 19, 2019 20:04

mathstuf reviewed Jun 6, 2019

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Provide byte-range reading of remote datasets #1267

Provide byte-range reading of remote datasets #1267

DennisHeimbigner commented Jan 2, 2019 •

edited by WardF

Loading

WardF commented Jan 2, 2019

DennisHeimbigner commented Jan 2, 2019

DennisHeimbigner commented Jan 2, 2019

WardF commented Jan 28, 2019

WardF commented Jan 29, 2019

DennisHeimbigner commented Jan 29, 2019

WardF commented Jan 31, 2019

DennisHeimbigner commented Feb 1, 2019

mathstuf Jun 6, 2019

DennisHeimbigner commented Jun 6, 2019

mathstuf commented Jun 7, 2019

Provide byte-range reading of remote datasets #1267

Provide byte-range reading of remote datasets #1267

Conversation

DennisHeimbigner commented Jan 2, 2019 • edited by WardF Loading

WardF commented Jan 2, 2019

DennisHeimbigner commented Jan 2, 2019

DennisHeimbigner commented Jan 2, 2019

WardF commented Jan 28, 2019

WardF commented Jan 29, 2019

DennisHeimbigner commented Jan 29, 2019

WardF commented Jan 31, 2019

DennisHeimbigner commented Feb 1, 2019

mathstuf Jun 6, 2019

Choose a reason for hiding this comment

DennisHeimbigner commented Jun 6, 2019

mathstuf commented Jun 7, 2019

DennisHeimbigner commented Jan 2, 2019 •

edited by WardF

Loading