1. TANGO Events “To be or not to be ?” Architecture Implementation Demonstration (?) Open questions

2. TANGO Events – do they exist ? YES ! First implementation available on SourceForge : – cppapi Release_3_0_0_events-branch Implemented for : – device servers in C++ – device clients in C++

3. TANGO Events – architecture mysql client 1 client 2 client 3 database server 2 notifd server 1 devices channel event(s) IOR factory host event(s) command_inout

4. TANGO Events – threads polling thread 1.poll attributes 2.push events 3.heartbeat device server push thread 1.activate POA 2.wait for events keep-alive thread 1.check heartbeat 2.send heartbeat client 10 minutes 10 seconds

5. TANGO Events - implementation Downloaded and compiled omniNotify alpha 2 version in omniORB/src/services 2 singleton classes : – EventSupplier (server side) – EventConsumer (client side) Notification daemon modified to export to TANGO database Database modified : – added Event table – added commands to export + import events Thanks to polling thread the integration into TANGO was very easy !

6. TANGO Events – database Event table – Name : varchar(255) – Exported : int(11) – Ior : text – Host : varchar(255) – Server : varchar(255) – Pid : int(11) – Version : varchar(8) – Started : datetime – Stopped : datetime

7. TANGO Events - API Client side : – DeviceProxy->subscribe_event(string attribute, string event, EventCallback*) – EventCallback (EventData *) DeviceProxy* string attribute string event string event_type int delta_change int delta_time DeviceAttribute bool err DevErrorList &errors Server side – simply recompile and link with Notification libraries !

8. TANGO Events – events Events are sent as Attributes on_change – event sent if delta_change > 10% of last event sent on_alarm – event sent if attribute goes into alarm periodic – event sent every polling period

9. TANGO Events – filters Notification Service supports filters on events Currently all clients automatically filter for the event of their choice In the future clients can specify filters on any of the filterable fields : – delta_change – delta_time

10. TANGO Events – heartbeat Aim – Detect server or notification daemon crashes – Only send events if there are subscribers Server side : – Server sends a heartbeat to its channel every 10 seconds – Client detects this heartbeat and uses it to determine whether server is alive Client side : – Client resubscribes to all of its events every 10 minutes – Server uses this to decide whether to keep on sending events

11. TANGO Events - Platforms Linux – main development platform Solaris – next platform to port to Windows – after Solaris – ordered notifd port from Duncan Grisby

12. TANGO Events - Java Needs client side idl files to be compiled Needs event.cpp to be ported to Java Need to modify ATK Q : who and when ?

13. TANGO Events – push and pull push-push – Server pushes events to notification daemon – Notification daemon pushes events to client – Quickest way of getting events to clients – Current model push-pull – Server pushes events to notification daemon – Notification daemon queues events – Client polls/pulls events from notification daemon – DeviceProxy->try_pull_events()

14. TANGO Events – TODO Implement : – reconnect policy in EventConsumer – state as an attribute Port : – Solaris – Windows Test : – Write test programs – TEST, TEST and TEST again !

15. TANGO Events - open questions ? Delta on change (default = 10%) Q : should this be an attribute property ? Polling frequency – same as for cache device (default = 1 second) Q : should this be an attribute property ? Heartbeats – Server = 10 seconds, Client = 10 minutes Q: should this be a property ? Only attributes as events Q : should it be possible to send other types of events ?

16. TANGO Events - Conclusion First version of TANGO events is available in C++ omniNotify looks good (so far) Easy to integrate in TANGO thanks to ET Need to answer open questions Ready to be ported to Java