confusion in history event id's

[dd1]

there is confusion in history event id’s when using “mfe -i index”. See

https://midas.triumf.ca/elog/Midas/1699

K.O.

[dd1]

i see a problem. I have /eq/slow and /eq/slow01, both with event id set to 2. I see mlogger defining history event id “2” for both. This is not right: their data from the two frontends will be written to the .hst files using the same id “2” and it will be mixed up. Different history event ID’s should have been assigned via /history/events. Hmm…

P.S. The MySQL and “FILE” history do not use numeric event id, only the “MIDAS” history is affected by this problem.

K.O.

[dd1]

Added logger message: [Logger,ERROR] [history.cxx:2466:add_event,ERROR] History events "slow01" and "Slow" use the same history event id 2. If both equipments write to the history, their data will be mixed up. To fix this, enable per-variable history, turn off the "MIDAS" history (use "FILE" history) or change event IDs or set "common/log history" to zero

K.O.

[dd1]

The error is in “AllocateEventId()”, it will take the history event id from “equipment/common/event id” and write it to /history/events without checking if this event id was already allocated to somebody else.

Normally all equipments are assigned different event id’s so this should not happen, but “indexed” frontends (mfe.c “-i” command line switch) create multiple frontends that all share the same event id. If they do write history, it will become mixed up. For example: frontend “slow” with event id 2, recorded as /history/events/2 → “slow”. start “fetest -i 1”, creates “slow01” with same event id, recorded as /history/events/2 → “slow01”, overwriting the record for “slow”. After this, I do not know who is the real McCoy and which equipment should use history event “2” and which one should get the next sequentially allocated id.

One fix is to use per-variable history. In this case, history event names are “slow/varname” and “slow01/varname” assigned sequentially allocated history event ids (common/event id is not used) and there is no collision.

Original problem is reported from the T2K/ND280 experiment where exactly this problem happens - multiple slow control frontends started with “-i”, all of them writing history - but because they use the MySQL (ODBC) history in per-variable history mode, no collisions happened and this problem remained hidden.

K.O.

‌

[dd1]

tmfe c++ frontend does not implement “indexed” equipments, this problem does not exist there. K.O.

[dd1]

Added a warning, commit ea5ce6e. K.O.