Project

General

Profile

Bug #8090

getNamedChannelData hangs when asked for a date before start of folder

Added by Philip Rodrigues over 4 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
Normal
Start date:
03/14/2015
Due date:
% Done:

100%

Estimated time:
3.00 h
Duration:

Description

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

test_nucondb.cxx (734 Bytes) test_nucondb.cxx Philip Rodrigues, 03/14/2015 11:27 AM

History

#1 Updated by Marc Mengel over 4 years ago

Phillip,

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
cut...

I can make the nucondb bundle for you, I think...

#2 Updated by Philip Rodrigues over 4 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 4 years ago

I put the latest up here in the project "files" page:

https://cdcvs.fnal.gov/redmine/attachments/download/23968/nucondb-client-2.3.tgz

#4 Updated by Philip Rodrigues over 4 years ago

Thanks! One question: there's an ifbeam.c and and ifbeam.cc file in that tarball. Are they both needed? Our cmt builder gets confused by that (because it tries to write two make targets for ifbeam.o).

#5 Updated by Philip Rodrigues over 4 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:

"""
getDataWithTimeout: url='http://mnvcon-data.fnal.gov:8088/mnvcon_prd/app/data?f=minerva_febs_eroicakludge&t=1378252799.000000'
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
getDataWithTimeout: url='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.)

#6 Updated by Philip Rodrigues over 4 years ago

Hi Marc,

Did I analyse this case right? Is it something that can be handled differently in nucondb, or should we continue to work around it in minerva code?

Thanks,
Phil

#7 Updated by Marc Mengel over 4 years ago

  • Project changed from NuConDB-client to LibWDA
  • Assignee set to Vladimir Podstavkov

Passing this over to Vladimir, I believe this retry logic is in the
libwda code these days. It probably should only retry on >501 error
codes.

#8 Updated by Vladimir Podstavkov over 2 years ago

  • Status changed from New to Work in progress
  • % Done changed from 0 to 20
  • Estimated time set to 3.00 h

#9 Updated by Vladimir Podstavkov over 2 years ago

  • % Done changed from 20 to 50

#10 Updated by Vladimir Podstavkov almost 2 years ago

  • Status changed from Work in progress to Resolved
  • % Done changed from 50 to 100


Also available in: Atom PDF