set_change_event() with nodb option - detect not working

Hi,

The manual says

set_change_event(bool implemented, bool detect = true);

where implemented=true indicates that events are pushed manually from the code and detect=true (when used) triggers the verification of the same event properties as for events send by the polling thread. When setting detect=false, no value checking is done on the pushed value


A. Test procedure
- Setting set_change_event(true, true);
- Calling push_change_event() with same value several times.

B. Result
1. Test with database option
- from the second calls, events are ignored

2. Test with no database option
- every calls arrived to the client, with the same values


I'm curious whether this is as designed.
Or am I testing the wrong way?

I'm using Tango v9.2.2 with Windows.

Hi,

I just tried it on Linux with Tango 9.2.2, it works as expected with the no database option (same result as your case #1).

So it could be a bug present only on Windows, or something else in your tests…
Or a bug present in a case different than the one I just tested (DevDouble ReadOnly attribute).
What did you put as Absolute Change and/or Relative Change criteria in the code?
Did you configure these criteria in the database as well in your case #1?
What is the type of your attribute? Is it Read/Only or Read/Write?
Are you testing with the exact same device server code in both cases?

Can you publish a sample of code which triggers the problem in your case?

Kind regards
Reynald
Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.
Additional question:

Are you using localhost in your device definition?
For instance: localhost:1234/my/device/name/my_attribute#dbase=no

I've just noticed this does not seem to behave well, on Linux at least.
And the client receives some "Event channel is not responding anymore" errors.
You will typically receive this error every 10 seconds. It will be followed by a reconnection attempt, which does a synchronous call to read your attribute.

This might be what you are observing?

If this is the case, can you try using the real name of your machine instead of localhost?

Kind regards
Reynald
Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.
Reynald

What did you put as Absolute Change and/or Relative Change criteria in the code?

The attributes are generated dynamically and the change value as well using below code


try
{
	a = new DynamicFINSAttribute(cfg);
	a->set_disp_level(Tango::OPERATOR);

	Tango::UserDefaultAttrProp event_prop;
	event_prop.set_event_abs_change("1");

	//- set other attribute properties : label, display format,…
	a->set_default_properties(event_prop);
	a->set_change_event(true, true);

	this->m_dyn_attrs.add(a); 

	return;
}
catch (std::bad_alloc)
{
	ERROR_STREAM << "TOmronServer::add_dynamic_attribute caught bad_alloc" << std::endl;
}
catch (Tango::DevFailed &e)
{
	ERROR_STREAM << "TOmronServer::add_dynamic_attribute caught DevFailed " << e << std::endl;
}
catch (…)
{
	ERROR_STREAM << "TOmronServer::add_dynamic_attribute caught (…)" << std::endl;
}


Did you configure these criteria in the database as well in your case #1?

The database does not contain any static attributes.

What is the type of your attribute? Is it Read/Only or Read/Write?

Read/Only

Are you testing with the exact same device server code in both cases?

Yes

Can you publish a sample of code which triggers the problem in your case?

I will.

Are you using localhost in your device definition?

Yes.

This might be what you are observing?

Nop.



My additional question is whether the push_change_event() call is thread-safe?
Now it is called by several threads derived from omni_thread simultaneously.

There is another issue.

Debuging mode, when client calls subscribe_event() to non-database server.
Then the server stopped immediately.

Refer to attached "server-side.png" at the server side, "client-side.png" at the client side.
Also "crash_point.png", the line when client causes this problem.

Relase mode, it seems OK.

This happens regardless whether I use computer_name or IP at TANGO_HOST environment.

So, I'm having hard time to publish sample code of my initial issue.smile
Hi,

It looks like you are trying to subscribe to attributes using wildcards, this is why you get this error on the client side:

Desc: * attribute not found
Origin: MultiAttribute::get_attr_ind_by_name

Remember that we said this is not supported? smile
You should subscribe to each attribute individually.

push_change_event() should be thread-safe.

Hoping this helps,
Reynald
Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.
Reynald,

Sorry I posted the wrong picture. (client side)

It says
.Tango exception
Severity = ERROR
Error reason = API_CorbaException
Desc : UNKNOWN CORBA system exception
Origin : Connection::command_inout()

Tango exception
Severity = ERROR
Error reason = API_CommunicationFailed
Desc : Failed to execute command_inout on device dserver/tomronserver/area1, command ZmqEventSubscriptionChange
Origin : Connection::command_inout()

Tango exception
Severity = ERROR
Error reason = API_DSFailedRegisteringEvent
Desc : Device server send exception while trying to register event
Origin : EventConsumer::connect_event()

Re-posted with new picture.
Edited 7 years ago
Thank you, this fits with the fact that the device server stops.

What would be interesting for us is to know the code executed when you read the attribute named E000095.
It would actually be interesting to know if it happens always on the same attribute.
Is your client trying to subscribe to thousands of attributes? This kind of information could be very useful too.
How many threads do you have, how many attributes in the server, how many commands…

We need to find out what could cause this invalid argument exception on the server side.
This seems to happen when a command is executed.
Are there any commands defined for this server?
Is the server throwing not-CORBA (not-TANGO) exceptions in these commands?
Is there a client executing commands?
Or could it be that when you read the E000095 attribute, this is executing a command?

It is still not clear to me why it would happen only in debug mode…
One of the differences I'm thinking of is that in debug mode, the server will be slower.

I hope this can help you a bit to debug this issue…

Kind regards
Reynald
Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.
Reynald,

Let me get back to the initial issue (regarding the detect not working issue).

I found something strange.

1. TANGO-HOST => 127.0.0.1:10000
Then the detect option not working.
Events keep generated with same values.
(repeated about 10 secs interval)

2. TANGO_HOST => mycomputername:10000
3. TANGO_HOST => localhost:10000
Both case, the detect option working.
Events with initially shown, then no more.

But the 2.3 case, subscribe_event() call is really sloowwwsmile
(about 5 secs per each call).

Hope this clears something.
OK, so what you are observing in case 1 is a problem with the events heartbeat.

As far as I know, the event subscription mechanism works as follows:
During the subscription, a synchronous call to read the value of the attribute the client just subscribed to is executed.
This generates the first event and is used to know the value of the attribute at the time of the subscription.
A thread called the KeepAliveThread will check periodically whether the remote device server is still alive and is expecting to receive some heartbeat events regularly.
If no heartbeat event has been received in the last 10 seconds, an event containing an API_EventTimeout error (flag err is true in the EventData structure) is generated on the client side.
Then, the client automatically retries to subscribe to the event in question, so in case of success, a synchronous call to read the value of the attribute is sent again and an event is generated on the client side.
This is what you are probably observing in case #1.

Please ensure to have the same TANGO_HOST variable definition on client and server side.
This is what was recommended by Andy in a previous post (http://www.tango-controls.org/community/forum/c/general/development/no-heartbeat-error-on-event-subscription/?page=4#post-654) for someone having similar issues.
Try to avoid mixing because there are so many cases to be handled, that there are some cases which are not yet handled correctly as you can see.

About the long time during the subscription, it could be due to the synchronous call happening at subscription time (if it takes quite some time to read the attribute value or if the server is busy answering many requests in parallel (waiting for a synchronization lock)) or a network issue (or …?).

Best regards,
Reynald
Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.
 
Register or login to create to post a reply.