[
https://issues.apache.org/jira/browse/HIVE-11515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14700569#comment-14700569
]
Siddharth Seth commented on HIVE-11515:
---------------------------------------
[~navis] - Do you have more details on how the query fails in the situations
where you see this occur ? Is there an exception or does the query hang or some
other manifestation ?
I think the patch is primarily moving the registerForVertexNotifications into
the constructor - which is fine. However, the condition where an event is
received before registering for vertex success notifications is already handled
in checkForSourceCompletion
{code}
int expectedEvents = numExpectedEventsPerSource.get(name).getValue();
if (expectedEvents < 0) {
// Expected events not updated yet - vertex SUCCESS notification not
received.
return;
} else {
{code}
Even if all the events were to come in before registering for the notification,
when prune is finally called - and a notification is received, these events
will be processed.
On the Tez side, it makes sure to send in events only after the Initializer has
been constructed - that's the HiveSplitGenerator.
> Still some possible race condition in DynamicPartitionPruner
> ------------------------------------------------------------
>
> Key: HIVE-11515
> URL: https://issues.apache.org/jira/browse/HIVE-11515
> Project: Hive
> Issue Type: Bug
> Components: Query Processor, Tez
> Reporter: Navis
> Assignee: Navis
> Priority: Minor
> Attachments: HIVE-11515.1.patch.txt
>
>
> Even after HIVE-9976, I could see race condition in DPP sometimes. Hard to
> reproduce but it seemed related to the fact that prune() is called by
> thread-pool. With some delay in queue, events from fast tasks are arrived
> before prune() is called.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)