Hi @shahor02 , I have question on the code.
In o2-ctp proxy I want to create class instance which will be in memory as long as o2-ctpproxy is running.
I am not sure in which part of code to do it.
Fore more details see below.
Cheers, Roman.
In o2-ctpproxy I create ctp config and send it to database:
https://github.com/lietava/AliceO2/blob/ctpdev/Detectors/CTP/workflowScalers/src/ctp-proxy.cxx#:~:text=if%20((messageHeader.find,%7D%20else%20%7B
But now I'd like to replace it with so call CTP run manager:
https://github.com/lietava/AliceO2/blob/ctpdev/DataFormats/Detectors/CTP/include/DataFormatsCTP/Configuration.h#:~:text=class%20CTPRunManager,%7D%3B
which will be managing active runs - configs and counters.

@lietava you can do the same as for the https://github.com/lietava/AliceO2/blob/d0d478643e48c6c313c4143bbed9357058932a76/Detectors/CTP/workflowScalers/src/ctp-proxy.cxx#L50
Create a shared ptr on the RunManager and capture it in the lambda:

auto runMgr = std::make_shared<o2::ctp::CTPRunManager>();

return [timesliceId, runMgr](TimingInfo&, FairMQDevice& device, FairMQParts& parts, ChannelRetriever channelRetriever) {
   ...
   runMgr->do_what_you_want();
   ...
}

BTW, you should not populate production CCDB with the objects of infinite coverage, https://github.com/lietava/AliceO2/blob/d0d478643e48c6c313c4143bbed9357058932a76/Detectors/CTP/workflowScalers/src/ctp-proxy.cxx#L67-L68, could you set the tmin/tmax to smallest reasonable range?

Hi @shahor02 , thanks for code.
For tmin/tmax - what is smallest reasonable range: for tests I am doing now I do not care, I can put there couple of days.
For real data:
startValidityTimestamp would be the time of storing in database,
endValidtyTimestamp would be infinity.
Do you agree ?

@lietava is this config created per run? If so, there is no point in having > 106h validity (max orbit reset period).
It is preferable to have infinite endValidtyTimestamp only for default objects (not sure if it applies here), otherwise we should minimize the overlap between new and old objects.

@shahor02: yes, config is per run as well as counters. I have not understood concept ValidityTimestamp,
Now I think I understand. I can store it to database at the end of run with correct validity ? Or at the beginning with 106 hours ?
Or can validity be changed ?

HI @shahor02, I have technical problem. I got segmentation violation when trying to push to std::vector. I played with it a lot but I am stuck. Either I am overlooking something simple or there is something which I do not know about c++.
I committed code here. When I run CreateCTPConfig.C macro I got :
ctpconfigerror.txt
Can you, please, have a look ?
Thanks, Roman.

Hi @lietava
I suspect you have a memory corruption somewhere before, but 1st of all, you have non-initialized variables in the CTPClass (though this should not create the immediate problem you see).
Why do you need at all these copy constructor (and assignment operator), are not they shallow in any case (then better to rely on default ones).
If after fixing all non-initialized variables you still get problem, could you run
valgrind root.exe -b -q CreateCTPConfig.C+ >& vlg.log
and send the log?

HI @shahor02 , copy constructor/=operator I introduced when I have started to have problems. I removed them now. I initilise CTPClass variables now.
I reduced the code even more. Macro only creates instance of CTPConfiguration and calls
CTPConfiguration::loadConfigurationRum3 , which only instantiate CTPclass and pushes it to mCTPClasses vector.
Please, find attached valgrind output.
vlg.log
Thanks, R.

@lietava but the log you've attached does not show any crash: I see the message Going write to db your macro prints just before return.

Hmm, just run now:
[O2/latest-ctpdev-o2] ~/alice/O2 $> cd Detectors/CTP/macro/
[O2/latest-ctpdev-o2] ~/alice/O2/Detectors/CTP/macro $> root -l CreateCTPConfig.C
root [0]
Processing CreateCTPConfig.C...

*** Break *** segmentation violation

===========================================================
There was a crash.
Attaching file

ctpclass_crash.txt

can you run it compiled, i.e. root -l CreateCTPConfig.C+.
If it crashes only in the interpreted mode, it is worth running valgrind --track-origins=yes root.exe -b -q CreateCTPConfig.C >& vlg.log

compiled it does not crash. Ok, I am running new valgrind.

if the problem persists only with interpreted macro, could you try to move the line

if I remove line outside of if:
#if !defined(CLING) || defined(ROOTCLING)
#include "FairLogger.h"
#include "CCDB/CcdbApi.h"
#include "CCDB/BasicCCDBManager.h"
#include
#include
#include
#endif
#include "DataFormatsCTP/Configuration.h"
I got a lot of errors.

Here is uncompiled valgrind:
vlg2.log

ok, will need to fetch and build your branch, but can do this only tomorrow.

ok, will need to fetch and build your branch, but can do this only tomorrow.

Thanks.

Hi @lietava
I've built your branch as it is, and for me it works:

root -b -q ~/alice/O2/Detectors/CTP/macro/CreateCTPConfig.C
...
Processing /home/shahoian/alice/O2/Detectors/CTP/macro/CreateCTPConfig.C...
[INFO] Loading CTP configuration.
Configuration:
 Version:0
CTP BC  masks:
CTP inputs:
CTP descriptors:
CTP detectors:0
CTP clusters:
CTP classes:
CTP Class:test Hardware mask:0
Going write to db

HI @shahor02 , thanks a lot. I give up and start from last AliceO2Group/dev commit.
All issue started as at some point I thought that there is problem with creating std::vectors of CTP Config c++ classes.
But from the above discussion: is it correct that I do not need to provide copy constructor/= operator ? Or actually it is better to not provide them ?

@lietava I guess you have a problem with your local build, perhaps it is worth to wipe out alice/sw and rebuild from scratch.
For the copy constructors and operator=: if all you do is a shallow copy (just assigning data members from the source to dest.) then better to not define them at all, they will be generated automatically.

@shahor02 I already pushed force from AliceO2. Are these commits in my repo lost ?

Yes. But I have your branch version which I was testing, from April 26 In case you need it: https://github.com/shahor02/AliceO2/tree/ctpdev_Apr26

Thanks, Ruben.

@shahor02 if I want to enter two different entities in ccdb - counters and config - how I distinguish them ?

@shahor02 if I want to enter two different entities in ccdb - counters and config - how I distinguish them ?

Not sure understood the question, are you asking how to have 2 separate objects?

yes, I have two separate objects.

database recognize them using root dictionary ?

No, CCDB knows nothing about the content of the objects.
When getting object from CCDB, you always use templated method get<your_class>(path).
The exception is the finaliseCCDB method used for the DPL CCDB fetcher, where a void pointer is provided, there one should simply cast to the needed class.