For Docker, I was running into the OOME, but then I bumped up the container/virtualbox memory to 4 GB (default is 2 GB) and it works fine.
-- Jason On Sun, Nov 6, 2016 at 6:37 PM, Stephen Mallette <[email protected]> wrote: > That stinks. Never got OOME with docker. Any other kinds of issues you can > recall or is it pretty much just that? > > On Nov 6, 2016 5:43 PM, "Robert Dale" <[email protected]> wrote: > > > One day I'll figure out why docker always fails for me. It's usually > > around some java.lang.OutOfMemoryError: unable to create new native > > thread. Usually happens in tinkergraph-gremlin. Sometimes it makes it to > > spark or hadoop, but inevitably fails miserably there. Tried latest > master > > and TINKERPOP-1434 but no joy. Even rebuilt docker containers from > scratch. > > > > Robert Dale > > > > On Fri, Oct 28, 2016 at 6:22 PM, Stephen Mallette <[email protected]> > > wrote: > > > > > That's probably fair. Perhaps that's a good rule. At least one person > > > should use CPU to do the docker build and mention that on the PR as > part > > of > > > their VOTE. I also suppose some PRs won't even need the docker run at > > all. > > > We can just use some common sense with that "rule". > > > > > > On Fri, Oct 28, 2016 at 5:29 PM, Daniel Kuppitz <[email protected]> > wrote: > > > > > > > Talking about sparing CPU cycles: docker/build.sh -t -i -n takes > time, > > > lots > > > > of time. I used to run it regardless of whether somebody else already > > did > > > > it or not. I won't do that anymore and instead rely on idempotent > > results > > > > (in the end that's why we originally created the Docker containers). > > > Hence, > > > > if anybody already ran the full build, I will only look through the > > code > > > > changes and if they look good to me - VOTE: +1. > > > > > > > > Cheers, > > > > Daniel > > > > > > > > > > > > On Fri, Oct 28, 2016 at 9:28 PM, Stephen Mallette < > > [email protected]> > > > > wrote: > > > > > > > > > We're backing up pretty heavily on pull request reviews/votes. > > > > > > > > > > https://github.com/apache/tinkerpop/pulls > > > > > > > > > > Can any committers help us along with some reviews/votes? > > > > > > > > > > Remember - you don't need to have full knowledge of the code to > > > > participate > > > > > in a code review. If the code comes from a core contributor (e.g. > > marko > > > > > submitting a gremlin-spark bug fix), you mostly need to focus on > the > > > big > > > > > picture and generalities of the change and then do a "mvn clean > > > install" > > > > or > > > > > better yet "docker.build.sh -t -i -n". If it all works then "VOTE > > +1". > > > > > > > > > > Most pull requests for review are super simple, like this one: > > > > > > > > > > https://github.com/apache/tinkerpop/pull/465 (removed deprecated > > > > classes) > > > > > > > > > > All you need to do is check if the classes are gone, if upgrade > docs > > > are > > > > > updated and if the thing builds...done. VOTE +1. > > > > > > > > > > Doing reviews is a huge help to the project (even for those who are > > not > > > > > committers and don't have binding votes, as it is a great way to > get > > > > > visibility in the project and learn more about how it works). It > > would > > > be > > > > > great if folks could make a habit of sparing a few CPU cycles for > > > > TinkerPop > > > > > at the end of a work day or while you sleep so that we can continue > > to > > > > stay > > > > > agile in our development. > > > > > > > > > > Thanks > > > > > > > > > > > > > > >
