aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Farner <wfar...@apache.org>
Subject Re: AURORA-507
Date Fri, 30 Jan 2015 19:22:18 GMT
I think the guidance i gave you early on may have been overkill.  You might
consider isolating your change to SchedulerThriftInterface, and filter the
result of lockManager.getLocks() to determine if the entity is locked
(based on the lock key).  This is obviously not optimal w.r.t. performance,
but given that the number of locks is likely to be quite small, an O(n)
operation should be fine to save the complexity.

-=Bill

On Thu, Jan 29, 2015 at 10:25 PM, Arunabha Ghosh <arunabha.gh@gmail.com>
wrote:

> Hmm, I'm happy to look at AURORA-189 first, but I'd still like to keep
> working on 507 if possible. From reading up on MyBatis, it does not look to
> be very complicated.
>
> Does all persistent lock state end up in the DbLockStore eventually ? i.e
> does WriteAheadStorage call DbLockStore internally (through the
> LockStore.Mutable member) ?
>
> Also, is the approach I outlined feasible ?
>
> Thanks,
> Arunabha
>
> On Thu, Jan 29, 2015 at 11:16 AM, Bill Farner <wfarner@apache.org> wrote:
>
> > The missing detail is that MyBatis dynamically creates an implementation
> of
> > LockMapper based on LockMapper.xml [1].
> >
> > However, i'm now realizing that this should probably not be classified
> as a
> > newbie ticket, since the the plumbing goes pretty deep, and knowledge of
> > several technologies is necessary.  If you're just looking for something
> to
> > cut you teeth, i suggest you look past this one.  I'll suggest this as an
> > alternative: https://issues.apache.org/jira/browse/AURORA-189
> >
> >
> > [1]
> >
> >
> https://github.com/apache/incubator-aurora/blob/master/src/main/resources/org/apache/aurora/scheduler/storage/db/LockMapper.xml
> >
> > -=Bill
> >
> > On Wed, Jan 28, 2015 at 10:22 PM, Arunabha Ghosh <arunabha.gh@gmail.com>
> > wrote:
> >
> > > 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
> > > <clambert@twitter.com.invalid
> > > > wrote:
> > >
> > > > Updated.  Enjoy!
> > > >
> > > >
> > > > On Tue, Jan 27, 2015 at 8:39 PM, Arunabha Ghosh <
> arunabha.gh@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Ok, my JIRA username is 'arunabha'
> > > > >
> > > > > On Tue, Jan 27, 2015 at 7:29 PM, Chris Lambert
> > > > > <clambert@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 <
> wfarner@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
<
> > > > maxim@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.gh@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
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message