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.
Sometimes it takes longer than five seconds to receive an event after it was published. What's going on?
If the developer-implemented receive method of a Consumer class takes a large amount of time to complete, this bottlenecks events being sent to that particular consumer. That is, there is a mutex lock somewhere in the TAO notification service making sure the first call to push_structured_event completes before this consumer method is invoked a second time.
The effect this has on other consumer instances is undesireable as well but not horrible most of the time mainly because TAO uses a pool of threads to handle consumer objects instead of a single thread for all consumers. Events being received by other consumers get delayed even if their receive method is "lightweight".
To get around this the HLA group has stated that non-ACS subsystems should queue the incoming events from their receive method and have a separate thread created within their code to process the events later. You should use your best judgement when deciding if your receive implementation is "heavy" or not. In general, implementations involving CORBA calls on other objects need to have the event queued. The generic steps needed to process these events later are:
ACS may help with the decision whether any particular receive
method should be implemented asynchronously, see NCClassesShouldMonitorReceiveMethodExecutionTime.