curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McKenzie <mckenzie....@gmail.com>
Subject Re: Next Steps
Date Tue, 18 Aug 2015 22:22:46 GMT
So, it seems that this is an issue with the WatcherNamespaceRemovalFacade.
It doesn't override

String fixForNamespace(String path, boolean isSequential)

which means that instead of using the wrapped CuratorFramework namespace,
it uses its own instance (which is null), meaning that the namespace fix
doesn't work.

I think that this version of the fixForNamespace is a new method on the
CuratorFramework since the CURATOR-217 branch was made.

Anyway, I have fixed it up and it seems to have fixed things. I'll rerun
all the tests and make sure nothing else is broken then I'll push the
changes.
cheers

On Tue, Aug 18, 2015 at 1:42 PM, Cameron McKenzie <mckenzie.cam@gmail.com>
wrote:

> Seems like a bunch of tests are failing:
>
>
> testWithNamespace(org.apache.curator.framework.recipes.locks.TestInterProcessMultiMutex)
>
> testWithNamespace(org.apache.curator.framework.recipes.locks.TestInterProcessMutex)
>
> testWithNamespace(org.apache.curator.framework.recipes.locks.TestInterProcessSemaphoreMutex)
> testLockACLs(org.apache.curator.framework.recipes.locks.TestLockACLs)
>
> testSimulationWithLocksNamespace(org.apache.curator.framework.recipes.locks.TestReaper)
>
> Tests are still running, and I haven't look into them yet, but it would
> seem based on the test names that something is broken with namespace stuff.
> Will have a look when I get a minute.
> cheers
>
>
> On Tue, Aug 18, 2015 at 1:38 PM, Scott Blum <dragonsinth@gmail.com> wrote:
>
>> Cool.  You should be able to just push a fix and then fast-foward
>> CURATOR-3.0.
>>
>> On Mon, Aug 17, 2015 at 11:29 PM, Cameron McKenzie <
>> mckenzie.cam@gmail.com> wrote:
>>
>>> I think it's all good. I've fixed up the couple of build issues on the
>>> 217-merged branch. Just running the unit tests. If everything's ok then
>>> I'll merge it back into CURATOR-3.0 and then I think we're back in a stable
>>> state, and I can start on CURATOR-214.
>>>
>>> On Tue, Aug 18, 2015 at 1:27 PM, Scott Blum <dragonsinth@gmail.com>
>>> wrote:
>>>
>>>> I think just confirm that ZooDefs.CONFIG_NODE is the correct watcher
>>>> path for getConfig()?
>>>>
>>>> On Mon, Aug 17, 2015 at 11:19 PM, Jordan Zimmerman <
>>>> jordan@jordanzimmerman.com> wrote:
>>>>
>>>>> Sorry - it’s hard to follow this thread. What do I need to do?
>>>>>
>>>>> -Jordan
>>>>>
>>>>>
>>>>>
>>>>> On August 17, 2015 at 6:18:21 PM, Cameron McKenzie (
>>>>> mckenzie.cam@gmail.com) wrote:
>>>>>
>>>>> Thanks Scott,
>>>>> I've just merged CURATOR-217 into master and have one small issue.
>>>>>
>>>>> Jordan, with the changes you made with to the Watching.java class, the
>>>>> getWatcher() call now takes a CuratorFramework reference and a path
>>>>> reference.
>>>>>
>>>>> The GetConfigBuilderImpl breaks when merging because it's using the old
>>>>> getWatcher() call that doesn't exist any more. This isn't an issue to
>>>>> fix,
>>>>> but I'm just wondering what path reference should be used for the
>>>>> configuration case, as it's a different sort of watch. It's just
>>>>> passed to
>>>>> the getConfig() call on the ZooKeeper class. It seems that I can't just
>>>>> pass in a null path as this gets validated. Suggestions?
>>>>>
>>>>> cheers
>>>>>
>>>>>
>>>>> On Tue, Aug 18, 2015 at 3:30 AM, Jordan Zimmerman <
>>>>> jordan@jordanzimmerman.com> wrote:
>>>>>
>>>>> > Great work. Thank you.
>>>>> >
>>>>> > ====================
>>>>> > Jordan Zimmerman
>>>>> >
>>>>> > > On Aug 17, 2015, at 12:10 PM, Scott Blum <dragonsinth@gmail.com>
>>>>> wrote:
>>>>> > >
>>>>> > > This is now done, sorry for the delay. Let me describe the
current
>>>>> state
>>>>> > > of the world:
>>>>> > >
>>>>> > > CURATOR-215-original, CURATOR-160-original, CURATOR-3.0-old,
>>>>> > > CURATOR-3.0-temp - these are the old versions of all the branches,
>>>>> we
>>>>> > > should consider pruning them at some point.
>>>>> > >
>>>>> > > CURATOR-215, CURATOR-160, CURATOR-3.0 - these are fixed/rebased
>>>>> versions
>>>>> > of
>>>>> > > the branches we should stick with.
>>>>> > >
>>>>> > > *ALL MASTER COMMITS ARE NOW MERGED INTO CURATOR-3.0.* There
is
>>>>> nothing
>>>>> > > that has been committed to master that isn't in 3.0 now.
>>>>> > >
>>>>> > > Procedures going forward:
>>>>> > >
>>>>> > > - If you're working on stuff for 2.8 / 2.9, branch from master
and
>>>>> > > merge/commit to master.
>>>>> > >
>>>>> > > - If you're working on stuff for 3.0, branch from CURATOR-3.0
and
>>>>> > > merge/commit to CURATOR-3.0.
>>>>> > >
>>>>> > > - Periodically, we'll want to get master changes into 3.0.
To do
>>>>> this,
>>>>> > *check
>>>>> > > out CURATOR-3.0*, and merge master into that, then push the
result
>>>>> after
>>>>> > > fixing conflicts (which should be small / non-existent). *Don't
do
>>>>> it
>>>>> > the
>>>>> > > other way, don't check out master and merge 3.0 into it.*
>>>>> > >
>>>>> > > For discussion: there is a *3.0-rejects* branch. One of the
commits
>>>>> > there
>>>>> > > is and added System.out.println that I think we don't want.
The
>>>>> other
>>>>> > one
>>>>> > > is the work to migrate to fasterxml Jackson. I think we actually
>>>>> want
>>>>> > this
>>>>> > > commit on 3.0. Please take a look and let me know, if we want
this
>>>>> > commit,
>>>>> > > we should cherry-pick it onto 3.0. I'm happy to do that.
>>>>> > >
>>>>> > > Everything I did should be reversible, so let me know if I
screwed
>>>>> > anything
>>>>> > > up!
>>>>> > >
>>>>> > > --Scott
>>>>> >
>>>>>
>>>>
>>>>
>>>
>>
>

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