New design for notificationQ/PersistentBus about killbill HOT 3 CLOSED

We fixed half of the issue by:
1 - removing the calls that were sensitive to latency-- entitlement IMM events-- but not using notificationQ.
2 - Create a dispatcher to fetch ready notifications across all queues and also prefetching a few notifications at once.

As a result we don't have to be aggressive in the polling and point 1 becomes less relevant.

Ordering still need to be addressed at some point.

from killbill.

We revisited that task-- for now we will not do the multiple locking strategy described above). Instead:

1. Extract Bus+ NotificationQ into new killbill-common repo
2. Fix Bus intensive queries by
   2.1 Dispatch from the post itself-- from context of a different thread-- instaed of polling for event on disk
   2.2 Still insert row on disk to cover failure scenarii and also for debugging purpose
   2.3 Move Processed row into different table to keep main table with a short number of rows
   2.4 Add a background polling mechanism for rows that were not processed
3. Revisit abstractions for:
   3.1 Dealing with internal/external bus
   3.2 Allow to plug KB lifecycle and initialize/start bus at the right time
4. Query optimization (remove NULL processing_owner to allow for better indexing)
5. Design plugin service for notificationQ

from killbill.

The code has been extracted under killbill-commons:

• Bus and notificationQ code has been abstracted (we can create multiple bus'es and notificationsQ)
• The performance issue with the bus has been addressed by keeping in in memory queue and doing select using record_id
• The growing tables has been addressed by creating history tables.

This is all we will do for now. Closing the bug

from killbill.