getNamedChannelData hangs when asked for a date before start of folder
It looks like getNamedChannelData hangs when the date requested is before the start date of the folder. The specific case we see is the folder minerva_febs_eroicakludge at URL http://mnvcon-data.fnal.gov:8088/mnvcon_prd/app/ hangs when asked for a date before t=1378252800
I've attached a test case
#1 Updated by Marc Mengel over 5 years ago
This sounds like a bug that was fixed a while ago in the ifbeam client code;
The question is do we want to cut a nucondb bundle again, or do we want to
convert the MINERvA build to use the external packages for this, that are already
I can make the nucondb bundle for you, I think...
#2 Updated by Philip Rodrigues over 5 years ago
We (Minerva) should probably just catch up with the current version as it exists, instead of having a copy of all the code in our repository.
We could try using the ups versions, but I'm not sure how to add the necessary include and link paths to our code, or we could just download and build the code in our build stage, which is how we deal with other external packages.
Probably the latter is easiest for us - could you point me to a link to download the nucondb source?
#3 Updated by Marc Mengel over 5 years ago
I put the latest up here in the project "files" page:
#5 Updated by Philip Rodrigues over 5 years ago
OK, I see that they are both needed, so I renamed ifbeam.c to ifbeam_c.c (following the header file ifbeam_c.h).
But it doesn't seem to fix the underlying problem. I reran my little test job, with debug turned on in wda.c and nucondb.cc, and I see:
HTTP status code=400: 'Data not found'
ret=0, k=1, delay=1, t0=1426884221, t1=1426884222 to=0
mget_http_response: 14 bytes retrieved
get_data_rows: 14 bytes retrieved
sleeping 0 and retrying for status: 400 message: Data not found
getting data at: http://mnvcon-data.fnal.gov:8088/mnvcon_prd/app/data?f=minerva_febs_eroicakludge&t=1378252799.000000
[repeats with longer sleeps]
But the 400 error in this case is 'data not found', so retrying doesn't make sense, right? What would work for us is to have it throw as soon as 'data not found' is returned.
(We run into the case when trying to retrieve calibration constants for a subdetector for a time before the subdetector was installed. We can work around it, but it would be easier if nucondb threw immediately instead of waiting a very long time.)