Re: In the constructor of JobInProgress, why is it safe to call FileSyste.closeAllForUGI().

2013-03-29 Thread Devaraj Das
Hey Xiao, iirc, the ugi will be different for the second ec2-user's job submission. So they should not interfere... On Mar 22, 2013 8:05 AM, "Xiao Yu" wrote: > Thanks a lot for the reply. > > I have made several changes here and there, but I do not think they are > quite relevant (the most relev

Re: In the constructor of JobInProgress, why is it safe to call FileSyste.closeAllForUGI().

2013-03-22 Thread Xiao Yu
Thanks a lot for the reply. I have made several changes here and there, but I do not think they are quite relevant (the most relevant modification on the control flow of JIP construction is at the end of JobInProgress$initTasks() where I add all the map tasks of this job into a data structure in J

Re: In the constructor of JobInProgress, why is it safe to call FileSyste.closeAllForUGI().

2013-03-22 Thread Harsh J
The current user (UserGroupInformation.getCurrentUser()) is the user active in the RPC call thats invoking these functions, and not the JT user exactly. However, given that the JIP construction is outside of a synchronized step and can potentially happen in parallel with another JIP request, it is

In the constructor of JobInProgress, why is it safe to call FileSyste.closeAllForUGI().

2013-03-21 Thread Xiao Yu
Hi, This might be a naive question, but I am having a difficult time to understand it. At the end of the constructor of JobInProgress, in the finally clause, the code calls FileSystem.closeAllForUGI(UserGroupInformation.getCurrentUser()), but why is it safe. My concern is that the current user is