bugfix: reading the run number from OCDB if the run description is not set, which...

This is a very old bug, and potentially responsible for bug
https://savannah.cern.ch/bugs/?62546

diff --git a/HLT/BASE/AliHLTComponent.cxx b/HLT/BASE/AliHLTComponent.cxx
index 0e95387ce0113089985e6b33d2a159c36d021bb5..bd26d4d03f0dbd82497c8d5dc4bd8f80fe770ff6 100644 (file)
--- a/HLT/BASE/AliHLTComponent.cxx
+++ b/HLT/BASE/AliHLTComponent.cxx
@@ -2131,7 +2131,18 @@ int AliHLTComponent::SetStopwatches(TObjArray* pStopwatches)
 AliHLTUInt32_t AliHLTComponent::GetRunNo() const
 {
   // see header file for function documentation
-  if (fpRunDesc==NULL) return kAliHLTVoidRunNo;
+
+  // 2010-02-11 OCDB is now the reliable source for the run number, it is
+  // initialized either by aliroot or the external interface depending
+  // on the environment. It turned out that the rundescriptor is not set
+  // in the aliroot mode, resulting in an invalid run number. However this
+  // did not cause problems until now. OCDB initialization has been revised
+  // already in 10/2009. This was a remnant.
+  // Have to check whether we get rid of the rundescriptor at some point.
+  if (fpRunDesc==NULL) return AliHLTMisc::Instance().GetCDBRunNo();
+  if (fpRunDesc->fRunNo!=(unsigned)AliHLTMisc::Instance().GetCDBRunNo()) {
+    HLTWarning("run number mismatch: ocdb %d   run descriptor %d", AliHLTMisc::Instance().GetCDBRunNo(), fpRunDesc->fRunNo);
+  }
   return fpRunDesc->fRunNo;
 }