[HCATALOG-546] Rework HCatalog's JMS Notifications

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 0.4.1
• Fix Version/s: 0.5
• Component/s: notification
• Assignee: Mithun Radhakrishnan
• Reporter: Mithun Radhakrishnan
• Created: 07/Nov/12 00:01
• Updated: 01/Oct/19 22:09
• Resolved: 10/Jan/13 02:08

Description

In 0.4.1, the NotificationListener listens for metastore operations and emits JMS notifications containing the entire metastore-objects (Database/Table/Partitions) in Java-serialized form. The assumption at the time was that consumers might need access to the whole object. This policy poses a couple of problems:

1. The notifications are verbose, since it conveys a bunch of information that's available from querying the metastore anyway.

2. Consumers of these JMS notifications (e.g. Oozie) would now be dependent on the Java class definitions of metastore-objects. If they change, Oozie would also need to be restarted (with updated libs), to consume the notifications.

Ideally, the notifications should convey only the minimum information that identifies the metastore-change unambiguously. (Everything else can be queried for.) They should be backward compatible. If new fields are added, existing consumers shouldn't break (unless they intend to consume the new fields). Also, the notification-format ought to be pluggable.

For the initial rework, we're proposing to use a JSON-string to represent the notification-content. We're also proposing a helper-class for the likes of Oozie to use, that converts the strings to POJOs, in a backward-compatible fashion.

I'll attach sample notifications and a tentative patch shortly.

Issue Links

• is blocked by: HCATALOG-556 HCatalog-trunk doesn't build against Hive-0.10.0
• is blocked by: HIVE-3680 Include Table information in Hive's AddPartitionEvent.