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 23:12:12 GMT
That seems to have fixed the namespace issues. There are still 2 tests
failing, but these are the ones that Mike has raised JIRA tickets for
already, so nothing additional is broken by the 3.0 changes. I will merge
into 3.0 now.
cheers

On Wed, Aug 19, 2015 at 8:22 AM, Cameron McKenzie <mckenzie.cam@gmail.com>
wrote:

> 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