Fix primary scalability issue in distributor (camel) component

[ThePrez]

Currently, the act of removing processed events from the database table (for instance, Manzan.ManzanMsg) imposes a substantial scalability roadblock.

The Camel route pulls off a set of events, processes them in parallel, and then each of those subtasks does a DELETE from before continuing with another iteration. The individual DELETE calls impedes a substantial overhead and the consumer cannot keep up if a lot of events are generated.

Some ideas:

• Build custom code to handle the deletion from the table (for instance, have the Camel route add
• Use JDBC batch processing for the multiple delete operations
• Do the existing DELETE FROM asynchronously via the wiretap EIP

[jonnyz32]

If we're just inserting into Manzan.ManzanMsg in order to read events from the table, why not just send messages via a socket instead? Or if we're worried about an extremely heavy load of messages, how about a streaming solution such as kafka?

[jonnyz32]

Fixed by #169 and #170