Thanks Chris ! After a look at the code here's the approach I'm considering
1) Override releaseLock in LockManager to take an extra parameter which can be used to return extra information. 2) Add a doesLockExist method to the LockStore interface and implement that in DbLockStore and WriteAheadStorage 3) Use the doesLockExist method in the implementations of the overridden releaseLock method in LockManager 2) Make SchedulerThriftInterface call the overloaded version of releaseLock in LockManager and add extra information to the response if needed. Does that seem like a reasonable way to proceed ? I have a few questions 1) I'm also a little bit mystified by the LockMapper interface which does not seem to be implemented anywhere. DbLockStore uses this interface. 2) WriteAheadStorage uses a LockStore.Mutable member to implement the actual removeLock method, however I'm unable to figure out which implementation of LockStore.Mutable is being used as the WriteAheadStorage class is instantiated in LogStorage which is instantiated by Guice (Blast!, I thought I'd seen the last of Guice) Thanks, Arunabha On Tue, Jan 27, 2015 at 9:07 PM, Chris Lambert <clamb...@twitter.com.invalid > wrote: > Updated. Enjoy! > > > On Tue, Jan 27, 2015 at 8:39 PM, Arunabha Ghosh <arunabha...@gmail.com> > wrote: > > > Ok, my JIRA username is 'arunabha' > > > > On Tue, Jan 27, 2015 at 7:29 PM, Chris Lambert > > <clamb...@twitter.com.invalid > > > wrote: > > > > > > > > > > Bill, not sure how I should get a JIRA username. I signed up for > > > > Reviewboard though. > > > > > > > > > I think you can just use the signup link on the login page at > > > issues.apache.org/jira > > > <https://issues.apache.org/jira/secure/Signup!default.jspa>. > > > > > > Chris > > > > > > > > > > > > > On Tue, Jan 27, 2015 at 5:01 PM, Bill Farner <wfar...@apache.org> > > wrote: > > > > > > > > > I don't believe we have really discussed the future of these RPCs, > > and > > > > > specifically whether we will remove the ability for users to > > implement > > > > > client-side updaters. I think a broader discussion on the future > of > > > job > > > > > updates is warranted if you'd like to propose removing that set of > > > RPCs. > > > > > > > > > > -=Bill > > > > > > > > > > On Tue, Jan 27, 2015 at 4:59 PM, Maxim Khutornenko < > ma...@apache.org > > > > > > > > wrote: > > > > > > > > > > > Thanks for reaching out! We are most likely going to deprecate > the > > > > > > acquireLock and releaseLock RPCs once the client updater is > removed > > > > > > (AURORA-785). > > > > > > > > > > > > There are plenty of other entry level items to chose from [1] > > though > > > > > > and we would greatly appreciate your help! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://issues.apache.org/jira/browse/AURORA-1064?jql=project%20%3D%20AURORA%20AND%20status%20in%20(Open%2C%20Accepted)%20AND%20labels%20in%20(newbie) > > > > > > > > > > > > Thanks, > > > > > > Maxim > > > > > > > > > > > > On Tue, Jan 27, 2015 at 4:49 PM, Arunabha Ghosh < > > > arunabha...@gmail.com > > > > > > > > > > > wrote: > > > > > > > Is anyone working on AURORA-507 > > > > > > > <https://issues.apache.org/jira/browse/AURORA-507> ? If not > I'd > > > like > > > > > to > > > > > > > start working on it. What would be a good place to start ? > > > > > > > > > > > > > > Thanks, > > > > > > > Arunabha > > > > > > > > > > > > > > > > > > > > >
