Today I will take a short break to discuss another modular input for Splunk. We will look at how to tie RSS feeds into Splunk. This is another input for Splunk that something that makes subscription easier. The same is true for any kind of notification services. The advantage in this kind of an input is that the application doesn't have to spin to poll.
This saves on CPU. If you look at the cpu usage by something like the Microsoft Outlook application, its very very low even with high loads. I'm not saying thats enabled merely by a push model, but it certainly contributes to it.
Another example of event notification model is the dot net API for MSMQ. The APIs were designed later than the windows ones and come with a better model to send and receive from the message queues.  The event notification model of the C# language is also very helpful in this regard.
If we look at a problem of reading the current message from multiple queues and we look at the API model that would best suit this need, we would like an event notification for any of the queues. This model helps us very well. Otherwise we wake up and poll on the queues and those that have the messages will need to be serviced. Since the queues can vary in size and in traffic, we want a solution that is both scalable and resource savvy. In this case we could treat all the queues and all the messages to be similar even if they are transactional or non-transactional, binary or xml messages etc.
and the task of reading a message from a queue can be delegated to the different workers.