Review Board 1.7.22


HIVE-5441: Async query execution doesn't return resultset status

Review Request #14486 - Created Oct. 4, 2013 and updated

Prasad Mujumdar
trunk
HIVE-5441
Reviewers
hive
hive-git
Separate out the query compilation and execute that part synchronously.
Added test cases
Total:
3
Open:
1
Resolved:
2
Dropped:
0
Status:
From:
Description From Last Updated Status
OK, I see what you mean. I was looking at just the commented line, and didn't look at the full ... Thejas Nair Nov. 8, 2013, 12:22 a.m. Open
Review request changed
Updated (Nov. 6, 2013, 11:50 p.m.)
Rebased and addressed the review feedback.
Posted (Nov. 7, 2013, 4:31 p.m.)
+1 from my side though we should wait to see if Carl or Thejas have anymore feedback.
Question: what happens if compile throws an exception, like NPE or something. Does that mean the locks do not get released?

If that is true then I think we should follow a follow-on jira, as it's not introduced here, to ensure the locks are released. 
  1. The lock will be freed if an exception is thrown. That is not a problem.
    
  2. Great to hear! For my own learning purposes, could you share how exactly that will occur? I just don't see it.
  3. Using 
    sychronized(obj){
    //sync code
    }
    is equivalent to -
    
    obj.intrinsicLock.lock();
    try{
     //sync code
    }
    finally{
     //gets called even on exception
     obj.intrinsicLock.unlock();
    }
  4. I think there maybe some kind of confusion here. I wasn't referring to the synchronized statement... I was referring to the HiveLock objects that the driver owns.
Ship it!
Posted (Nov. 7, 2013, 9:17 p.m.)
Ship It!
Posted (Nov. 8, 2013, 12:22 a.m.)

   

  
OK, I see what you mean. I was looking at just the commented line, and didn't look at the full view-diff page. Yes, the releaseLocks won't get called. That looks like a problem.

Thanks to Vaibhav to pointing it out to me.
  1. OK, thanks for responding. I'll open a jira.
  2. https://issues.apache.org/jira/browse/HIVE-5781
  3. I guess the lock are acquired a bit later, just before the execution. We can actually get rid of that releaseLocks() in case of compiler error.