Re: [ANNOUNCE] Enrico Olivelli is the new PMC Chair

Indeed, thank you! On Wed, Nov 18, 2020 at 8:50 PM Cameron McKenzie wrote: > Congratulations Enrico, > Thanks for stepping up! > cheers > > On Thu, Nov 19, 2020 at 11:53 AM Jordan Zimmerman > wrote: > >> Hello Everyone, >> >> Congratulations to Enrico Olivelli who has been nominated and has >>

Re: TreeCacheIterator

Hi Jordan, we're hanging in there. Hope you are as well! I can probably take a look later today. On Tue, Mar 31, 2020 at 12:37 PM Jordan Zimmerman < jor...@jordanzimmerman.com> wrote: > Hi Scott, > > I hope you're well in this trying time... > > If you have the time, I'd appreciate a quick

Re: Mzxid vs Version

I don't recall, version might work just as well. On Sat, Nov 9, 2019 at 9:37 AM Jordan Zimmerman wrote: > Hey Scott (or anyone else), > > Do you remember why in TreeCache you chose to check for a changed node by > doing "oldChildData.getStat().getMzxid() == newStat.getMzxid()" vs using > the

[jira] [Commented] (CURATOR-477) Ability to turn off Zk Watches in Curator Framework

[ https://issues.apache.org/jira/browse/CURATOR-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16624965#comment-16624965 ] Scott Blum commented on CURATOR-477: PR seems fine to me if that's what we want, although I wonder

[jira] [Comment Edited] (CURATOR-477) Ability to turn off Zk Watches in Curator Framework

[ https://issues.apache.org/jira/browse/CURATOR-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16624965#comment-16624965 ] Scott Blum edited comment on CURATOR-477 at 9/23/18 4:52 AM: - PR seems fine

Re: [VOTE] Release Apache Curator version 4.0.0 - candidate 3

rdan On Jul 28, 2017, at 3:21 AM, Scott Blum <dragonsi...@gmail.com> wrote: Tests passed for me on Mac. On Fri, Jul 28, 2017 at 12:18 AM, Jay Zarfoss <zarf...@apache.org> wrote: > I just fired everything up and I see the same errors. > > On Thu, Jul 27, 2017 at 9:02 PM, F

Re: [VOTE] Release Apache Curator version 4.0.0 - candidate 3

> org.apache.curator.framework.imps.TestReconfiguration.testAddAndRemove( > > TestReconfiguration.java:277) > > > > Anyone else has this issue or only me? > > > > On Thu, Jul 27, 2017 at 8:55 PM, Fangmin Lv <lvfang...@gmail.com> wrote: > > > > > +

Re: [VOTE] Release Apache Curator version 4.0.0 - candidate 3

> Jordan Zimmerman > > On Jul 27, 2017, at 9:03 PM, Scott Blum <dragonsi...@gmail.com> wrote: > > Same as always! I don't have the bandwidth to actively monitor Curator, > test it myself, or try out a new version against a code base I work on that > uses it. So I can't v

Re: [VOTE] Release Apache Curator version 4.0.0 - candidate 3

wrote: > What's the reason for +0 Scott? > > > On Jul 27, 2017, at 3:55 PM, Scott Blum <dragonsi...@gmail.com> wrote: > > > > +0 > > > > On Wed, Jul 26, 2017 at 7:42 PM, Jordan Zimmerman < > > jor...@jordanzimmerman.com> wrote: > > > >>

Re: [VOTE] Release Apache Curator version 4.0.0 - candidate 3

+0 On Wed, Jul 26, 2017 at 7:42 PM, Jordan Zimmerman < jor...@jordanzimmerman.com> wrote: > > All the tests are passing\ > In 40 min for which is a huge difference. > > > (though the actual Maven task for the ZK3.4 > > compatibility testing fails after all of the tests pass). > > Yeah = there's

Re: IMPORTANT: The master branch is now Curator 3.x

nything. I'm going to > open an Issue for this. > > -Jordan > > > On May 8, 2017, at 12:54 AM, Scott Blum <dragonsi...@gmail.com> wrote: > > > > I'll try it out tomorrow. > > > > On Sun, May 7, 2017 at 4:15 AM, Jordan Zimmerman < > jor

Re: Merge strategy now that CURATOR-3.0 is master

0 as examples of changes that also apply to > CURATOR-2.0. Cherry-pick is one option. A git patch/apply would also work. > > -JZ > > On May 8, 2017, at 7:50 AM, Scott Blum <dragonsi...@gmail.com> wrote: > > We should definitely be very clear on the goals before trying to pick

Re: Merge strategy now that CURATOR-3.0 is master

We should definitely be very clear on the goals before trying to pick a specific technical strategy! If 2.0 is basically "done" except for bugfixes, then the best strategy is probably to just do everything on master (3.0) and only backport / cherry-pick specific bugfixes. I'm assuming that was

Re: IMPORTANT: The master branch is now Curator 3.x

I'll try it out tomorrow. On Sun, May 7, 2017 at 4:15 AM, Jordan Zimmerman <jor...@jordanzimmerman.com > wrote: > Scott - any more info on this? > > -JZ > > > On May 2, 2017, at 11:33 PM, Scott Blum <dragonsi...@gmail.com> wrote: > > > > BTW: I tried

Re: IMPORTANT: The master branch is now Curator 3.x

BTW: I tried running tests on the new master, and I get consistent hangs on: org.apache.curator.framework.imps.TestFrameworkEdges Unsure if that was a problem in 3.0 or old master. Have you seen this before? On Tue, May 2, 2017 at 4:31 PM, Jordan Zimmerman wrote:

[jira] [Comment Edited] (CURATOR-406) The CURATOR-3.0 branch should become master

[ https://issues.apache.org/jira/browse/CURATOR-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15993647#comment-15993647 ] Scott Blum edited comment on CURATOR-406 at 5/2/17 8:15 PM: What I did

[jira] [Commented] (CURATOR-406) The CURATOR-3.0 branch should become master

[ https://issues.apache.org/jira/browse/CURATOR-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15993647#comment-15993647 ] Scott Blum commented on CURATOR-406: What I did. (Note, my Apache remote is named "apache&q

[jira] [Comment Edited] (CURATOR-406) The CURATOR-3.0 branch should become master

[ https://issues.apache.org/jira/browse/CURATOR-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15993647#comment-15993647 ] Scott Blum edited comment on CURATOR-406 at 5/2/17 8:14 PM: What I did

[jira] [Commented] (CURATOR-406) The CURATOR-3.0 branch should become master

[ https://issues.apache.org/jira/browse/CURATOR-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15993637#comment-15993637 ] Scott Blum commented on CURATOR-406: I'm not super strongly opinionated, but I haven't seen other

[jira] [Resolved] (CURATOR-406) The CURATOR-3.0 branch should become master

[ https://issues.apache.org/jira/browse/CURATOR-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Blum resolved CURATOR-406. Resolution: Fixed - master is on 3.0 now - I left a CURATOR-2.0 branch where master was, you

[jira] [Comment Edited] (CURATOR-406) The CURATOR-3.0 branch should become master

[ https://issues.apache.org/jira/browse/CURATOR-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15993606#comment-15993606 ] Scott Blum edited comment on CURATOR-406 at 5/2/17 7:55 PM: Do you want

[jira] [Comment Edited] (CURATOR-406) The CURATOR-3.0 branch should become master

[ https://issues.apache.org/jira/browse/CURATOR-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15993606#comment-15993606 ] Scott Blum edited comment on CURATOR-406 at 5/2/17 7:55 PM: Do you want

[jira] [Comment Edited] (CURATOR-406) The CURATOR-3.0 branch should become master

[ https://issues.apache.org/jira/browse/CURATOR-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15993606#comment-15993606 ] Scott Blum edited comment on CURATOR-406 at 5/2/17 7:56 PM: Do you want

[jira] [Assigned] (CURATOR-406) The CURATOR-3.0 branch should become master

[ https://issues.apache.org/jira/browse/CURATOR-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Blum reassigned CURATOR-406: -- Assignee: Scott Blum > The CURATOR-3.0 branch should become mas

[jira] [Commented] (CURATOR-406) The CURATOR-3.0 branch should become master

[ https://issues.apache.org/jira/browse/CURATOR-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15993606#comment-15993606 ] Scott Blum commented on CURATOR-406: Do you want the old master as "master-2.0" or &q

Re: Change master to be CURATOR-3.0?

u wrote. But, I don't see how to make CURATOR-3.0 be > master on remotes/forks without a force. > > -JZ > > > On May 2, 2017, at 2:40 PM, Scott Blum <dragonsi...@gmail.com> wrote: > > > > The best way I can think to explain it is this: > > > > Every

Re: Change master to be CURATOR-3.0?

erman <jor...@jordanzimmerman.com > wrote: > Wow - nice. I didn't see that anywhere on SO. Can you point at doc for > this or describe the steps first? > > -Jordan > > > On May 2, 2017, at 2:29 PM, Scott Blum <dragonsi...@gmail.com> wrote: > > > > Hey guys, this isn't hard.

Re: Change master to be CURATOR-3.0?

Hey guys, this isn't hard. All we have to do is create a merge commit between 3.0 and master, then you can fast-forward master to the merge commit. No push -f required. Would you guys like me to do this now? I can leave a CURATOR-2.0 branch where master is now. On Tue, May 2, 2017 at 3:20

Re: Determining ZNode change for the cache recipes

I think mxzid should be fine, it should be a ZK-wide unique value. On Sun, Mar 12, 2017 at 6:03 PM, Jordan Zimmerman < jor...@jordanzimmerman.com> wrote: > So, is mxzid enough? Do we check version too? Is compared the data even > necessary? > > -JZ > > On Mar 12, 2017

Re: Determining ZNode change for the cache recipes

I think "version" and "mzxid" should be equally reliable for determining that the contents changed. Whenever a change happens the version gets incremented while the mzxid gets set to the associated zk transaction id. So I don't see a problem with ifVersion == data.getStat().getVersion() but I

Re: Determining ZNode change for the cache recipes

I never considered this corner case! So yeah, I agree that mxzid would be more reliable. On Sun, Mar 12, 2017 at 5:09 PM, Scott Blum <dragonsi...@gmail.com> wrote: > I think "version" and "mzxid" should be equally reliable for determining > that the contents changed. W

Re: [VOTE] Release Apache Curator versions 2.12.0 and 3.3.0

+1 On Thu, Mar 2, 2017 at 4:37 PM, Cameron McKenzie wrote: > Hello, > > This is the vote for Apache Curator versions 2.12.0 and 3.3.0 > > *** Please download, test and vote within approx. 72 hours > > Note that we are voting upon the source (tag) and binaries are >

[jira] [Commented] (CURATOR-171) LeaderLatch isn't aware if it's own ephemeral node goes away

[ https://issues.apache.org/jira/browse/CURATOR-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15826685#comment-15826685 ] Scott Blum commented on CURATOR-171: I think he's saying, the leader can talk to ZK (no partition

[jira] [Commented] (CURATOR-171) LeaderLatch isn't aware if it's own ephemeral node goes away

[ https://issues.apache.org/jira/browse/CURATOR-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15824551#comment-15824551 ] Scott Blum commented on CURATOR-171: I could totally get on board with the idea that everyone watches

Re: Pull Requests needing review

. Something better could and should exist. On Sun, Jan 15, 2017 at 9:34 PM, Jordan Zimmerman < jor...@jordanzimmerman.com> wrote: > I love Maven :D > > https://rule1.quora.com/Use-Maven-Not-Gradle > > -JZ > > > On Jan 15, 2017, at 12:36 PM, Scott Blum <dragonsi..

Re: Pull Requests needing review

I glanced at the maven shade one, seemed okay. Maven is such a shit ball though that the rule of thumb is that of the output is right, it's right. Lol On Jan 15, 2017 8:30 AM, "Jordan Zimmerman" wrote: > Thanks Cameron > > > On Jan 13, 2017, at 11:33 PM, Cameron

[jira] [Commented] (CURATOR-171) LeaderLatch isn't aware if it's own ephemeral node goes away

[ https://issues.apache.org/jira/browse/CURATOR-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15822946#comment-15822946 ] Scott Blum commented on CURATOR-171: For what it's worth (this isn't a Curator issue), but in Solr

[jira] [Assigned] (CURATOR-374) Reduce memory usage in TreeCache

[ https://issues.apache.org/jira/browse/CURATOR-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Blum reassigned CURATOR-374: -- Assignee: Scott Blum > Reduce memory usage in TreeCa

Re: [VOTE] Release Apache Curator versions 2.11.1 and 3.2.1

+0, I trust you guys' assessments. On Sun, Nov 13, 2016 at 8:22 PM, Cameron McKenzie wrote: > +1 (binding) for both releases for me > > Have build and run unit tests on both releases. > > Some intermittent test failures on the 3.0 branch (as usual) which were >

Re: [DISCUSS] Refactor Curator for other backends

Seems very ambitious! Looks like some of the most useful recipes like locks, leases, and elections are built-in to etcd. On Wed, Jul 27, 2016 at 9:48 PM, Jordan Zimmerman < jor...@jordanzimmerman.com> wrote: > I know nothing about etcd/raft either. My motivation is more future > thinking. > > >

Re: CURATOR-3.0 tests

> > On Thu, May 26, 2016 at 2:06 AM, Scott Blum <dragonsi...@gmail.com> wrote: > > > Sure, what SHA are they failing at Cam? > > > > On Wed, May 25, 2016 at 9:36 AM, Jordan Zimmerman < > > jor...@jordanzimmerman.com> wrote: > > > > > S

Re: CURATOR-3.0 tests

Sure, what SHA are they failing at Cam? On Wed, May 25, 2016 at 9:36 AM, Jordan Zimmerman < jor...@jordanzimmerman.com> wrote: > Scott can you take a look? > > -Jordan > > > On May 25, 2016, at 4:35 AM, Cameron McKenzie > wrote: > > > > Tree cache tests are still

[jira] [Commented] (CURATOR-319) NodeCache recreates deleted parents of the node being cached

[ https://issues.apache.org/jira/browse/CURATOR-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15267204#comment-15267204 ] Scott Blum commented on CURATOR-319: I understand in the past there may have been an issue

[jira] [Commented] (CURATOR-319) NodeCache recreates deleted parents of the node being cached

[ https://issues.apache.org/jira/browse/CURATOR-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15267181#comment-15267181 ] Scott Blum commented on CURATOR-319: I actually have to agree with Tommy in principle. It makes

[jira] [Commented] (CURATOR-319) NodeCache recreates deleted parents of the node being cached

[ https://issues.apache.org/jira/browse/CURATOR-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15267103#comment-15267103 ] Scott Blum commented on CURATOR-319: As a workaround, if you use TreeCache with depth = 0 it won't

[jira] [Commented] (CURATOR-288) Provide a mechanism to limit tree traversal in TreeCache + Return old values in NODE_REMOVED event

[ https://issues.apache.org/jira/browse/CURATOR-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159447#comment-15159447 ] Scott Blum commented on CURATOR-288: Isn't this done now, with TreeCacheSelector? > Prov

Re: NamespaceWatcher hashCode and equals still bugging me

NamespaceWatcher. What do you think? On Wed, Feb 10, 2016 at 8:48 AM, Jordan Zimmerman < jor...@jordanzimmerman.com> wrote: > Scott - are you OK with a release or should I wait for more discussion on > this issue? > > -Jordan > > On Feb 9, 2016, at 1:50 PM, Scott Blu

Re: NamespaceWatcher hashCode and equals still bugging me

arn people that Curator wraps > watchers. > > Agreed? > > -Jordan > > > On Feb 10, 2016, at 11:56 AM, Scott Blum <dragonsi...@gmail.com> wrote: > > I think there's a subtlety here that I didn't explain very carefully. > > Assume w = a raw watcher. > > I

Re: NamespaceWatcher hashCode and equals still bugging me

> appear as equal inside of ZK. > > -Jordan > > On Feb 10, 2016, at 11:30 AM, Scott Blum <dragonsi...@gmail.com> wrote: > > Here's where I am right this second. I looked back over > commit ff8a795e61d0d44622bdbaf2144c25c70e31e864, and I think I understand > i

Re: NamespaceWatcher hashCode and equals still bugging me

Looks good to me now (fc7404585c455e33efad1df10e2086d880a7e2e9). I've had a couple of random flakes like this: Failed tests: org.apache.curator.framework.recipes.cache.TestPathChildrenCache.testKilledSession(org.apache.curator.framework.recipes.cache.TestPathChildrenCache) Run 1:

Re: [VOTE] Release Apache Curator version 2.10.0 and 3.1.0, RC2

+1 On Wed, Feb 10, 2016 at 3:30 PM, Jordan Zimmerman wrote: > Hello, > > This is a combined vote to release Apache Curator versions 2.10.0 and > 3.1.0, RC2 > > *** Please download, test and vote within approx. 72 hours > > Note that we are voting upon the source (tag) and

Re: NamespaceWatcher hashCode and equals still bugging me

urred to me that the map isn’t needed if > NamespaceWatcher could have equality/hash values the same as the Watcher > that it wraps. My testing proved this. > > Thoughts? > > -Jordan > > > > On Feb 9, 2016, at 11:49 AM, Scott Blum <dragonsi...@gmail.com> wrote

Re: [VOTE] Release Apache Curator version 2.10.0 and 3.1.0

Let me take a look tomorrow. I had no idea they were failing on 3.0. Maybe this was known-failures masking unknown-failures. On Mon, Feb 8, 2016 at 10:43 PM, Jordan Zimmerman < jor...@jordanzimmerman.com> wrote: > Should we cancel the release? Scott? > > > On Feb 8, 2016, at 10:21 PM, Cameron

Re: [VOTE] Release Apache Curator version 2.10.0 and 3.1.0

Going to -1 until we track down the TestTreeCache failures (today). Also, floated a potential issue with NamespaceWatcher under separate subject. On Tue, Feb 9, 2016 at 5:45 AM, Scott Blum <dragonsi...@gmail.com> wrote: > Let me take a look tomorrow. I had no idea they were faili

NamespaceWatcher hashCode and equals still bugging me

Hi guys, I'm a practical guy, not a purist, but the 3.0 implementations of NamespaceWatcher.hashCode() and equals() are bothering me. The reason I care is that I want to avoid subtle bugs cropping up. So here's the problem. 1) equals() is not reflexive between NamespaceWatcher and Watcher

Re: [VOTE] Release Apache Curator version 2.10.0 and 3.1.0

I want to push a commit to master, merge master into 3.0, and then push another commit into 3.0. I think this will fix TestTreeCache and also generally make that test fail faster if we write a bad test in the future. On Tue, Feb 9, 2016 at 5:55 PM, Scott Blum <dragonsi...@gmail.com> wrote

Re: [VOTE] Release Apache Curator version 2.10.0 and 3.1.0

Alright... pushed! I think this fixes things. Thanks for your patience! On Tue, Feb 9, 2016 at 6:03 PM, Jordan Zimmerman <jor...@jordanzimmerman.com > wrote: > Sounds good - go ahead. > > On Feb 9, 2016, at 6:02 PM, Scott Blum <dragonsi...@gmail.com> wrote: > &

Re: [VOTE] Release Apache Curator version 2.10.0 and 3.1.0

t; > -Jordan > > On Feb 9, 2016, at 11:51 AM, Scott Blum <dragonsi...@gmail.com> wrote: > > Actually let me clarify.. > > +1 on 2.10.0 > -1 on 3.1.0 > > On Tue, Feb 9, 2016 at 11:50 AM, Scott Blum <dragonsi...@gmail.com> wrote: > >> Going to -1 until we

Re: PLEASE REVIEW - Major re-work of Watcher wrappers

. On Sun, Feb 7, 2016 at 10:36 PM, Scott Blum <dragonsi...@gmail.com> wrote: > Oooh... let me try that. > > On Sun, Feb 7, 2016 at 8:29 PM, Jordan Zimmerman < > jor...@jordanzimmerman.com> wrote: > >> FYI - I added a new method to Timing to help with this: &g

Re: PLEASE REVIEW - Major re-work of Watcher wrappers

hat. > > -JZ > > > On Feb 8, 2016, at 12:06 PM, Scott Blum <dragonsi...@gmail.com> wrote: > > Okay, I took a look, and I couldn't see how to use > timing.forSessionSleep() in this test correctly. It's not the test harness > I'm trying to block. What I'm trying to test invo

Re: https://github.com/apache/curator/pull/131

I threw down some minor comments, sorry I don't have more context on the major pieces. That said, if all the tests are passing, that seems like a strong indicator of success! On Mon, Feb 8, 2016 at 9:50 AM, Jordan Zimmerman wrote: > I’d like to merge

[jira] [Resolved] (CURATOR-302) TestTreeCache.testKilledSession() fails in 3.0 branch

[ https://issues.apache.org/jira/browse/CURATOR-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Blum resolved CURATOR-302. Resolution: Fixed > TestTreeCache.testKilledSession() fails in 3.0 bra

Re: PLEASE REVIEW - Major re-work of Watcher wrappers

both fail here. > > -JZ > > On Feb 7, 2016, at 1:06 AM, Scott Blum <dragonsi...@gmail.com> wrote: > > I need to analyze this a bit deeper, but what I'm seeing on the 3.0 branch > is that the ephemeral node /test/me created in testKilledSession() really > isn't disap

Re: PLEASE REVIEW - Major re-work of Watcher wrappers

id change though. A change I made to ZK got added in 3.5 and > we now use that. > > -Jordan > > On Feb 7, 2016, at 1:55 PM, Scott Blum <dragonsi...@gmail.com> wrote: > > Are we using a new zookeeper? Or did something change with our > implementation of KillSession.ki

Re: PLEASE REVIEW - Major re-work of Watcher wrappers

gt; client. So, no, it’s not a real session kill like it used to be. But, now > it’s more reliable. Use timing.forSessionSleep() to wait for session > timeout. > > -JZ > > > On Feb 7, 2016, at 8:21 PM, Scott Blum <dragonsi...@gmail.com> wrote: > > Can you describe

[jira] [Created] (CURATOR-302) TestTreeCache.testKilledSession() fails in 3.0 branch

Scott Blum created CURATOR-302: -- Summary: TestTreeCache.testKilledSession() fails in 3.0 branch Key: CURATOR-302 URL: https://issues.apache.org/jira/browse/CURATOR-302 Project: Apache Curator

Re: PLEASE REVIEW - Major re-work of Watcher wrappers

a node. Any idea why the timing here would have changed? On Sat, Feb 6, 2016 at 1:41 PM, Scott Blum <dragonsi...@gmail.com> wrote: > https://issues.apache.org/jira/browse/CURATOR-302 > > I need to trace through what's really going on under the hood rather than > band-aid the tes

Re: Can't merge master into 3.0

t.watches().remove(this).ofType(WatcherType.Any).locally().inBackground().forPath(path); > > I believe this is unnecessary as the WatcherRemoveCuratorFramework handles > it automatically. If I remove this line the log errors go away. > > -Jordan > > On Feb 3, 2016, at 7:45 PM, S

Re: Can't merge master into 3.0

Yes, I confirmed this works on your watcher rework branch. (Nothing I was able to hack on CURATOR-3.0 would make it pass, probably due to collection element equality/hashcode issues with wrapping in a spot I wasn't able to find.) On Fri, Feb 5, 2016 at 11:31 AM, Scott Blum <dragonsi...@gmail.

Re: PLEASE REVIEW - Major re-work of Watcher wrappers

;data".getBytes()); > assertEvent(TreeCacheEvent.Type.INITIALIZED); > > This fails. But, if I switch them it works: > > assertEvent(TreeCacheEvent.Type.INITIALIZED); > > assertEvent(TreeCacheEvent.Type.NODE_REMOVED, "/test/me", "data".getBytes()); > > On

Re: PLEASE REVIEW - Major re-work of Watcher wrappers

e in Jira for this. > > -Jordan > > On Feb 5, 2016, at 12:24 PM, Scott Blum <dragonsi...@gmail.com> wrote: > > BTW: this is broken on CURATOR-3.0 as well, so it appears to have been > broken for a while. Maybe I'll have to git bisect... > > On Fri, Feb 5, 2016 at 1

Re: PLEASE REVIEW - Major re-work of Watcher wrappers

in how background events are getting sent to TreeCache, and I don't really understand it yet. And running the debugger seems to affect the timing, like something racy is going on. :( On Fri, Feb 5, 2016 at 11:57 AM, Scott Blum <dragonsi...@gmail.com> wrote: > Ok, that is kind of weird. I

Re: PLEASE REVIEW - Major re-work of Watcher wrappers

BTW: this is broken on CURATOR-3.0 as well, so it appears to have been broken for a while. Maybe I'll have to git bisect... On Fri, Feb 5, 2016 at 12:22 PM, Scott Blum <dragonsi...@gmail.com> wrote: > Okay, so I looked into this for a bit, and I hit kind of a wall. I think > ther

Re: PLEASE REVIEW - Major re-work of Watcher wrappers

So you end up with 2 initialized events? You mean this? assertEvent(TreeCacheEvent.Type.CONNECTION_RECONNECTED); +assertEvent(TreeCacheEvent.Type.INITIALIZED); assertEvent(TreeCacheEvent.Type.NODE_REMOVED, "/test/me", "data".getBytes());

Re: Can't merge master into 3.0

> > -Jordan > > On Feb 1, 2016, at 3:14 PM, Scott Blum <dragonsi...@gmail.com> wrote: > > Alright, I've git bisected it down to a single change that breaks > TestTreeCache: > > WatcherRemovalManager.internalRemove, > > private sy

[jira] [Commented] (CURATOR-296) Notify cache listeners when re-init completes after reconnect

[ https://issues.apache.org/jira/browse/CURATOR-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15126850#comment-15126850 ] Scott Blum commented on CURATOR-296: [~cammckenzie] gave me an LGTM so I went ahead and merged what I

Re: Can't merge master into 3.0

to be the namespaceWatcherMap.removeWatcher. If I comment out that line, TestTreeCache passes. On Mon, Feb 1, 2016 at 3:05 PM, Scott Blum <dragonsi...@gmail.com> wrote: > I think there may be some general problem, I notice warning messages in > the test logs, lik

Re: Can't merge master into 3.0

ing to write a JIra for it today. > > On Feb 1, 2016, at 3:05 PM, Scott Blum <dragonsi...@gmail.com> wrote: > > I think there may be some general problem, I notice warning messages in > the test logs, like: > > ERROR org.apache.zookeeper.ClientCnxn Failed to fi

[jira] [Resolved] (CURATOR-296) Notify cache listeners when re-init completes after reconnect

[ https://issues.apache.org/jira/browse/CURATOR-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Blum resolved CURATOR-296. Resolution: Fixed Fix Version/s: 2.9.2 3.0.1 > Notify cache listen

Re: Can't merge master into 3.0

at org.apache.zookeeper.ZooKeeper$ZKWatchManager.containsWatcher(ZooKeeper.java:377) at org.apache.zookeeper.ZooKeeper$ZKWatchManager.removeWatcher(ZooKeeper.java:252) at org.apache.zookeeper.WatchDeregistration.unregister(WatchDeregistration.java:58) On Mon, Feb 1, 2016 at 3:04 PM, Scott Blum

Re: Can't merge master into 3.0

:46 PM, Jordan Zimmerman <jor...@jordanzimmerman.com > wrote: > I can try to merge when I get a chance. At some point, we should move > CURATOR-3.0 to master so we don’t have to keep maintaining this. > > -JZ > > On Feb 1, 2016, at 2:38 PM, Scott Blum <d

Re: Can't merge master into 3.0

I went ahead and pushed CURATOR-3.0 since the the new code doesn't make anything worse and the bug already existed. On Mon, Feb 1, 2016 at 3:15 PM, Scott Blum <dragonsi...@gmail.com> wrote: > BTW, I'd be happy to dig into this more, but I'd need a "theory of >

[jira] [Assigned] (CURATOR-296) Notify cache listeners when re-init completes after reconnect

[ https://issues.apache.org/jira/browse/CURATOR-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Blum reassigned CURATOR-296: -- Assignee: Scott Blum > Notify cache listeners when re-init completes after reconn

Can't merge master into 3.0

TestTreeCache fails on 6acf0987125469ecb79ff48ce5e9735a98cd1abb , a proposed merge of master into 3.0. It has something to do with the new watcher stuff, but I haven't been able to figure out what the problem is, possible because I

[jira] [Resolved] (CURATOR-294) Optimize TreeCache, fix possible concurrency issue

[ https://issues.apache.org/jira/browse/CURATOR-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Blum resolved CURATOR-294. Resolution: Fixed > Optimize TreeCache, fix possible concurrency is

[jira] [Commented] (CURATOR-294) Optimize TreeCache, fix possible concurrency issue

[ https://issues.apache.org/jira/browse/CURATOR-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15124698#comment-15124698 ] Scott Blum commented on CURATOR-294: Re-spun the PR per [~nickhill] suggestions. > Optim

[jira] [Commented] (CURATOR-294) Optimize TreeCache, fix possible concurrency issue

[ https://issues.apache.org/jira/browse/CURATOR-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15123940#comment-15123940 ] Scott Blum commented on CURATOR-294: Great idea! > Optimize TreeCache, fix possible concurre

[jira] [Created] (CURATOR-294) Optimize TreeCache, fix possible concurrency issue

Scott Blum created CURATOR-294: -- Summary: Optimize TreeCache, fix possible concurrency issue Key: CURATOR-294 URL: https://issues.apache.org/jira/browse/CURATOR-294 Project: Apache Curator

[jira] [Commented] (CURATOR-294) Optimize TreeCache, fix possible concurrency issue

[ https://issues.apache.org/jira/browse/CURATOR-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121851#comment-15121851 ] Scott Blum commented on CURATOR-294: Nick, Looking at this closer, I see your point

[jira] [Commented] (CURATOR-294) Optimize TreeCache, fix possible concurrency issue

[ https://issues.apache.org/jira/browse/CURATOR-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121849#comment-15121849 ] Scott Blum commented on CURATOR-294: It just seems that not guaranteeing consistency of the stat

[jira] [Comment Edited] (CURATOR-294) Optimize TreeCache, fix possible concurrency issue

[ https://issues.apache.org/jira/browse/CURATOR-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15122155#comment-15122155 ] Scott Blum edited comment on CURATOR-294 at 1/28/16 7:28 PM: - [~randgalt

[jira] [Commented] (CURATOR-294) Optimize TreeCache, fix possible concurrency issue

[ https://issues.apache.org/jira/browse/CURATOR-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15122155#comment-15122155 ] Scott Blum commented on CURATOR-294: [~randgalt] I pushed a branch, would you mind reviewing

Re: TreeCache question

gt; > Ignoring the less-important suggestion for simplifying ChildData itself, > wouldn't there still be significant value in a simple change to move the > TreeNode data and stat atomic refs into a single ChildData atomic ref? > > Cheers, > Nick > > > Quoting Scott Blum &

Re: TreeCache question

HI Nick, TreeCache came later, and literally the only reason for reusing ChildData was to not create additional API surface area, and make for an easier transition / drop-in replacement for NodeCache & PathChildrenCache. Ordinarily, I'm a big fan of immutable objects. I'm not aware of any

Re: TreeCache wasDeleted()

It looks like the history has gotten super gnarly, so it's hard to track code provenance. But the call to client.clearWatcherReferences(this) has always been there. It's important for long running TreeCaches to be able to clear dead watchers as they go. On Mon, Jan 18, 2016 at 2:09 PM, Jordan

Re: TreeCache wasDeleted()

ving ONLY client > side > > watches. You can set a flag indicating that if the call to the server > fails > > that the client side watches should still be removed. > > > > On Tue, Jan 19, 2016 at 8:10 AM, Scott Blum <dragonsi...@gmail.com> > wrote: > > >

TreeCacheSelector

We should document that TreeCacheSelector implementations need to return stable answers over time. A Selector that returns different answers over time is specifically not supported, and will yield very inconsistent results. (This is why I didn't originally try to tackle this, but on the net I

Re: TreeCacheSelector

(Be happy to patch it myself, but I'm not sure what branch to commit to) On Mon, Jan 18, 2016 at 5:01 PM, Scott Blum <dragonsi...@gmail.com> wrote: > We should document that TreeCacheSelector implementations need to return > stable answers over time. A Selector that returns diffe

Re: [VOTE] Release Apache Curator version 2.9.1

No concerns! Just slammed right now with work so I'm not able to really evaluate. I trust you all. On Oct 29, 2015 8:42 AM, "Jordan Zimmerman" <jor...@jordanzimmerman.com> wrote: > Any reason why +0? Do you have some concerns? > > -JZ > > > On Oct 29, 2015,

Re: [VOTE] Release Apache Curator version 2.9.1

gt; > On Oct 29, 2015, at 12:05 PM, Scott Blum <dragonsi...@gmail.com> wrote: > > No concerns! Just slammed right now with work so I'm not able to really > evaluate. I trust you all. > On Oct 29, 2015 8:42 AM, "Jordan Zimmerman" <jor...@jordanzimmerman.com>

  1   2   >