Reliable Event Delivery

Good explanation of where this PR leaves us is on the public website: http://www.candlepinproject.org/docs/gutterball/reliable_events.html

Important changes made to EventSource for durable hornetq queues, and preventing duplicate messages that could be caused by server restart. (duplicate messages are still a possibility GB should be prepared for)

Event status added to gutterball, which combines with two phase event processing to hopefully limit the exceptions that could be thrown during event processing, and allow us to identify events that failed later.

Added a super-admin only API call GET /admin/queues to view the HornetQ (not qpid) queues we have configured and a count of the messages pending in each.




Hrmm...
I don't know. It's probably fine; I'm just not entirely fond of a design where we have to make guesses and assumptions to come up with a state. Granted, in the event of a catastrophic database issue after setting the initial RECEIVED status, but before (completely) processing the event, we'll have the same state concern. I just feel that it's probably not all that likely and not worth sacrificing explicity. At the end of the day, however, I won't lose sleep over a "missing" state.

Also, do we have any issues or potential cases such that one event failing prevents others from being run? When we re-run "failed" events, would we dump all DB info that occurs after the failed event and regenerate it from the subsequent events?