Presubmit checks in github
Hello, Looks like currently we don't automatically run any check when a new pull request is created on github. It could be as simple as https://github.com/criteo-forks/cassandra/blob/cassandra-3.11-criteo/.travis.yml (minus the release part) I guess circleci could be used too since apparently it's already used for some things. Thoughs ? -- Corentin Chary http://xf.iksaif.net - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Presubmit checks in github
At one point we tested with a travis config very similar to what circle does (run all the unit tests, etc). The free options for Travis can’t run the basic unit test suite reliably, where circle could, so we put the circle yaml in - no reason we can’t ADD Travis as well The ASF has a paid Travis account so we can get some basic builds and badges on pull request, but I’m not convinced we’ll ever get reliable unit test runs based on conversations with their (Travis) sales team, so the Travis badges wouldn’t really be meaningful. Some of us are actively working on making this less friction for contributors (by making test builds trigger on pull requests), but it takes time to get all that sorted out. -- Jeff Jirsa > On Sep 20, 2017, at 5:38 AM, Corentin Chary wrote: > > Hello, > Looks like currently we don't automatically run any check when a new > pull request is created on github. > > It could be as simple as > https://github.com/criteo-forks/cassandra/blob/cassandra-3.11-criteo/.travis.yml > (minus the release part) > > I guess circleci could be used too since apparently it's already used > for some things. > > Thoughs ? > > -- > Corentin Chary > http://xf.iksaif.net > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
The future: Java 9 and the disappearance of CLASSPATH
We're very new to Cassandra. We implement org.apache.index.Indexdropping a JAR containing our custom-index service into Cassandra's /lib/ subdirectory because this subdirectory is on the classpath. It's early days yet, but I thought I'd ask about the plans for Java 9 given that Jigsaw sort of closes the door on classpath (though it doesn't shut and lock it absolutely). What are Cassandra's plans in this direction? Do I have anything to fear long-term? Given the importance of Stratio's Lucene index extension, which uses this mechanism too, I'd guess no one wants to do anything that would destroy that either, but I need to ask. Many thanks, Russ
reclaim after memtable flush
Hi, I'm trying to understand how Regions are being allocated and deallocated in Memtable. I can see that the same region is being used to allocate more size until the max region limit is hit. However, once the max limit is reached, the current region is set to null and eventually new Region gets allocated. My question is if it possible for this filled region (which can be set to null) to have some valid data (from current memtable) which hasn't been flushed yet? How each memtable is mapped to these regions? Thanks, Preetika
Re: The future: Java 9 and the disappearance of CLASSPATH
There are several other components that function similarly (compaction strategies, snitches, UDFs, etc.). I don't see us doing anything different without a compelling reason. On Thu, Sep 21, 2017 at 3:06 AM, Russell Bateman wrote: > We're very new to Cassandra. > > We implement org.apache.index.Indexdropping a JAR containing our > custom-index service into Cassandra's /lib/ subdirectory because this > subdirectory is on the classpath. It's early days yet, but I thought I'd ask > about the plans for Java 9 given that Jigsaw sort of closes the door on > classpath (though it doesn't shut and lock it absolutely). > > What are Cassandra's plans in this direction? Do I have anything to fear > long-term? Given the importance of Stratio's Lucene index extension, which > uses this mechanism too, I'd guess no one wants to do anything that would > destroy that either, but I need to ask. > > Many thanks, > > Russ > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
