Information
We are currently investigating an issue with the editor of some pages. Please save your work and avoid to create new pages until this banner is gone.
...
What follows is a trivial consumer that processes one event and then disconnects from the channel.
ACS/LGPL/CommonSoftware/jcontexmpl/src/alma/demo/EventConsumerImpl/EventConsumerImpl.java:
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
import alma.acs.nc.Consumer; |
...
//… |
...
private Consumer m_consumer = null; |
...
//… |
...
public void receive(alma.FRIDGE.temperatureDataBlockEvent joe) |
...
{ |
...
System.out.println("The temp difference is:" + joe.absoluteDiff); |
...
} |
...
//… |
...
m_consumer = new Consumer(alma.FRIDGE.CHANNELNAME_FRIDGE.value, m_containerServices); |
...
m_consumer.addSubscription(alma.FRIDGE.temperatureDataBlockEvent.class, this); |
...
m_consumer.consumerReady(); |
...
m_consumer.disconnect(); |
1 | The location of the Consumer class in Java. |
5-8 | We define a "receive" method designed to process the particular type of event we are interested in. Please note that it must be named "receive" and it does not matter which class this method is implemented in. In this example, it was defined in the component implementation to keep things simple. |
10-11 | The constructor must subscribe to a specific channel providing a reference to a ContainerServices object (line 10) and then add a subscription for a specific type of event (line 11). On line 11, the 2nd parameter to addSubscription must be an object implementing receive(temperatureDataBlockEvent someEvent). |
12 | consumerReady must be invoked to start receiving events. |
13 | Failure to disconnect from the channel causes remote memory leaks! |
...
...
The following describes a set of Supplier and Consumer subclasses contributed by the Scheduling subsystem designed primarily for simulating CORBA Notification Channels entirely within Java virtual machines.
...
alma.acs.nc
...
...
Publisher is equivalent to Supplier.
Receiver is equivalent to Consumer.
...
...
...
The concept of a local notification channel has been previously mentioned. The LocalNotificationChannel class implements all the methods required to publish and receive events. In fact, after being created, application code that publishes or receives events see no difference between the two. The restriction is that the LocalNotificationChannel usage is restricted to channels, publishers and receivers that exist within the same Java virtual machine. Of course, the LocalNotificationChannel does not use CORBA, which is the whole point.
NOTE: For the local notification channel your application has to be running on one JVM. Otherwise channels will not find each other!
...
...
Yes! The examples below have been tested with Python and C++ suppliers. Likewise, FridgePublisher has been tested with a python consumer and a C++ consumer.
...
...
...
...
...
...
...
...
...
...
When using the ACS Notification Channel framework, there is nothing special required from the developer aside from issuing the usual ACS startup command(s) which in turn start the CORBA services. However, for those wishing to modify the Quality of Service and Administrative properties for a channel, they can do the following:
...
Quite often it seems to be the case that there is confusion about whether events have been received or even sent for that matter. In as such, the EventChannel.xsd schema now provides an extra attribute, IntegrationLogs, having nothing to do with properties of the channel. When this Boolean value is set to true, a log is sent out each time an event is published or consumed. Be careful though as logs are also events and using this mechanism instantly doubles the overhead being placed on the CORBA Notification Service. It is likely that this debugging functionality will be removed to improve performance someday but for the time being it should prove to be an invaluable too.
...
...
Overloading the CORBA notification service with enormous amounts of events and consumer objects that take too long processing the events can cause serious performance issues or even the corruption of the notification service process itself. To help deal with this, ACS has introduced a new optional sequence of XML elements, Events:, within the main _EventChannel element of EventChannel.xsd. By setting the "MaxProcessTime" attribute of this new element, one can make the ACS NC API(s) emit warning messages whenever an event handler method or function takes too long processing an event. Even if you choose not to use the CDB to set this, by default these messages are sent if the handler takes more than two seconds to process an event.
As an all too brief example, let's say you are the developer sending the events and know the frequency of a particular type of event, IDL:/alma/FRIDGE/FridgeTemperatureDataBlockEvent:1.0, will be shorter than the two second maximum ACS automatically sets. Assume this frequency is once per second. It should then be obvious that any consumers receiving these events need to process them within one second or risk having the event being added to a queue somewhere thereby eventually eating up all available memory. What you can do to be made aware of this problem at run-time is to add the following XML element to the XML described in the section 15.1:
Code Block | ||
---|---|---|
| ||
<Events> |
...
<_ Name="FridgeTemperatureDataBlockEvent" MaxProcessTime="1.0"/> |
...
</Events> |
The only other piece of advice is that any number of these "_" elements can appear within the "Events" element.
...
...
ACS provides a graphical user interface which provides some high-level information about events being sent, number of consumers, etc.:
This GUI is started by running "acseventbrowser" from the command-line after Manager is up and running.
...
...
...
...
Your best source of information is from the code itself (i.e., Doxygen). Other than that, here are the locations (in CVS) of all examples in this document:
ACS/LGPL/CommonSoftware/acsexmpl/ws/idl/acsexmplFridge.midl
ACS/LGPL/CommonSoftware/acsexmpl/ws/include/acsexmplFridgeImpl.h
ACS/LGPL/CommonSoftware/acsexmpl/ws/src/acsexmplFridgeImpl.cpp
ACS/LGPL/CommonSoftware/acsexmpl/ws/src/acsexmplClientFridgeNC.cpp
ACS/LGPL/CommonSoftware/acspyexmpl/src/*.py
ACS/LGPL/CommonSoftware/jcontexmpl/src/alma/demo/Event*
Links to the Doxygen, Javadoc, and Pydoc generated documentation can be found on the ACS webpage.