Could not find the StreamerInfo for version 3 of the class TH2F

O² O² FLP
1

Trying to read in JS some objects from the test CCDB, using :

node test.js

where test.js is :

const { TObject2JsonClient } = require("@aliceo2/qc");
const client = new TObject2JsonClient("ccdb", {
  hostname: "ccdb-test.cern.ch",
  port: 8080
});
const test1 = "QcTaskMCH/QcMuonChambers_Pedestals_DS39/1564581527418";
const test2 = "QcTaskMCH/QcMuonChambers_Noise_00/1566827328236";
client.retrieve(test2).then(data => {
  console.log(JSON.stringify(data));
});

it works for test1 (which is a TH1F) but for test2 (a TH2F) I get :

Error in TMessage::ReadClassBuffer: Could not find the StreamerInfo for version 3 of the class TH2F, object skipped at offset 92
Error in TMessage::CheckByteCount: object of class TH2F read too few bytes: 2 instead of 11705

Any idea why ?

2

Did you write these 2 objects in the same way? I am just shooting in the dark here but could it be that one of them was serialized as a TMessage and and the other as a TMemFile? I think TMemFile will be the preferred default but currently in the CcdbApi the TMessage solution still exists.

3

@aferrero any idea whether the two objects were written differently ?
@swenzel even if the two objects were written differently, why should it matter in the end ? I mean, in the CCDB the objects should be the same whatever the writing method, shouldn’t it ?

4

But there are 2 APIs for retrieval: “retrieve” and “retrieveFromFile” and they work slightly differently. In the end this will be harmonized and only one will survive. In any case, I am not sure this is the problem but it could be.

5

Both of them seem to be a plain TMessage. (Potentially the problem may go away once we move to TFiles as the binary storage since the streamers will be saved inside.)

6

Yes, this is the motivation to use TFile instead of simply using TMessage to serialize. The StreamerInfos are lost at the moment because we use TMessage.
The new storage methods are available and will be enabled imminently as ROOT 6.18.02 is being built and tested.

This problem should therefore not happen again and I would advise not to spend too much time trying to understand and fix this specific problem.

7

ok, but there must be something fishy on my side, as the qcg (e.g. qcg-test.cern.ch) is able to access both objects w/o any issue (and with the same JS API as far in principle)…

8

@bvonhall our messages crossed… ok, will wait for the new storage methods then.

9

Indeed, messages crossed. I agree that there is something fishy if the qcg manages to open both.

10

Not to my knowledge… they are both created by publishing them via the object manager.