Page History

...

• light weight (a library)
• provide simple interface
• decouple the publisher and subscriber so that they need not be aware of other
• powerful enough to provide filters for events of a type to wildcard (all events)
• deliver events asynchronously. Publisher publishes the event and forgets.

In order for CloudStack be able to generate rich set of events and have clean mechanism to generate events, its important to have state machine associated with every resource that is managed by CloudStack. So another goal of this proposal is to associate with every resource (User VM, Volume, Nic, Network, public IP, snapshot, template etc) with a state machine and generate events as part of the state change. So the publishers of events in CloudStack will become that StateListeners associated with the resource. 

...

• Google Guava Event bus library which is under Apache License 2.0 seems to be good fit for implementing event bus in CloudStack. Its light-wieght and has simple interface but very powerful. But any other alternatives could be evaluated
• If there is clustered management server setup then subscribers need to be present on the both management servers. Using a messaging queue servers like RabbitMQ can be used for event bus, but i thinks will add complexity into CloudStack. Are there any scenarios where having in-process event bus proposed will fall short in clustered management server setups?