I've had a bit of a look at it and the test seems very fragile. It already has a bit of built in margin for error, but it relies on the consumers being able to consume messages off the queue faster than they are produced. If more than 20 messages end up on the queue at any time then test test fails.
Anyway, I will raise a JIRA and we can discuss there. On Wed, Aug 26, 2015 at 9:29 AM, Cameron McKenzie <[email protected]> wrote: > Thanks Mike, > On master. I'll have a bit of a look into it and let you know. I think > that it's a race condition based on how the test is structured. > cheers > > On Wed, Aug 26, 2015 at 9:18 AM, Mike Drob <[email protected]> wrote: > >> Is this on 3.0 or master? Can you create a JIRA with some log output? >> >> On Tue, Aug 25, 2015 at 6:15 PM, Cameron McKenzie <[email protected] >> > >> wrote: >> >> > Is anyone seeing fairly consistent failure of the >> > >> > TestBoundedDistributedQueue.testMulti:184 >> > >> > test? When I run from inside eclipse in isolation it seems ok, but >> running >> > a 'mvn test' seems to fail on this test with some consistency. The >> changes >> > for CURATOR-167 certainly haven't caused this to happen. >> > cheers >> > >> > On Wed, Aug 26, 2015 at 7:45 AM, Cameron McKenzie < >> [email protected]> >> > wrote: >> > >> > > Thanks Scott, >> > > I will merge into master. >> > > cheers >> > > >> > > On Wed, Aug 26, 2015 at 1:00 AM, Scott Blum <[email protected]> >> > wrote: >> > > >> > >> Yep, that looks perfect. Is CURATOR-167 done? If so, we can just >> > >> fast-foward merge it into master now. >> > >> >> > >> On Tue, Aug 25, 2015 at 12:11 AM, Cameron McKenzie < >> > >> [email protected]> >> > >> wrote: >> > >> >> > >> > Thanks Scott, >> > >> > Done, would you mind checking the origin/CURATOR-167 to make sure >> > that I >> > >> > haven't done anything wrong! I have done a git pull on a different >> > >> machine >> > >> > and it seems to be ok. >> > >> > cheers >> > >> > >> > >> > On Tue, Aug 25, 2015 at 1:49 PM, Scott Blum <[email protected] >> > >> > >> wrote: >> > >> > >> > >> > > You just force push your branch. >> > >> > > >> > >> > > If it's your feature branch, and you know you have it in a good >> > state >> > >> > > locally, you can just force push the remote branch into the same >> > >> state. >> > >> > > >> > >> > > You'd never want to do that to master, a release branch, or >> someone >> > >> > else's >> > >> > > branch. >> > >> > > On Aug 24, 2015 11:15 PM, "Cameron McKenzie" < >> > [email protected]> >> > >> > > wrote: >> > >> > > >> > >> > > > Thanks Mike, >> > >> > > > That was a good description. The CURATOR-167 branch is >> definitely >> > >> there >> > >> > > as >> > >> > > > it's been a pull request for the last few months. So, I'll >> await >> > >> your >> > >> > > > thoughts in the morning. Alternatively, I can just merge master >> > >> instead >> > >> > > of >> > >> > > > rebasing it. >> > >> > > > >> > >> > > > On Tue, Aug 25, 2015 at 1:00 PM, Mike Drob < >> [email protected]> >> > >> > wrote: >> > >> > > > >> > >> > > > > Yea, that's the big downside with rebasing, is that remotes >> > don't >> > >> > > exactly >> > >> > > > > keep up with the history. I'm going to try to explain this as >> > best >> > >> > as I >> > >> > > > > can, but usually I point people towards this excellent "Git >> for >> > >> Ages >> > >> > 4 >> > >> > > > and >> > >> > > > > Up" video https://www.youtube.com/watch?v=1ffBJ4sVUb4 - he >> > talks >> > >> > about >> > >> > > > > rebases at the very very end, around the 1:30 mark. >> > >> > > > > >> > >> > > > > Essentially, your current version of the branch does not have >> > the >> > >> > > remote >> > >> > > > > version of the as an ancestor. Which is correct, when you did >> > the >> > >> > > rebase, >> > >> > > > > you wrote a new commit lineage. >> > >> > > > > >> > >> > > > > I didn't realize that there was already a CURATOR-167 branch >> > >> pushed >> > >> > to >> > >> > > > the >> > >> > > > > repo when I gave you those steps. I'll have to look at what's >> > >> going >> > >> > on >> > >> > > > with >> > >> > > > > a fresh set of eyes in the morning. >> > >> > > > > >> > >> > > > > On Mon, Aug 24, 2015 at 8:37 PM, Cameron McKenzie < >> > >> > > > [email protected]> >> > >> > > > > wrote: >> > >> > > > > >> > >> > > > > > I just tried this and obviously I'm doing something wrong. >> > >> > > > > > >> > >> > > > > > git checkout CURATOR-167 >> > >> > > > > > git pull >> > >> > > > > > git rebase -i origin/master >> > >> > > > > > >> > >> > > > > > #This gives me a dialog with one commit with pick >> > >> > > > > > Save and exit >> > >> > > > > > #This gives a merge conflict and leaves me in a detached >> head >> > >> state >> > >> > > (I >> > >> > > > > > presume this is ok). >> > >> > > > > > Fix up the merge conflict >> > >> > > > > > git rebase --continue >> > >> > > > > > #This gives me a dialog to commit the changes >> > >> > > > > > Save and exit >> > >> > > > > > #Everything seems fine at this point. Builds ok, tests run >> ok. >> > >> > > > > > >> > >> > > > > > git push >> > >> > > > > > >> > >> > > > > > ! [rejected] CURATOR-167 -> CURATOR-167 >> > >> (non-fast-forward) >> > >> > > > > > error: failed to push some refs to ' >> > >> > > > > > https://git-wip-us.apache.org/repos/asf/curator.git' >> > >> > > > > > hint: Updates were rejected because the tip of your current >> > >> branch >> > >> > is >> > >> > > > > > behind >> > >> > > > > > hint: its remote counterpart. Integrate the remote changes >> > (e.g. >> > >> > > > > > hint: 'git pull ...') before pushing again. >> > >> > > > > > hint: See the 'Note about fast-forwards' in 'git push >> --help' >> > >> for >> > >> > > > > details. >> > >> > > > > > >> > >> > > > > > There have been no changes on the branch since I did the >> pull >> > >> > before >> > >> > > > the >> > >> > > > > > rebase. >> > >> > > > > > >> > >> > > > > > Any ideas? >> > >> > > > > > >> > >> > > > > > >> > >> > > > > > >> > >> > > > > > >> > >> > > > > > >> > >> > > > > > >> > >> > > > > > On Tue, Aug 25, 2015 at 8:48 AM, Cameron McKenzie < >> > >> > > > > [email protected]> >> > >> > > > > > wrote: >> > >> > > > > > >> > >> > > > > > > Thanks Mike, >> > >> > > > > > > Will give it a spin today some time. >> > >> > > > > > > cheers >> > >> > > > > > > >> > >> > > > > > > On Tue, Aug 25, 2015 at 8:36 AM, Mike Drob < >> > >> [email protected]> >> > >> > > > > wrote: >> > >> > > > > > > >> > >> > > > > > >> if you're going to tray that, here's what you want to do >> > >> > (assuming >> > >> > > > > > command >> > >> > > > > > >> line) >> > >> > > > > > >> >> > >> > > > > > >> git checkout CURATOR-167 # start with the branch that >> you >> > are >> > >> > > > changing >> > >> > > > > > >> git rebase -i master # rebase the current branch on top >> of >> > >> the >> > >> > > given >> > >> > > > > > >> branch >> > >> > > > > > >> >> > >> > > > > > >> On Mon, Aug 24, 2015 at 5:07 PM, Cameron McKenzie < >> > >> > > > > > [email protected] >> > >> > > > > > >> > >> > >> > > > > > >> wrote: >> > >> > > > > > >> >> > >> > > > > > >> > Scott, >> > >> > > > > > >> > I've been using a similar approach to Jordan given >> that's >> > >> what >> > >> > > I'm >> > >> > > > > > used >> > >> > > > > > >> to, >> > >> > > > > > >> > but I'm happy to try your approach. I'm going to try >> and >> > >> fix >> > >> > up >> > >> > > > > > >> CURATOR-167 >> > >> > > > > > >> > as it will no longer cleanly merge (it's been sitting >> > >> there a >> > >> > > > > while). >> > >> > > > > > >> So, I >> > >> > > > > > >> > should rebase master into the CURATOR-167 branch? >> > >> > > > > > >> > cheers >> > >> > > > > > >> > >> > >> > > > > > >> > On Tue, Aug 25, 2015 at 2:55 AM, Scott Blum < >> > >> > > > [email protected] >> > >> > > > > > >> > >> > > > > > >> > wrote: >> > >> > > > > > >> > >> > >> > > > > > >> > > LOL! So sorry to hear that. Yeah, it's definitely >> > >> possible >> > >> > > to >> > >> > > > > mess >> > >> > > > > > >> > > things up badly. If I'm doing something >> particularly >> > >> risky, >> > >> > > > I'll >> > >> > > > > > just >> > >> > > > > > >> > "git >> > >> > > > > > >> > > branch original" before I start, so as to leave a >> > branch >> > >> > > pointer >> > >> > > > > at >> > >> > > > > > my >> > >> > > > > > >> > > start point as a safe recovery if it goes south. I >> > also >> > >> use >> > >> > > > gitk >> > >> > > > > to >> > >> > > > > > >> > > visualize sometimes. >> > >> > > > > > >> > > >> > >> > > > > > >> > > Another major selling point for rebase (-i) is that >> > it's >> > >> > > > *really* >> > >> > > > > > >> hard to >> > >> > > > > > >> > > merge the wrong branch. If the list of commits that >> > >> comes >> > >> > up >> > >> > > > > > doesn't >> > >> > > > > > >> > look >> > >> > > > > > >> > > basically correct, you probably did something >> wrong-- >> > >> trying >> > >> > > to >> > >> > > > > > rebase >> > >> > > > > > >> > onto >> > >> > > > > > >> > > the wrong branch will give you tons of commits, >> most of >> > >> > which >> > >> > > > > aren't >> > >> > > > > > >> > yours. >> > >> > > > > > >> > > >> > >> > > > > > >> > > I think what you've been doing is fine, it's >> definitely >> > >> the >> > >> > > > right >> > >> > > > > > >> > approach >> > >> > > > > > >> > > if you're doing a merge strategy! I've just ended >> up >> > >> > > > gravitating >> > >> > > > > > to a >> > >> > > > > > >> > > rebase strategy over the years for the reasons I've >> > >> > mentioned. >> > >> > > > > > >> > > >> > >> > > > > > >> > > On Mon, Aug 24, 2015 at 12:43 PM, Jordan Zimmerman < >> > >> > > > > > >> > > [email protected]> wrote: >> > >> > > > > > >> > > >> > >> > > > > > >> > >> I’ll admit that rebase terrifies me. I’ve f’d up >> > several >> > >> > > > projects >> > >> > > > > > >> with >> > >> > > > > > >> > it >> > >> > > > > > >> > >> so I can’t even type the letters without breaking >> > into a >> > >> > > sweat. >> > >> > > > > > "git >> > >> > > > > > >> > rebase >> > >> > > > > > >> > >> -i” is a lot safer, though. Here’s what I’ve been >> > doing >> > >> - >> > >> > let >> > >> > > > me >> > >> > > > > > >> know if >> > >> > > > > > >> > >> it’s OK. For branches that are off of CURATOR-3.0, >> I >> > >> never >> > >> > > > merge >> > >> > > > > > >> > master. I >> > >> > > > > > >> > >> only merge CURATOR-3.0: “git merge CURATOR-3.0”. In >> > >> fact, >> > >> > > > should >> > >> > > > > we >> > >> > > > > > >> > have a >> > >> > > > > > >> > >> branch naming scheme to enforce this? >> > >> > > > > > >> > >> >> > >> > > > > > >> > >> -Jordan >> > >> > > > > > >> > >> >> > >> > > > > > >> > >> >> > >> > > > > > >> > >> >> > >> > > > > > >> > >> On August 24, 2015 at 11:30:50 AM, Scott Blum ( >> > >> > > > > > >> [email protected]) >> > >> > > > > > >> > >> wrote: >> > >> > > > > > >> > >> >> > >> > > > > > >> > >> Correct. When I say "main" branch vs. "feature" >> > branch I >> > >> > just >> > >> > > > > mean >> > >> > > > > > >> the >> > >> > > > > > >> > >> stable branch everyone is working against (3.0 or >> > >> master) >> > >> > > vs. a >> > >> > > > > > >> feature >> > >> > > > > > >> > >> branch where you're actively working. >> > >> > > > > > >> > >> >> > >> > > > > > >> > >> You'll get to a point in development where you'll >> > think >> > >> > "Hey, >> > >> > > > > there >> > >> > > > > > >> are >> > >> > > > > > >> > >> changes on the main branch I'm working against >> that I >> > >> > really >> > >> > > > need >> > >> > > > > > to >> > >> > > > > > >> > pull >> > >> > > > > > >> > >> into my feature branch." At that point >> (particularly >> > if >> > >> you >> > >> > > > have >> > >> > > > > an >> > >> > > > > > >> svn >> > >> > > > > > >> > >> background) you'll be tempted to merge the main >> branch >> > >> into >> > >> > > > your >> > >> > > > > > >> feature >> > >> > > > > > >> > >> branch. I would suggest not doing that, as it makes >> > the >> > >> > > history >> > >> > > > > > very >> > >> > > > > > >> > muddy >> > >> > > > > > >> > >> to follow. Instead, my workflow is usually more >> like >> > >> this: >> > >> > > > > > >> > >> >> > >> > > > > > >> > >> Suppose I'm working on CURATOR-218. It was >> originally >> > >> > > branched >> > >> > > > > off >> > >> > > > > > >> 3.0, >> > >> > > > > > >> > >> and I want to pull in new changes. >> > >> > > > > > >> > >> >> > >> > > > > > >> > >> git remote update >> > >> > > > > > >> > >> git rebase -i origin/CURATOR-3.0 >> > >> > > > > > >> > >> >> > >> > > > > > >> > >> This pulls up an editor that gives me the list of >> > >> commits >> > >> > to >> > >> > > > > > rebase. >> > >> > > > > > >> I >> > >> > > > > > >> > >> would typically exit out of the editor to at this >> > point >> > >> to >> > >> > > > accept >> > >> > > > > > the >> > >> > > > > > >> > >> commit list, but if I'm so inclined, I'll do things >> > like >> > >> > > > reorder >> > >> > > > > > the >> > >> > > > > > >> > list, >> > >> > > > > > >> > >> or squash commits like like "wip" or "minor >> reformat" >> > >> into >> > >> > a >> > >> > > > more >> > >> > > > > > >> > curated >> > >> > > > > > >> > >> set of logical commits. >> > >> > > > > > >> > >> >> > >> > > > > > >> > >> Once you exit the editor, git goes through and >> applies >> > >> each >> > >> > > > > commit, >> > >> > > > > > >> one >> > >> > > > > > >> > at >> > >> > > > > > >> > >> a time, to the head of the target branch. It's like >> > >> picking >> > >> > > up >> > >> > > > > your >> > >> > > > > > >> > commit >> > >> > > > > > >> > >> chain and dumping it at the end of the target >> branch, >> > >> as if >> > >> > > all >> > >> > > > > > your >> > >> > > > > > >> > work >> > >> > > > > > >> > >> had been done against what's now the head of that >> > >> branch. >> > >> > > > You'll >> > >> > > > > > may >> > >> > > > > > >> > have >> > >> > > > > > >> > >> to fix conflicts along the way, but usually not >> much >> > >> more >> > >> > > than >> > >> > > > if >> > >> > > > > > you >> > >> > > > > > >> > did >> > >> > > > > > >> > >> it as a merge. >> > >> > > > > > >> > >> >> > >> > > > > > >> > >> I'd encourage us to try this out a couple times and >> > get >> > >> a >> > >> > > feel >> > >> > > > > for >> > >> > > > > > >> the >> > >> > > > > > >> > >> rebase flow. It's a little more to get your head >> > around >> > >> at >> > >> > > > first, >> > >> > > > > > but >> > >> > > > > > >> > the >> > >> > > > > > >> > >> upside is you end up with really easy to follow >> commit >> > >> > > > histories, >> > >> > > > > > >> which >> > >> > > > > > >> > >> makes it way easier to untangle problems later if >> they >> > >> crop >> > >> > > up. >> > >> > > > > > >> > >> >> > >> > > > > > >> > >> On Mon, Aug 24, 2015 at 12:17 PM, Jordan Zimmerman >> < >> > >> > > > > > >> > >> [email protected]> wrote: >> > >> > > > > > >> > >> >> > >> > > > > > >> > >> > Can you explain this in detail? For me, I have >> some >> > >> > > features >> > >> > > > > that >> > >> > > > > > >> are >> > >> > > > > > >> > >> > 3.0.0 based so I’m treating CURATOR-3.0 as a >> kind of >> > >> > > master. >> > >> > > > > The >> > >> > > > > > >> true >> > >> > > > > > >> > >> > “master” is Curator 2.x only, right? >> > >> > > > > > >> > >> > >> > >> > > > > > >> > >> > -Jordan >> > >> > > > > > >> > >> > >> > >> > > > > > >> > >> > >> > >> > > > > > >> > >> > >> > >> > > > > > >> > >> > On August 24, 2015 at 11:10:08 AM, Scott Blum ( >> > >> > > > > > >> [email protected] >> > >> > > > > > >> > ) >> > >> > > > > > >> > >> > wrote: >> > >> > > > > > >> > >> > >> > >> > > > > > >> > >> > BTW: I noticed a couple of new commits >> > >> > > > > > >> > >> > (ba4b5d8cb1f9733d3901b0b619528454d3dbf8c8 >> > >> > > > > > >> > >> > & 2343daf29388566b0efa0b0a2ad21574fb534a27) where >> > 3.0 >> > >> is >> > >> > > > > getting >> > >> > > > > > >> > merged >> > >> > > > > > >> > >> > into feature branches. Almost every project I've >> > been >> > >> on >> > >> > we >> > >> > > > > don't >> > >> > > > > > >> tend >> > >> > > > > > >> > >> to >> > >> > > > > > >> > >> > do that as it leads to confusing history (this >> isn't >> > >> just >> > >> > > > > > >> aesthetic, >> > >> > > > > > >> > it >> > >> > > > > > >> > >> > can >> > >> > > > > > >> > >> > get harder for tooling to figure out what >> happened). >> > >> If I >> > >> > > > want >> > >> > > > > to >> > >> > > > > > >> pull >> > >> > > > > > >> > >> > changes from the main branch into my feature >> > branch, I >> > >> > > would >> > >> > > > > > >> typically >> > >> > > > > > >> > >> > *rebase* my feature branch against the main >> branch. >> > >> > > > > > >> > >> > >> > >> > > > > > >> > >> > On Mon, Aug 24, 2015 at 12:05 PM, Scott Blum < >> > >> > > > > > >> [email protected]> >> > >> > > > > > >> > >> > wrote: >> > >> > > > > > >> > >> > >> > >> > > > > > >> > >> > > Yeah, 217 & 161 were the first two big things >> in >> > >> 3.0. >> > >> > > > > > >> > >> > > >> > >> > > > > > >> > >> > > On Mon, Aug 24, 2015 at 9:53 AM, Jordan >> Zimmerman >> > < >> > >> > > > > > >> > >> > > [email protected]> wrote: >> > >> > > > > > >> > >> > > >> > >> > > > > > >> > >> > >> OK - Also, is CURATOR-161 complete? The issue >> is >> > >> still >> > >> > > > open >> > >> > > > > in >> > >> > > > > > >> > Jira. >> > >> > > > > > >> > >> > >> >> > >> > > > > > >> > >> > >> >> > >> > > > > > >> > >> > >> >> > >> > > > > > >> > >> > >> On August 24, 2015 at 12:47:21 AM, Cameron >> > >> McKenzie ( >> > >> > > > > > >> > >> > >> [email protected]) wrote: >> > >> > > > > > >> > >> > >> >> > >> > > > > > >> > >> > >> Yes, I merged it in last week some time. >> > >> > > > > > >> > >> > >> >> > >> > > > > > >> > >> > >> On Mon, Aug 24, 2015 at 3:25 PM, Jordan >> > Zimmerman < >> > >> > > > > > >> > >> > >> [email protected]> wrote: >> > >> > > > > > >> > >> > >> >> > >> > > > > > >> > >> > >> > Scott, did CURATOR-217 get merged into the >> new >> > >> > > > > CURATOR-3.0? >> > >> > > > > > >> > >> > >> > >> > >> > > > > > >> > >> > >> > -Jordan >> > >> > > > > > >> > >> > >> > >> > >> > > > > > >> > >> > >> > >> > >> > > > > > >> > >> > >> > >> > >> > > > > > >> > >> > >> >> > >> > > > > > >> > >> > > >> > >> > > > > > >> > >> > > >> > >> > > > > > >> > >> > >> > >> > > > > > >> > >> > >> > >> > > > > > >> > >> >> > >> > > > > > >> > > >> > >> > > > > > >> > > >> > >> > > > > > >> > >> > >> > > > > > >> >> > >> > > > > > > >> > >> > > > > > > >> > >> > > > > > >> > >> > > > > >> > >> > > > >> > >> > > >> > >> > >> > >> >> > > >> > > >> > >> > >
