The two Database class methods called get_server_info() and put_server_info() have been added to the Database for the couple Astor/Starter. Astor uses the put_server_info() method to add in a specific db table some info
related to a DS process. Starter is using the get_server_info() method to retrieve these info. The underlying database table is updated only by the put_server_info() call. This is what Astor is doing when you select
"Set startup level" for a device server process in a host window. Until this is not done, there is no info in the database table about the DS process. This is why you get a "structure" with the host field set to "".
I agree that the documentation is silent about this and that this is a trap.
In my opinion, it is safer to remove these two methods from the PyTango Database class binding and to modify the documentation.
Hoping this help
Emmanuel Taurel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good point. Actually, it is not really possible using the Database class. The info is there but not transmitted to the client by any call on the Database class!!!
Nevertheless, what you can do, is the following:
- The database server has one classical Tango device. Create a DeviceProxy on this device
- Execute the command "DbImportDevice" on this device. The input parameter is a device name. In your case, it has to be the device server process admin device name (Dserver/DS_exec_name/DS_inst_name)
- In the returned value, the host name is the fifth string
I agree, it is not user friendly. We will change this for Tango 7
Good luck
Emmanuel Taurel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry I am more confused than before. Would it not make more sense in the other direction if Starter calls put_server_info() including the host it is running on when it is actually starting the DS? And astor uses this information to build its tree?
What I want is a kind of "super" starter that can start, stop, kill and restart DS and devices ignorant of the host it is running on, just by specifying the DS/instance or the device name. Maybe I will even integrate that into the tau-devicepanel. (if we find the time...) Without knowing the Starter that is responsible for starting a certain server I can not do that :-(
My wish for upcoming TANGO is, to keep the number of features to the essential minimum and focus more on robustness, binding and documentation. (For example a *complete* doxygenated API reference). Oh and maybe "data-driven" polling (execute polling thread when new data arrives). Anyway I am happy with TANGO as it is.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I assume you mean the Database.get_server_info() because there is no Database.get_host_info().
I believe this bug is in the Tango Database server.
I tryed to execute a command directly in the database device DbGetServerInfo and it returns a DevVarStringArray:
[0]='SimuMotorCtrl/BL99'
[1]=' '
[2]=' '
[3]=' '
Therefore I changed the category to Database server
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ops,
Sorry about my previous comment. I didn't see that there were already many comments posted by lothar and manu.
Nevertheless I believe changing the category was a valid thing to do.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I changed the Assigned To
Hola a todos
The two Database class methods called get_server_info() and put_server_info() have been added to the Database for the couple Astor/Starter. Astor uses the put_server_info() method to add in a specific db table some info
related to a DS process. Starter is using the get_server_info() method to retrieve these info. The underlying database table is updated only by the put_server_info() call. This is what Astor is doing when you select
"Set startup level" for a device server process in a host window. Until this is not done, there is no info in the database table about the DS process. This is why you get a "structure" with the host field set to "".
I agree that the documentation is silent about this and that this is a trap.
In my opinion, it is safer to remove these two methods from the PyTango Database class binding and to modify the documentation.
Hoping this help
Emmanuel Taurel
I want to have commandline script for restarting DSs? How then can I figure out which host a particular server was/is running on?
Hi Lothar,
Good point. Actually, it is not really possible using the Database class. The info is there but not transmitted to the client by any call on the Database class!!!
Nevertheless, what you can do, is the following:
- The database server has one classical Tango device. Create a DeviceProxy on this device
- Execute the command "DbImportDevice" on this device. The input parameter is a device name. In your case, it has to be the device server process admin device name (Dserver/DS_exec_name/DS_inst_name)
- In the returned value, the host name is the fifth string
I agree, it is not user friendly. We will change this for Tango 7
Good luck
Emmanuel Taurel
Sorry I am more confused than before. Would it not make more sense in the other direction if Starter calls put_server_info() including the host it is running on when it is actually starting the DS? And astor uses this information to build its tree?
What I want is a kind of "super" starter that can start, stop, kill and restart DS and devices ignorant of the host it is running on, just by specifying the DS/instance or the device name. Maybe I will even integrate that into the tau-devicepanel. (if we find the time...) Without knowing the Starter that is responsible for starting a certain server I can not do that :-(
My wish for upcoming TANGO is, to keep the number of features to the essential minimum and focus more on robustness, binding and documentation. (For example a *complete* doxygenated API reference). Oh and maybe "data-driven" polling (execute polling thread when new data arrives). Anyway I am happy with TANGO as it is.
I assume you mean the Database.get_server_info() because there is no Database.get_host_info().
I believe this bug is in the Tango Database server.
I tryed to execute a command directly in the database device DbGetServerInfo and it returns a DevVarStringArray:
[0]='SimuMotorCtrl/BL99'
[1]=' '
[2]=' '
[3]=' '
Therefore I changed the category to Database server
Ops,
Sorry about my previous comment. I didn't see that there were already many comments posted by lothar and manu.
Nevertheless I believe changing the category was a valid thing to do.