[jira] [Comment Edited] (HIVE-13966) DbNotificationListener: can loose DDL operation notifications

[Rahul Sharma (JIRA)]

[ 
https://issues.apache.org/jira/browse/HIVE-13966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15348861#comment-15348861
 ] 

Rahul Sharma edited comment on HIVE-13966 at 6/24/16 11:25 PM:
---

Repost: Can a listener be registered with multiple properties, for ex: can 
DBNotification listener be part of 
hive.metastore.synchronous.event.listeners(proposed above) and 
hive.metastore.event.listeners.  Should this be a check from the 
code to prevent duplicated entries in the notification log or this be checked 
by the user ?


was (Author: rahul9269):
Repost: Can a listener be registered with multiple properties, for ex: can 
DBNotification listener be part of 
hive.metastore.synchronous.event.listeners(proposed above) and 
hive.metastore.event.listeners.  Should this be a check from the 
code to prevent duplicated entries in the notification log or this be checked 
by the user/CM ?

> DbNotificationListener: can loose DDL operation notifications
> -
>
> Key: HIVE-13966
> URL: https://issues.apache.org/jira/browse/HIVE-13966
> Project: Hive
>  Issue Type: Bug
>  Components: HCatalog
>Reporter: Nachiket Vaidya
>Assignee: Rahul Sharma
>Priority: Critical
>
> The code for each API in HiveMetaStore.java is like this:
> 1. openTransaction()
> 2. -- operation--
> 3. commit() or rollback() based on result of the operation.
> 4. add entry to notification log (unconditionally)
> If the operation is failed (in step 2), we still add entry to notification 
> log. Found this issue in testing.
> It is still ok as this is the case of false positive.
> If the operation is successful and adding to notification log failed, the 
> user will get an MetaException. It will not rollback the operation, as it is 
> already committed. We need to handle this case so that we will not have false 
> negatives.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (HIVE-13966) DbNotificationListener: can loose DDL operation notifications

[Colin Patrick McCabe (JIRA)]

[ 
https://issues.apache.org/jira/browse/HIVE-13966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15345781#comment-15345781
 ] 

Colin Patrick McCabe edited comment on HIVE-13966 at 6/23/16 5:30 AM:
--

I definitely agree that a synchronous listener is what we need.

It seems like the listener type itself should know whether it needs to be 
synchronous or not, right?  We can have a method somewhere in 
{{MetaStoreEventListener}}, which defaults to false, which specifies whether a 
listener is synchronous or not.  There shouldn't be any need to configure this 
since we should already know for each listener whether it needs to be 
synchronous or not based on its type.


was (Author: cmccabe):
I definitely agree that a synchronous listener is what we need.

It seems like the listener type itself should know whether it needs to be 
synchronous or not, right?  We can have a method somewhere in base class or 
interface that specifies whether a listener is synchronous or not.  There 
shouldn't be any need to configure this since we should already know for each 
listener whether it needs to be synchronous or not based on its type.

> DbNotificationListener: can loose DDL operation notifications
> -
>
> Key: HIVE-13966
> URL: https://issues.apache.org/jira/browse/HIVE-13966
> Project: Hive
>  Issue Type: Bug
>  Components: HCatalog
>Reporter: Nachiket Vaidya
>Assignee: Rahul Sharma
>Priority: Critical
>
> The code for each API in HiveMetaStore.java is like this:
> 1. openTransaction()
> 2. -- operation--
> 3. commit() or rollback() based on result of the operation.
> 4. add entry to notification log (unconditionally)
> If the operation is failed (in step 2), we still add entry to notification 
> log. Found this issue in testing.
> It is still ok as this is the case of false positive.
> If the operation is successful and adding to notification log failed, the 
> user will get an MetaException. It will not rollback the operation, as it is 
> already committed. We need to handle this case so that we will not have false 
> negatives.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)