Incorrect getting of the list of devices from a pattern for Tango::Group if using a remote host.

[elkinvg]

incorrect getting of the list of devices from a pattern for Tango::Group if using a remote host.

Tango 9.2.5
OmniORB 4.2.1
0MQ 4.3.1

For group from localhost

[elkin@tango-linac test_for_group]$ ./test_for_group "sys/tg_test/*"
Getting information from Tango::Group

         Number of devices in pattern: 1

         List of Devices:
                sys/tg_test/1

command_inout for Tango::Group


         Device Name: sys/tg_test/1
         State: 1

For group from remote host.

The correct list of devices from group but without REMOTE_TANGO_HOST.

[elkin@tango-linac test_for_group]$ ./test_for_group "tango://{{REMOTE_TANGO_HOST}}:10000/sys/tangotest/*"
Getting information from Tango::Group

         Number of devices in pattern: 6

         List of Devices:
                sys/TangoTest/1
                sys/TangoTest/2
                sys/tangotest/3
                sys/tangotest/33
                sys/TangoTest/4
                sys/TangoTest/crio

command_inout for Tango::Group

device sys/tangotest/1 not defined in the database !
Failed to execute command_inout on device sys/database/2, command DbImportDevice
Can't connect to device sys/tangotest/1

pattern_from_remote_host.zip

[bourtemb]

Hi,

Groups indeed, when created using patterns, do not seem to support (yet) devices coming from a TANGO_HOST different than the TANGO_HOST of the client. This can be very confusing indeed!

Please be careful when using patterns to define a group because the group will be created with all the devices matching the pattern and which are exported at the moment of the group creation.
If you have a device defined in the database but not exported at the moment of the group creation, this device will not be part of the group. This might be an issue in many use cases.
There is an issue already reported about this: #303

Thank you very much for the bug report and the provided code sample.

[elkinvg]

Thank you for your reply.

Now I usually solve this problem as shown below.

string pattern = "tango://hostname:10000/name/of/device*";

// [0] tango://hostname:10000/}}
// [1] name/of/device*
std::pair<std::string> hostAndDevice = splitDeviceName(pattern);

group = new Tango::Group("name");
group->add(pattern);

std::vector<std::string> deviceList = group->get_device_list(true);

if (deviceList.size() && hostAndDevice.first.size() &&
!splitDeviceName(deviceList[0]).first.size()) {

	group->remove_all();
	for (auto& dev : deviceList) {
		group->add(hostAndDevice.first + dev);
	}

	deviceList = group->get_device_list(true);
	group_size = group->get_size(true);
}

[mliszcz]

Hi @elkinvg, @bourtemb
I cannot reproduce the issue, neither in 9.2.5 nor in 9.3.3. Can you describe your setup? Here is mine:

• 172.18.0.1 machine (VM):
  • DataBaseds from source distribution 9.3.3
  • TangoTest from source distribution 9.3.3
• 172.18.0.71 machine (docker container):
  • (test 1): libtango 9.3.3 from source distribution
  • (test 2): libtango 9.2.5a from debian stretch package

Both commands have the same output (9 devices, all "State" commands executed successfully):

./test_event 'sys/tg_test/*'
./test_event 'tango://172.18.0.1:10000/sys/tg_test/*'

[bourtemb]

@mliszcz , I think the problem occurs when you're trying to access devices from a TANGO_HOST different than the one from the client.
In your case, you have TANGO_HOST=172.18.0.1:10000 on your client side I guess?

You should try with several Tango databases and try to have a group with devices like tango://remotehost:10000/my/dev/name in it, with remotehost being different than 172.18.0.1

Did you try something like that?

[bourtemb]

Please also note that @elkinvg was invoking his test program on different device names (which do not exist in client TANGO_HOST DB but do exist in the remote tango host DB) when doing it with a remote tango host (sys/tangotest/* instead of sys/tg_test/*).

[mliszcz]

Thanks! I've managed to reproduce the issue with the following setup:

• 172.18.0.1:
  • DataBaseds + mariadb server
  • TangoTest
• 172.18.0.72:
  • DataBaseds + mariadb server
• 172.18.0.71:
  • run: TANGO_HOST=172.18.0.72:10000 ./test_event 'tango://172.18.0.1:10000/sys/tg_test/*'

I have one more question: do you have any idea how we can test this on travis? Adding a second database and db device server is not trivial just for this one test and for sure it will confict with #568.

[bourtemb]

I have one more question: do you have any idea how we can test this on travis? Adding a second database and db device server is not trivial just for this one test and for sure it will confict with #568.

Would it be possible to run a second database server on Travis, specifying another port number (20000 instead of 10000 for instance)? I guess this should be enough to reproduce this issue.
We might need to adapt the tango-db docker container to be able to specify the port number used by the Tango database server?

[mliszcz]

I can add a second mysql container and a second tango_cs container to the before_script section in .travis.yml. I think the default port will be ok, the servers will be on different machines with different IPs.

I'll then pass an extra env variable TANGO_HOST_2 to the cpp_tango container. The testcase will have to replace it's TANGO_HOST env var with TANGO_HOST_2 before creating the group. The group will contain DevTest from original TANGO_HOST.

Additionally, these files need to be changed in a similar way to allow for local runs.

• cpp_test_suite/environment/setup.sh
• cpp_test_suite/environment/shutdown.sh