missing DServer in ArchivingRoot (HDB, Snap and TDP)

# 8 years ago
Philippe	Hi tangoers, I recently encountered some problems while using Archiving system. It seems to be the reason why we had problems with panorama binding (http://www.tango-controls.org/community/forums/c/general/installation/installation-of-panorama-binding/). Investigating the example given in [ARCHIVINGROOT_DIRECTORY]/doc/sample-hdb-device-installation.sql, I realized some of the HDB and TDB DS are installed without any "DServer". It implies at least HdbExtractor, TdbExtractor and HDBTDBArchivingWatcher. At page 101 of TANGO 9.2 control system handbook (http://ftp.esrf.fr/pub/cs/tango/tango_92.pdf , already referenced at page 219 of TANGO 8.1 handbook), we can read : 8.1.7.2 The DServer class In order to simplify device server process administration, a device of the DServer class is automatically added to each device server process. Thus, every device server process supports the same set of adminis- tration commands. The implementation of this DServer class follows the device pattern and therefore, its device behaves like any other devices. The device name is dserver/device server executable name/device server instance name For instance, for the device server process described in chapter 6.1.7.1, the dserver device name is dserver/perk- in/id11. This name is returned by the adm_name CORBA attribute available for every device. The installation of this device DServer seems automatic, it probably does not come from $ARCHIVINGROOT/doc/sample-hdb-device-installation.sql Do you have any idea where is the problem ? - Philippe Edited 8 years ago

# 8 years ago

Hi tangoers,
I recently encountered some problems while using Archiving system.
It seems to be the reason why we had problems with panorama binding (http://www.tango-controls.org/community/forums/c/general/installation/installation-of-panorama-binding/).

Investigating the example given in [ARCHIVINGROOT_DIRECTORY]/doc/sample-hdb-device-installation.sql, I realized some of the HDB and TDB DS are installed without any "DServer".
It implies at least HdbExtractor, TdbExtractor and HDBTDBArchivingWatcher.

At page 101 of TANGO 9.2 control system handbook (http://ftp.esrf.fr/pub/cs/tango/tango_92.pdf , already referenced at page 219 of TANGO 8.1 handbook), we can read :

8.1.7.2 The DServer class

In order to simplify device server process administration, a device of the DServer class is automatically added to each device server process. Thus, every device server process supports the same set of adminis- tration commands. The implementation of this DServer class follows the device pattern and therefore, its device behaves like any other devices. The device name is

dserver/device server executable name/device server instance name

For instance, for the device server process described in chapter 6.1.7.1, the dserver device name is dserver/perk- in/id11. This name is returned by the adm_name CORBA attribute available for every device.

The installation of this device DServer seems automatic, it probably does not come from $ARCHIVINGROOT/doc/sample-hdb-device-installation.sql

Do you have any idea where is the problem ?

- Philippe

Edited 8 years ago

# 8 years ago
Andy	Hi Philippe, I am not an expert in the HDB archiving system but I wonder if this behaviour (no DServer admin device) is not due to the fact that the HDB device servers are written with Java and are using an old version of the Java binding. In this case it has always been like this and is maybe not a problem… I let the HDB experts answer. Andy

# 8 years ago
Philippe	Thank you Andy. It seems that the fact that DServer is missing makes TANGO launch an exception. I wait for the answer of experts to understand how we could avoid this exception to crash other applications. - Philippe

# 8 years ago
girardot	Hello The archiving devices are indeed written in java, but they do not all use the old IDL (for example, HDBTDBArchivingWatcher uses the new idl). That being said, I think the problem comes from somewhere else : A user already told me (but I did not take time to correct this) that the sample-hdb-device-installation.sql creates the device instances in tango db but not the device classes. For that reason, this script may not work. So you might need to register the device classes in tango db before running the script. But if this is not the problem, you also have to check the devices and device classes properties. For example, HdbArchiver class should contain the properties to describe how to connect to your historical database. You should take a look at [ARCHIVINGROOT_DIRECTORY]/doc/Archiving Devices Properties_v4.pdf Don't hesitate to contact me in case of problems. Regards, Rg Edited 8 years ago

# 8 years ago

girardot

Hello

The archiving devices are indeed written in java, but they do not all use the old IDL (for example, HDBTDBArchivingWatcher uses the new idl).

That being said, I think the problem comes from somewhere else :
A user already told me (but I did not take time to correct this) that the sample-hdb-device-installation.sql creates the device instances in tango db but not the device classes. For that reason, this script may not work.

So you might need to register the device classes in tango db before running the script.

But if this is not the problem, you also have to check the devices and device classes properties.
For example, HdbArchiver class should contain the properties to describe how to connect to your historical database.

You should take a look at [ARCHIVINGROOT_DIRECTORY]/doc/Archiving Devices Properties_v4.pdf

Don't hesitate to contact me in case of problems.

Regards,

Edited 8 years ago

# 4 years ago
philippeg	Hi @girardot, I read the doc, thank you for including it, it's very useful and details about properties are very helpful.:) It seems the sample-hdb-device-installation.sql is made for Oracle Database and the properties should be fixed for a MySQL database. According to the doc, I modified the script to only define following class properties for MySQL: INSERT INTO property_class (class, name, count, value, updated, accessed, comment) VALUES ('HdbArchiver','Description','1','Device description',NULL,NULL,NULL), ('HdbArchiver','ProjectTitle','1','Project description',NULL,NULL,NULL), ('HdbArchiver','DbHost','1','localhost',NULL,NULL,NULL), ('HdbArchiver','DbName','1','hdb',NULL,NULL,NULL), ('HdbArchiver','DbSchema','1','hdb',NULL,NULL,NULL), ('HdbArchiver','Facility','1','false',NULL,NULL,NULL), ('HdbArchiver','DbUser','1','hdb',NULL,NULL,NULL), ('HdbArchiver','DbPassword','1','hdb',NULL,NULL,NULL), ('HdbArchiver','DbType','1','MySQL',NULL,NULL,NULL), ('HdbExtractor','Description','1','Device description',NULL,NULL,NULL), ('HdbExtractor','ProjectTitle','1','Project description',NULL,NULL,NULL); Some properties are defined into device properties instead of class properties into the sample script. Is it an error or could those properties be defined into both? In this last case, what is the good way to define those properties? I see that scripts exists for both InnoDB and MyISAM. Do you confirm the good practice is to use InnoDB? (this format is the one used by default in MySQL since a few years) The result script (with only one device for each DS) is attached. Could you confirm me these scripts are correct? Regards. - Philippe Edited 4 years ago Attachments: 6Kb 5Kb

# 4 years ago

philippeg

Hi @girardot,
I read the doc, thank you for including it, it's very useful and details about properties are very helpful.:)

It seems the sample-hdb-device-installation.sql is made for Oracle Database and the properties should be fixed for a MySQL database.
According to the doc, I modified the script to only define following class properties for MySQL:

INSERT INTO property_class (class, name, count, value, updated, accessed, comment) VALUES
	('HdbArchiver','Description','1','Device description',NULL,NULL,NULL),
	('HdbArchiver','ProjectTitle','1','Project description',NULL,NULL,NULL),
	('HdbArchiver','DbHost','1','localhost',NULL,NULL,NULL),
	('HdbArchiver','DbName','1','hdb',NULL,NULL,NULL),
	('HdbArchiver','DbSchema','1','hdb',NULL,NULL,NULL),
	('HdbArchiver','Facility','1','false',NULL,NULL,NULL),
	('HdbArchiver','DbUser','1','hdb',NULL,NULL,NULL),
	('HdbArchiver','DbPassword','1','hdb',NULL,NULL,NULL),
	('HdbArchiver','DbType','1','MySQL',NULL,NULL,NULL),

	('HdbExtractor','Description','1','Device description',NULL,NULL,NULL),
	('HdbExtractor','ProjectTitle','1','Project description',NULL,NULL,NULL);

Some properties are defined into device properties instead of class properties into the sample script.
Is it an error or could those properties be defined into both?
In this last case, what is the good way to define those properties?

I see that scripts exists for both InnoDB and MyISAM.
Do you confirm the good practice is to use InnoDB? (this format is the one used by default in MySQL since a few years)

The result script (with only one device for each DS) is attached. Could you confirm me these scripts are correct?

Regards.

- Philippe

Edited 4 years ago

# 4 years ago
philippeg	After some investigations and thanks to some insights from Gwenaëlle, I found some answers I put downside for information: philippeg I see that scripts exists for both InnoDB and MyISAM. Do you confirm the good practice is to use InnoDB? (this format is the one used by default in MySQL since a few years) The InnoDB scripts crashed so I did not succeed to test it at this time. philippeg The result script (with only one device for each DS) is attached. Could you confirm me these scripts are correct? There is an error in "doc/Archiving Devices Properties_v4.pdf" concerning the DbUser and DbPassword for Archivers which are defined to hdb/hdb and tdb/tdb instead of hdbarchiver/hdbarchiver and tdbarchiver/tdbarchiver. - Philippe

# 4 years ago

philippeg

After some investigations and thanks to some insights from Gwenaëlle, I found some answers I put downside for information:

philippeg
I see that scripts exists for both InnoDB and MyISAM.
Do you confirm the good practice is to use InnoDB? (this format is the one used by default in MySQL since a few years)

The InnoDB scripts crashed so I did not succeed to test it at this time.

philippeg
The result script (with only one device for each DS) is attached. Could you confirm me these scripts are correct?

There is an error in "doc/Archiving Devices Properties_v4.pdf" concerning the DbUser and DbPassword for Archivers which are defined to hdb/hdb and tdb/tdb instead of hdbarchiver/hdbarchiver and tdbarchiver/tdbarchiver.

- Philippe

# 4 years ago
philippeg	After some tests, here are some fixes to make ArchivingRoot work with MariaDB: if you use InnoDB format (my suggestion), in db/create-HDB-InnoDB.sql and db/create-TDB-InnoDB.sql: replace "varchar(200)" by "varchar(191)" (it's due to use of format utf8mb4 for UTF8, which take 4 bytes instead of 3) if you use MyISAM format, in db/create-SNAPDB-MyISAM.sql : replace "timestamp(14)" by "timestamp" (due to a change of timestamp behavior, see https://answers.launchpad.net/maria/+question/237396). if you want to use distantly the GUI tools (mambo, bensikin, etc.), you have to install ArchivingRoot on each client and define HdbArchiver and TdbArchiver Class property DbHost to the name of the ArchivingRoot server - Philippe Edited 4 years ago

# 4 years ago

philippeg

After some tests, here are some fixes to make ArchivingRoot work with MariaDB:

if you use InnoDB format (my suggestion), in db/create-HDB-InnoDB.sql and db/create-TDB-InnoDB.sql: replace "varchar(200)" by "varchar(191)" (it's due to use of format utf8mb4 for UTF8, which take 4 bytes instead of 3)
if you use MyISAM format, in db/create-SNAPDB-MyISAM.sql : replace "timestamp(14)" by "timestamp" (due to a change of timestamp behavior, see https://answers.launchpad.net/maria/+question/237396).
if you want to use distantly the GUI tools (mambo, bensikin, etc.), you have to install ArchivingRoot on each client and define HdbArchiver and TdbArchiver Class property DbHost to the name of the ArchivingRoot server

- Philippe

Edited 4 years ago