We're updating the issue view to help you get more done. 

Sticky state for containers (?) when switching back and forth between the default and virtual file systems

Description

Still working on a good description. Here's a bes command file that shows the error:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 <?xml version="1.0" encoding="UTF-8"?> <bes:request xmlns:bes="http://xml.opendap.org/ns/bes/1.0#" reqID="[thread:http-nio-8080-exec-6-24][bes_client:/-0]"> <bes:setContext name="bes_timeout">3000</bes:setContext> <bes:setContext name="xdap_accept">2.0</bes:setContext> <bes:setContext name="dap_explicit_containers">no</bes:setContext> <bes:setContext name="errors">xml</bes:setContext> <bes:setContext name="max_response_size">0</bes:setContext> <bes:setContainer name="c1">/RemoteResources/test/httpd_catalog/fnoc1.nc</bes:setContainer> <bes:define name="d1"> <bes:container name="c1" /> </bes:define> <bes:get type="dds" definition="d1" /> <bes:setContainer name="c1">/data/csv/temperature.csv</bes:setContainer> <bes:define name="d1"> <bes:container name="c1" /> </bes:define> <bes:get type="dds" definition="d1" /> <bes:setContainer name="c2">/data/csv/temperature.csv</bes:setContainer> <bes:define name="d1"> <bes:container name="c2" /> </bes:define> <bes:get type="dds" definition="d1" /> </bes:request>

The response should be to show the fnoc1 DDS and then two copies of the CSV file's DDS, but instead the second request (of the three) returns fnoc1's DDS.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 edamame:tests jimg$ besstandalone -c bes.conf -i httpd_catalog_4.xml Dataset { Int16 u[time_a = 16][lat = 17][lon = 21]; Int16 v[time_a = 16][lat = 17][lon = 21]; Float32 lat[lat = 17]; Float32 lon[lon = 21]; Float32 time[time = 16]; } httpd_cat_229cfd09608045bbfb1d1c03a6572356e370bdb28f425be461d5ff39505b7d20; Dataset { Int16 u[time_a = 16][lat = 17][lon = 21]; Int16 v[time_a = 16][lat = 17][lon = 21]; Float32 lat[lat = 17]; Float32 lon[lon = 21]; Float32 time[time = 16]; } httpd_cat_229cfd09608045bbfb1d1c03a6572356e370bdb28f425be461d5ff39505b7d20; Dataset { String Station[record = 5]; Float32 latitude[record = 5]; Float32 longitude[record = 5]; Float32 temperature_K[record = 5]; String Notes[record = 5]; } temperature.csv;

Questions:

  • Is this a fail with the container, the container storage or the definitions?

  • Is this a real problem - the OLFS never issues requests like this? It seems we see this sticky behavior in a real running server when using the web interface, but I'm not able to reproduce that now

Environment

None

Status

Assignee

James Gallagher

Reporter

James Gallagher

Labels

Fix versions

Story Points

3

Affects versions

Hyrax 1.15.4

Epic Link

Priority

High