Re: [DISCUSS] Change style guide to recommend use of @Override
+1 — Robert Stupp @snazy > On 2. Sep 2020, at 10:38, Sylvain Lebresne wrote: > > +1 > -- > Sylvain > > > On Wed, Sep 2, 2020 at 10:21 AM Sam Tunnicliffe wrote: > >> +1 >> >>> On 2 Sep 2020, at 09:03, Benjamin Lerer >> wrote: >>> >>> +1 >>> >>> >>> >>> On Wed, Sep 2, 2020 at 5:36 AM Berenguer Blasi >> >>> wrote: >>> >>>> +1 >>>> >>>> On 2/9/20 5:09, Joshua McKenzie wrote: >>>>> +1 >>>>> >>>>> On Tue, Sep 1, 2020 at 6:26 PM Jordan West wrote: >>>>> >>>>>> +1 >>>>>> >>>>>> On Tue, Sep 1, 2020 at 12:22 PM Benedict Elliott Smith < >>>>>> bened...@apache.org> >>>>>> wrote: >>>>>> >>>>>>> +1 >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 01/09/2020, 20:09, "Caleb Rackliffe" >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> +1 >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Sep 1, 2020, 2:00 PM Jasonstack Zhao Yang < >>>>>>> jasonstack.z...@gmail.com> >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> +1 >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> On Wed, 2 Sep 2020 at 02:45, Dinesh Joshi >>>>>> wrote: >>>>>>>> >>>>>>> >>>>>>>>> +1 >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>>> On Sep 1, 2020, at 11:27 AM, David Capwell < >>>> dcapw...@gmail.com >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> Currently our style guide recommends to avoid using @Override >>>>>> and >>>>>>>> updates >>>>>>> >>>>>>>>>> intellij's code style to exclude it by default; I would like >>>> to >>>>>>> propose >>>>>>> >>>>>>>>> we >>>>>>> >>>>>>>>>> change this recommendation to use it and to update intellij's >>>>>>> style to >>>>>>> >>>>>>>>>> include it by default. >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> @Override is used by javac to enforce that a method is in >>>> fact >>>>>>> >>>>>>>> overriding >>>>>>> >>>>>>>>>> from an abstract class or an interface and if this stops >>>> being >>>>>>> true >>>>>>> >>>>>>>> (such >>>>>>> >>>>>>>>>> as a refactor happens) then a compiler error is thrown; when >>>> we >>>>>>> default >>>>>>> >>>>>>>>> to >>>>>>> >>>>>>>>>> excluding, it makes it harder to detect that a refactor >>>> catches >>>>>>> all >>>>>>> >>>>>>>>>> implementations and can lead to subtle and hard to track down >>>>>>> bugs. >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> This proposal is for new code and would not be to go rewrite >>>>>> all >>>>>>> code >>>>>>> >>>>>>>> at >>>>>>> >>>>>>>>>> once, but would recommend new code adopt this style, and to >>>>>> pull >>>>>>> old >>>>>>> >>>>>>>> code >>>>>>> >>>>>>>>>> forward which is related to changes being made (similar to >>>> our >>>>>>> stance >>>>>>> >>>>>>>> on >>>>>>> >>>>>>>>>> imports). >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> If people are ok with this, I will file a JIRA, update the >>>>>> docs, >>>>>>> and >>>>>>> >>>>>>>>>> update intellij's formatting. >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> Thanks for your time! >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> - >>>>>>> >>>>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>> >>>> - >>>> 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 >> >>
Re: [VOTE] Release Apache Cassandra 4.0-beta1
+1 (nb) — Robert Stupp @snazy > On 15. Jul 2020, at 20:07, Jasonstack Zhao Yang > wrote: > > +1 (nb) > > On Thu, 16 Jul 2020 at 01:28, Brandon Williams wrote: > >> +1 (binding) >> >> On Tue, Jul 14, 2020, 6:06 PM Mick Semb Wever wrote: >> >>> Proposing the test build of Cassandra 4.0-beta1 for release. >>> >>> sha1: 5e767711360ecc4bc05a7cd219f0e680bfada004 >>> Git: >>> >>> >> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta1-tentative >>> Maven Artifacts: >>> >>> >> https://repository.apache.org/content/repositories/orgapachecassandra-1210/org/apache/cassandra/cassandra-all/4.0-beta1/ >>> >>> The Source and Build Artifacts, and the Debian and RPM packages and >>> repositories, are available here: >>> https://dist.apache.org/repos/dist/dev/cassandra/4.0-beta1/ >>> >>> The vote will be open for 72 hours (longer if needed). Everyone who has >>> tested the build is invited to vote. Votes by PMC members are considered >>> binding. A vote passes if there are at least three binding +1s and no >> -1s. >>> >>> Eventual publishing and announcement of the 4.0-beta1 release will be >>> coordinated, as described in >>> >>> >> https://lists.apache.org/thread.html/r537fe799e7d5e6d72ac791fdbe9098ef0344c55400c7f68ff65abe51%40%3Cdev.cassandra.apache.org%3E >>> >>> [1]: CHANGES.txt: >>> >>> >> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-beta1-tentative >>> [2]: NEWS.txt: >>> >>> >> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta1-tentative >>> >>
Re: [DISCUSS] Revisiting Java 11's experimental status
Yea, ZGC is kinda tricky in 11. — Robert Stupp @snazy > On 14. Jul 2020, at 15:02, Jeff Jirsa wrote: > > Zgc > >> On Jul 14, 2020, at 2:26 AM, Robert Stupp wrote: >> >> >>> On 14. Jul 2020, at 07:33, Jeff Jirsa wrote: >>> >>> Perhaps the most notable parts of jdk11 (for cassandra) aren’t even prod >>> ready in jdk11 , so what’s the motivation and what does the project gain >>> from revisiting the experimental designation on jdk11? >> >> Can you elaborate on what’s not even prod ready in Java 11? > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org >
Re: [DISCUSS] Revisiting Java 11's experimental status
If I understand correctly, you’re proposing to “officially support” Java 8 and 11 (i.e. remove the “experimental” tag for Java 11). +1 on that from my side. It totally makes sense to me for 4.0. Don’t want to hijack the original thread (as it’s just about C* 4.0), but some thoughts about post-4.0: Java 8 gets (probably just critical) patches until 2026 (e.g. from adoptopenjdk, not sure about other vendors). But I suspect 2026 is really the very last date until 8 finally gets retired. Considering that users still run C* 2.1 (released 2014) and older, it’s probably reasonable to plan to remove Java 8-support in the next version (i.e. 4.1) and require the last LTS Java (11, 17, etc) _and_ the current non-LTS (on a best-effort/experimental basis). Especially the “new GCs” (Z, Shenandoah) and a bunch of other upcoming features (e.g. Loom, Panama, Records) are very interesting and beneficial for the project. I did some experiments and a recent build works against Java 14 (and a nightly build of 15 IIRC). A couple of unit tests need to be adopted (fix the no longer working java.lang.ref.Field code in some unit tests) and Nashorn needs to be replaced (it has recently been removed). It is not that much work, it just needs to be done. — Robert Stupp @snazy > On 13. Jul 2020, at 20:42, Jon Haddad wrote: > > Support for Java 11 was added a long time ago, and it's been about 2 years > since it was released (Sept 2018). Had we released Cassandra 4 close to > that date, I'd be fine with keeping the status as experimental, but at this > point I'm wondering if releasing a new major version of C* that's primarily > targeting Java 8 as the only "official" supported version is a good idea. > > To those of you that are planning on rolling out C* 4.0, are you planning > on using Java 8 still, or moving to 11? Speaking for myself, I can say I > don't think I'd want to use 8 anymore. If most folks are testing with 11 > at this point, I think we should consider making 11 the recommended version > and really only encouraging Java 8 for legacy purposes - teams who have a > restriction that prevents them from upgrading. > > To those of you planning on moving to 4.0 soon after it's release, are you > planning on deploying to JDK 11 or 8? > > [1] https://www.oracle.com/java/technologies/java-se-support-roadmap.html
Re: [DISCUSS] Revisiting Java 11's experimental status
> On 14. Jul 2020, at 07:33, Jeff Jirsa wrote: > > Perhaps the most notable parts of jdk11 (for cassandra) aren’t even prod > ready in jdk11 , so what’s the motivation and what does the project gain from > revisiting the experimental designation on jdk11? Can you elaborate on what’s not even prod ready in Java 11?
Re: Build tool
Yea - it's already in a pretty good state. Some work-in-progress-state is already available in either https://github.com/snazy/cassandra/tree/tryout-gradle (or https://github.com/snazy/cassandra/tree/tryout-gradle-dist-test with an additional commit). I already use it on my machine for a bunch of things and it already "feels bad" to go back to a branch without Gradle. I'll start a separate dev-ML thread with some more information in the next days, because getting C* 4.0-beta released is a higher priority atm. On 6/1/20 2:41 AM, Joshua McKenzie wrote: Build tools are like religions, that's why. Or maybe cults. Or all Stockholm Syndrome creators? :) Robert Stupp has been noodling around with a gradle based build env for C* that'll live alongside ant. Not sure what the status is on that atm through. On Sun, May 31, 2020 at 3:16 PM Abhishek Singh wrote: Hi All, Hope you are doing well and are safe. I just wanted to know why is the build still on ant and is there any plan to migrate to a modern build tool? Regards, Abhishek Singh -- Robert Stupp @snazy - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Calling for release managers (Committers and PMC)
I can help -- Robert Stupp @snazy > Am 07.05.2020 um 20:29 schrieb Mick Semb Wever : > > The Cassandra release process has had some improvements to better in > line with the ASF guidelines: sha256 & sha512 checksums, staged > artefacts in svnpubsub, dep and rpm repositories complete and signed > in staging, and separate scripts and manual steps merged together. > > The updated documentation for cutting, voting, and publishing a > release is found here: > https://cassandra.apache.org/doc/latest/development/release_process.html > > I am hoping to get as many Committers* and PMC members interested as > possible for cutting a future release. > > Who is interested? How many names can I get :-) > > The more that are interested then the easier it is to take turns and > be flexible depending on our own availability each time. I will help > out everyone on their first run. Indeed most of my motivation in > getting involved with the release process was to make it all as simple > and as forgettable as possible, so the role of the role manager can > change easily from release to release. > > *When a Committer cuts a release, a PMC member has to perform the very > last post-vote publish step. > > regards, > Mick > > - > 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
Re: UDF
The patch is technically complete - i.e. it works and does its thing. It's not strictly a bug fix but targets trunk. That's why I started the discussion. On 09/11/2018 02:53 PM, Jason Brown wrote: Hi Robert, Thanks for taking on this work. Is this message a heads up that a patch is coming/complete, or to spawn a discussion about including this in 4.0? Thanks, -Jason On Tue, Sep 11, 2018 at 2:32 AM, Robert Stupp wrote: In an effort to clean up our hygiene and limit the dependencies used by UDFs/UDAs, I think we should refactor the UDF code parts and remove the dependency to the Java Driver in that area without breaking existing UDFs/UDAs. A working prototype is in this branch: https://github.com/snazy/ cassandra/tree/feature/remove-udf-driver-dep-trunk < https://github.com/snazy/cassandra/tree/feature/remove- udf-driver-dep-trunk> . The changes are rather trivial and provide 100% backwards compatibility for existing UDFs. The prototype copies the necessary parts from the Java Driver into the C* source tree to org.apache.cassandra.cql3.functions.types and adopts its usages - i.e. UDF/UDA code plus CQLSSTableWriter + StressCQLSSTableWriter. The latter two classes have a reference to UDF’s UDHelper and had to be changed as well. Some functionality, like type parsing & handling, is duplicated in the code base with this prototype - once in the “current” source tree and once for UDFs. However, unifying the code paths is not trivial, since the UDF sandbox prohibits the use of internal classes (direct and likely indirect dependencies). Robert — Robert Stupp @snazy -- Robert Stupp @snazy - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
UDF
In an effort to clean up our hygiene and limit the dependencies used by UDFs/UDAs, I think we should refactor the UDF code parts and remove the dependency to the Java Driver in that area without breaking existing UDFs/UDAs. A working prototype is in this branch: https://github.com/snazy/cassandra/tree/feature/remove-udf-driver-dep-trunk <https://github.com/snazy/cassandra/tree/feature/remove-udf-driver-dep-trunk> . The changes are rather trivial and provide 100% backwards compatibility for existing UDFs. The prototype copies the necessary parts from the Java Driver into the C* source tree to org.apache.cassandra.cql3.functions.types and adopts its usages - i.e. UDF/UDA code plus CQLSSTableWriter + StressCQLSSTableWriter. The latter two classes have a reference to UDF’s UDHelper and had to be changed as well. Some functionality, like type parsing & handling, is duplicated in the code base with this prototype - once in the “current” source tree and once for UDFs. However, unifying the code paths is not trivial, since the UDF sandbox prohibits the use of internal classes (direct and likely indirect dependencies). Robert — Robert Stupp @snazy
Re: [DISCUSS] Cassandra and future Java
Ideally, CI would run against both Java 8 and 11. I’ve no clue about b.a.o though. There will definitely be a log of smaller issues - both for OpenJDK 8 and 11. I think, it’s sufficient to deal with the Linux distros' (RH/deb) openjdk dependencies - just making sure, that we’re using the right Java version - and not let the package manger just pull the newest available. The version-string from adoptopenjdk for example is one of these “minor issues"... — Robert Stupp @snazy > On 28. May 2018, at 15:46, Stefan Podkowinski wrote: > > The main issue that I see, for supporting both Java 8 + 11, is testing. > We should first decide how this would effect builds.apache.org, or how > we're going to do CI testing in general for that situation. > > There are probably also smaller issues that we're not aware of yet, such > as which Java dependency to use for our deb and rpm packages, > differences in Java distributions (Oracle, AdoptOpenJDK, Redhat,..) and > so on. I'd expect we could deal with this on the Java side, but the > infra, scripting and testing implications give me a greater headache > when thinking of it. > > > On 25.05.2018 15:33, J. D. Jordan wrote: >> +1 for “Option 3: both 8 + 11” it shouldn’t be too hard to maintain code >> wise, and leaves people’s options open. >> >> -Jeremiah >> >>> On May 25, 2018, at 6:31 AM, Robert Stupp wrote: >>> >>> I'd like to bring up the C*/Java discussion again. It's been a while since >>> we've discussed this. >>> >>> To me it sounds like there's still the question about which version(s) of >>> Java we want to support beginning with C* 4.0. >>> >>> I assume, that it's legit (and probably very necessary) to assume that >>> OpenJDK is now (i.e. after Java 6) considered as "production ready" for C*. >>> The public (and legal and free) availability of Oracle's Java 8 will end in >>> January 2019 (unless you're using it privately on your desktop). Java 9 and >>> 10 are not a thing, as both will be EOL when the C* 4.0 branch is about to >>> be cut. The most recent available Java version will be 11, which is meant >>> to be publicly available from Oracle until March 2019 and should get LTS >>> support for OpenJDK 11 from major Linux distros (RHEL and derivates, >>> Ubuntu, Azul Zulu). >>> >>> (Side note: adoptopenjdk is different here, because it does not include the >>> patch version in the version banner (java.version=1.8.0-adoptopenjdk), so >>> difficult to check the minimum patch version on startup of C*.) >>> >>> (Attn, rant: I'm not particularly happy with the new release and support >>> model for Java, because developing something now, that's about to release >>> end of the year on a Java version that has not even reached >>> feature-complete status, is, gently speaking, difficult. But sticking to an >>> "antique" Java version (8) has its own risks as well.) >>> >>> I'm silently ignoring any Java release, that's not aimed to get any >>> LTS(-ish?) support from anybody - so only Java 8 + 11 remain. >>> >>> There are generally three (IMO legit) options here: only support Java 8, >>> only support Java 11, support both Java 8 and Java 11. All three options >>> have a bunch of pros and cons. >>> >>> Option 1, only Java 8: Probably the safest option. Considering the >>> potential lifetimes of Java 8 and C* 4.0, even the most enthusiastic >>> maintainers may stop backporting security or bug fixes to OpenJDK 8. It >>> might not be an issue in practice, but if there's for example a severe >>> issue in the SSL/TLS area and nobody fixes it in 8, well, good luck. >>> >>> Option 2, only Java 11: The option with the most risks IMO. Java 11 is not >>> even feature complete, and there a bunch of big projects that still may >>> make it into 11 (think: Valhalla). There's no guarantee whether the C* code >>> or any included library will actually work with Java 11 (think: if it works >>> now, it may not work with the final Java version). However, it leaves the >>> door wide open for all the neat and geeky things in Java 11. >>> >>> Option 3: both 8 + 11: The idea here is to default to Java 8, but the code >>> also runs on 11. It leaves the option to benefit from optimizations that >>> are only available on 11 while maintaining the known stability of 8. >>> Initially, only the combination of C* 4.0 + Java 8 would be labeled as >>> "stable" and the combi
[DISCUSS] Cassandra and future Java
I'd like to bring up the C*/Java discussion again. It's been a while since we've discussed this. To me it sounds like there's still the question about which version(s) of Java we want to support beginning with C* 4.0. I assume, that it's legit (and probably very necessary) to assume that OpenJDK is now (i.e. after Java 6) considered as "production ready" for C*. The public (and legal and free) availability of Oracle's Java 8 will end in January 2019 (unless you're using it privately on your desktop). Java 9 and 10 are not a thing, as both will be EOL when the C* 4.0 branch is about to be cut. The most recent available Java version will be 11, which is meant to be publicly available from Oracle until March 2019 and should get LTS support for OpenJDK 11 from major Linux distros (RHEL and derivates, Ubuntu, Azul Zulu). (Side note: adoptopenjdk is different here, because it does not include the patch version in the version banner (java.version=1.8.0-adoptopenjdk), so difficult to check the minimum patch version on startup of C*.) (Attn, rant: I'm not particularly happy with the new release and support model for Java, because developing something now, that's about to release end of the year on a Java version that has not even reached feature-complete status, is, gently speaking, difficult. But sticking to an "antique" Java version (8) has its own risks as well.) I'm silently ignoring any Java release, that's not aimed to get any LTS(-ish?) support from anybody - so only Java 8 + 11 remain. There are generally three (IMO legit) options here: only support Java 8, only support Java 11, support both Java 8 and Java 11. All three options have a bunch of pros and cons. Option 1, only Java 8: Probably the safest option. Considering the potential lifetimes of Java 8 and C* 4.0, even the most enthusiastic maintainers may stop backporting security or bug fixes to OpenJDK 8. It might not be an issue in practice, but if there's for example a severe issue in the SSL/TLS area and nobody fixes it in 8, well, good luck. Option 2, only Java 11: The option with the most risks IMO. Java 11 is not even feature complete, and there a bunch of big projects that still may make it into 11 (think: Valhalla). There's no guarantee whether the C* code or any included library will actually work with Java 11 (think: if it works now, it may not work with the final Java version). However, it leaves the door wide open for all the neat and geeky things in Java 11. Option 3: both 8 + 11: The idea here is to default to Java 8, but the code also runs on 11. It leaves the option to benefit from optimizations that are only available on 11 while maintaining the known stability of 8. Initially, only the combination of C* 4.0 + Java 8 would be labeled as "stable" and the combination of C* 4.0 + Java 11 as "experimental". But it gives us time to "evaluate" 4.0 on 11. When we have enough experience with 11, C* on 11 can be labeled as "stable" as well. The downside of this "hybrid" is, that it's a bit more difficult to introduce features, that depend on 11. I think, 3) gives the best of both worlds: stability of 8 and an upgrade path to 11 in the future, that people can actually test with C* 4.0. Happy to make the patch for #9608 ready for option 3. But it would be great to get a consensus here for either option before we review #9608 and commit it. Another proposal, for both options 1+3: Raise the minimum supported version of 8 for C* 4.0 to something more recent than 8u40, which is quite from the stone-age. It could be 8u171 or whatever will be recent in autumn. Robert -- Robert Stupp @snazy - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] java 9 and the future of cassandra on the jdk
sarily the pure ones from the upstream, they might include patches that provide better support for the distribution - or even fix bugs that are not yet in the upstream version. I guess we also need the Windows versions, maybe the PowerPC & ARM versions also at some point. I'm not sure if we plan to support J9 or other JVMs at some point. We would also need to create CVE reports after each Java CVE for Cassandra as well I would assume since it would affect us separately (and updating only the Java wouldn't help). To me this sounds like an understatement of the amount of work that would go to this. Not to mention the bad publicity if Java CVEs are not actually patched instantly in the Cassandra also (and then each user would have to validate that the shipped version actually works with their installation in their hardware since they won't get support for it from the vendors as it's unofficial package). - Micke - 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 - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org -- Robert Stupp @snazy - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] java 9 and the future of cassandra on the jdk
Don't forget that you have to spend bucks to get LTS. My hope is that after that Java 9, upcoming releases should be smoother to use. I.e. settling the C* release on the Java release that's current at that point in time sounds good enough. I.e. my hope is that any C* release made for Java X will work with Java X+n (in the foreseeable future). Caveat is probably the use of "Unsafe"... For example, if a major release would be planned for April, supporting Java 10 should be good enough. But that C* major release should stay on Java 10 and no code that requires a newer Java version must get in. I'm not sure whether recommending OracleJDK over OpenJDK is required. You get some goodies with OracleJDK (CAs for example), sure. On 03/20/2018 03:22 PM, Josh McKenzie wrote: Need a little clarification on something: 2) always release cassandra on a LTS version combined with: 3) keep trunk on the lasest jdk version, assumming we release a major cassandra version close enough to a LTS release. Wouldn't that potentially leave us in a situation where we're ready for a C* release but blocked waiting on a new LTS cut? For example, if JDK 9 were the currently supported LTS and trunk was on JDK 11, we'd either have to get trunk to work with 9 or wait for 11 to resolve that. On Tue, Mar 20, 2018 at 9:32 AM, Jason Brown <jasedbr...@gmail.com> wrote: Hi all, TL;DR Oracle has started revving the JDK version much faster, and we need an agreed upon plan. Well, we probably should has this discussion this already by now, but here we are. Oracle announced plans to release updated JDK version every six months, and each new version immediate supercedes the previous in all ways: no updates/security fixes to previous versions is the main thing, and previous versions are EOL'd immediately. In addition, Oracle has planned parallel LTS versions that will live for three years, and then superceded by the next LTS; but not immediately EOL'd from what I can tell. Please see [1, 2] for Oracle's offical comments about this change ([3] was particularly useful, imo), [4] and many other postings on the internet for discussion/commentary. We have a jira [5] where Robert Stupp did most of the work to get us onto Java 9 (thanks, Robert), but then the announcement of the JDK version changes happened last fall after Robert had done much of the work on the ticket. Here's an initial proposal of how to move forward. I don't suspect it's complete, but a decent place to start a conversation. 1) receommend OracleJDK over OpenJDK. IIUC from [3], the OpenJDK will release every six months, and the OracleJDK will release every three years. Thus, the OracleJDK is the LTS version, and it just comes from a snapshot of one of those OpenJDK builds. 2) always release cassandra on a LTS version. I don't think we can reasonably expect operators to update the JDK every six months, on time. Further, if there are breaking changes to the JDK, we don't want to have to update established c* versions due to those changes, every six months. 3) keep trunk on the lasest jdk version, assumming we release a major cassandra version close enough to a LTS release. Currently that seems reasonable for cassandra 4.0 to be released with java 11 (18.9 LTS) support. Perhaps we can evaluate this over time. Once we agree on a path forward, *it is impreative that we publish the decision to the docs* so we can point contributors and operators there, instead of rehashing the same conversation. I look forward to a lively discussion. Thanks! -Jason [1] http://www.oracle.com/technetwork/java/eol-135779.html [2] https://blogs.oracle.com/java-platform-group/faster-and-easier-use-and-redistribution-of-java-se [3] https://www.oracle.com/java/java9-screencasts.html?bcid=5582439790001=single-social=events [4] http://blog.joda.org/2018/02/java-9-has-six-weeks-to-live.html?utm_source=feedburner_medium=feed_campaign=Feed%3A+StephenColebournesBlog+%28Stephen+Colebourne%27s+blog%29 [5] https://issues.apache.org/jira/browse/CASSANDRA-9608 - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org -- Robert Stupp @snazy - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: URGENT: CASSANDRA-14092 causes Data Loss
;>>> create table test(name text primary key,age int);
>>>>>>>> insert into test(name,age) values('test_20yrs',30) USING TTL
>>>> 63072;
>>>>>>>> select * from test where name='test_20yrs';
>>>>>>>>
>>>>>>>> name | age
>>>>>>>> --+-
>>>>>>>>
>>>>>>>> (0 rows)
>>>>>>>>
>>>>>>>> insert into test(name,age) values('test_20yr_plus_1',30) USING TTL
>>>>>> 630720001;InvalidRequest: Error from server: code=2200 [Invalid
>> query]
>>>>>> message="ttl is too large. requested (630720001) maximum (63072)"
>>>>>>>> ThanksAnuj
>>>>>>>> On Friday 26 January 2018, 12:11:03 AM IST, J. D. Jordan <
>>>>>> jeremiah.jor...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Where is the dataloss? Does the INSERT operation return
>> successfully
>>>>>> to the client in this case? From reading the linked issues it sounds
>>>> like
>>>>>> you get an error client side.
>>>>>>>>
>>>>>>>> -Jeremiah
>>>>>>>>
>>>>>>>>> On Jan 25, 2018, at 1:24 PM, Anuj Wadehra <anujw_2...@yahoo.co.in
>> .
>>>> INVALID>
>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> For all those people who use MAX TTL=20 years for
>> inserting/updating
>>>>>> data in production, https://issues.apache.org/
>>>> jira/browse/CASSANDRA-14092
>>>>>> can silently cause irrecoverable Data Loss. This seems like a certain
>>>> TOP
>>>>>> MOST BLOCKER to me. I think the category of the JIRA must be raised
>> to
>>>>>> BLOCKER from Major. Unfortunately, the JIRA is still "Unassigned"
>> and no
>>>>>> one seems to be actively working on it. Just like any other critical
>>>>>> vulnerability, this vulnerability demands immediate attention from
>> some
>>>>>> very experienced folks to bring out an Urgent Fast Track Patch for
>> all
>>>>>> currently Supported Cassandra versions 2.1,2.2 and 3.x. As per my
>>>>>> understanding of the JIRA comments, the changes may not be that
>> trivial
>>>> for
>>>>>> older releases. So, community support on the patch is very much
>>>> appreciated.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Anuj
>>>>>>>>
>>>>>>>>
>> -
>>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>>
>> -
>>>>>> 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
>>
>>
—
Robert Stupp
@snazy
Re: [VOTE] self-assignment of jira tickets
non-binding +1, too. — Robert Stupp @snazy > On 29. Mar 2017, at 15:21, Jason Brown <jasedbr...@gmail.com> wrote: > > Hey all, > > Following up my thread from a week or two ago ( > https://lists.apache.org/thread.html/0665f40c7213654e99817141972c003a2131aba7a1c63d6765db75c5@%3Cdev.cassandra.apache.org%3E), > I'd like to propose a vote to change to allow any potential contributor to > assign a jira to themselves without needing to be added to the contributors > group first. > > https://issues.apache.org/jira/browse/INFRA-11950 is an example of how to > get this done with INFRA. > > Vote will be open for 72 hours. > > Thanks, > > -Jason Brown signature.asc Description: Message signed with OpenPGP
Re: A proposal to move away from Jira-centric development
I am +1 on separating JIRA changes into a new issues@ ML and to have mail to start a design discussion in JIRA on the dev@ ML. FWIW, I’m coding for many many years and have seen a lot of attempts to organise discussions within businesses and in public. Most of these discussions were made on mailing lists, which was *the tool* to work with these days. But emails were never and still are not a definitely reliable medium - emails sometimes get lost or massively delayed on the transport - which is the nature of emails - emails are not instant messaging nor necessarily arrive in order. But having an common, consistent and ordered view to a discussion is important IMO. JIRA provides this view as a tool made to track issues. Mean - JIRAs are dynamic, have a state and such. Emails don’t. You can see whether an issue is e.g. closed - but you can’t instantly see whether an email discussion is “closed”. When I started to contribute to Apache Cassandra, I really liked the use of JIRA because it made it much easier to get into tickets/topics that are interesting and are still active (why should a newbie read a whole discussion about something that’s already done or obsolete to find something interesting?). Nowadays, I look at the tickets updated in commits@ but go to JIRA to see the whole picture. Additionally, I’ve got a dashboard setup for my needs - but that’s probably only advantageous for frequent contributors or committers. IMO, JIRA is the medium with the best signal-noise-ratio - you can filter/watch individual JIRAs. But for mailing lists it’s always all or nothing. — Robert Stupp @snazy > On 16 Aug 2016, at 06:19, Ken Hancock <ken.hanc...@schange.com> wrote: > > On Mon, Aug 15, 2016 at 3:57 PM, Dave Lester <dave_les...@apple.com> wrote: > >> Interesting, thanks for pointing out this distinction. >> >> Perhaps breaking out issues from the commits list would help make it >> easier for folks to subscribe in the future? At least within the Apache >> Mesos and Apache Aurora projects, we’ve seen more people subscribe to >> issues@ lists than commits@ lists. >> > > I was unaware of the commits mailing list and subscribed, but created > filters to delete comments/updates and only keep Created/Resolved. Is that > essentially what the issues@ list is for Mesos?
Re: [VOTE] Release Apache Cassandra 3.8
+1 — Robert Stupp @snazy > On 21 Jul 2016, at 07:48, Michael Shuler <mshu...@apache.org> wrote: > > I propose the following artifacts for release as 3.8. > > sha1: c3ded0551f538f7845602b27d53240cd8129265c > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.8-tentative > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-1123/org/apache/cassandra/apache-cassandra/3.8/ > Staging repository: > https://repository.apache.org/content/repositories/orgapachecassandra-1123/ > > The debian packages are available here: http://people.apache.org/~mshuler/ > > The vote will be open for 72 hours (longer if needed). > > [1]: http://goo.gl/oGNH0i (CHANGES.txt) > [2]: http://goo.gl/KjMtUn (NEWS.txt) > [3]: https://goo.gl/TxVLKo (3.8 Test Summary)
Re: Blockers for 4.0
There’s also: CASSANDRA-10520 Compressed writer and reader should support non-compressed data (changes sstable format) CASSANDRA-10383 Disable auto snapshot on selected tables (changes schema) — Robert Stupp @snazy > On 21 Jul 2016, at 00:59, Jason Brown <jasedbr...@gmail.com> wrote: > > CASSANDRA-8457 - nio MessagingService. Patch is up and awaiting review > > On Wed, Jul 20, 2016 at 7:40 AM, Jonathan Ellis <jbel...@gmail.com> wrote: > >> The plan of record has been to ship 4.0 in November, 12 months after 3.0. >> But, there are a number of features that are going to cause backwards >> incompatibility and if they miss 4.0 will need to wait for 5.0. Are any of >> these worth delaying 4.0 for? >> >> (Currently the plan is to have all of these ready for November, but let's >> get our backup plan figured out now, just in case. That way we don't have >> to make the decision at the last minute when everything feels like an >> emergency.) >> >> Some candidates that might be worth delaying the release for: >> >> - "Birch" trees for the primary key index >> <https://issues.apache.org/jira/browse/CASSANDRA-9754>. Changes the >> format of data on disk so automatically in the "dot zero" category. >> - Decouple messaging protocol versioning >> <https://issues.apache.org/jira/browse/CASSANDRA-12042>. This would >> allow us to change the intra-node protocol on a per-message basis, which >> gives us more flexibility with compatibility. Currently any change >> drops >> us into the "no schema changes until everyone is upgraded" world which >> effectively rules out making any improvements across tick-tock releases. >> - Allow dropping COMPACT STORAGE flag >> <https://issues.apache.org/jira/browse/CASSANDRA-10857>. This is what >> makes it possible to remove the deprecated Thrift support. >> - Schema rearchitecture >> <https://issues.apache.org/jira/browse/CASSANDRA-9424>. Can we live >> without safe and programatic CREATE and ALTER for another year? >> >> -- >> Jonathan Ellis >> Project Chair, Apache Cassandra >> co-founder, http://www.datastax.com >> @spyced >>
Re: MSc Project - compaction strategy
As Markus already mentioned, the best place to discuss the idea of your compaction strategy is a lira ticket. Best would be to include as much details (written, not coded) as necessary to understand why this compaction strategy is useful and how it works. Implementation questions and clarifications on #cassandra-dev IRC Robert — Robert Stupp @snazy > On 12 Jul 2016, at 19:42, Pedro Gordo <pedro.gordo1...@gmail.com> wrote: > > Hi all > > I'm finishing an MSc in which my final project is to implement a new > compaction strategy in Cassandra. I've discussed the main points of the > strategy with other community members and received valuable feedback. > However, I understand this will be a tough challenge for someone who has > never worked with Cassandra, but after getting to know the technology, I've > found it fascinating. Since I wanted to contribute to an open source > project in my MSc Project, this makes Cassandra the ideal technology to go > forward, and hence why I've chosen it. > > However, since this is my first time contributing to an open source > project, I've some questions on how to proceed correctly. Looking at the How > To Contribute <http://wiki.apache.org/cassandra/HowToContribute> page, I > see that we're supposed to create a ticket before starting working on it, > however, in this case, does someone need to validate the usefulness of the > strategy or can I just proceed and implement it, or do something else? > Also, is this the correct mailing list to be asking this sort of questions? > :) > > As for the code itself, if I have a question like "Should we be using an > abstract class for compaction classes?" or "What is this method supposed to > do?", can I ask it here? What is the best course of action to learn about > the details of the code in Cassandra? I already saw that it has some > comments, but probably won't be enough. > > The strategy I have in mind will be very simple until I finish the MSc. > After the submission, I'll improve it with other features and feedback I > got, but for the moment, I'll keep it at a basic level. The strategy will > start only during certain periods of time (for example a time of the day > where the cluster has little traffic (1)), during which, the rows will be > made unique across all SSTables. These new tables will be capped at a > configurable size, so after compaction, we can have multiple tables > created. This operation only happens if, after a prior analysis, we find > that the row exists in a number of SSTables above a certain threshold. What > I'm trying to address here is the continuous high CPU usage of the LCS (1), > but also the need for lots of disc space when we have big SSTables > resulting from STCS. I suppose it's a naive strategy, but the aim here is > to give me experience with C*, and of course I'll be happy to take > suggestions. But I'll probably only use the ideas after delivering the > project because, at the moment, I need to keep it simple. Otherwise, I'll > never be able to submit it. :) > > Sorry for the long email, and thanks for all the help in advance! I'm very > excited about this project and look forward to being part of this community! > > Best regards Pedro Gordo
Re: [VOTE] Release Apache Cassandra 3.6 (Attempt #2)
+1 (non-binding) — Robert Stupp @snazy > On Jun 1, 2016, at 19:30, Jake Luciani <j...@apache.org> wrote: > > I propose the following artifacts for release as 3.6. > > sha1: 8d22d9fd1842c59ea65a3793aceb5a78c5852351 > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.6-tentative > Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-1114/org/apache/cassandra/apache-cassandra/3.6/ > Staging repository: > https://repository.apache.org/content/repositories/orgapachecassandra-1114/ > > The artifacts as well as the debian package are also available here: > http://people.apache.org/~jake > > The vote will be open for 72 hours (longer if needed). > > [1]: http://goo.gl/lg9U9a (CHANGES.txt) > [2]: http://goo.gl/nyDyxk (NEWS.txt) > [3]: https://goo.gl/hNyrnW (DataStax QA Report) signature.asc Description: Message signed with OpenPGP using GPGMail
Commit message automation
Hi, yesterday I built a small python script that helps during commits. In case you’re interested, it’s on github as a public gist https://gist.github.com/snazy/1e7223be98e4ebe608af https://gist.github.com/snazy/1e7223be98e4ebe608af Usage: ./commit-jira.py TICKET_NUM Example: ./commit-jira.py 12345 (not CASSANDRA-12345) It uses the JIRA REST API to get the assignee, reviewer and summary to construct the commit msg and set the --author argument. It also opens a browser tab with the issue. Robert PS: I did not test it very thoroughly - so no idea what happens, when reviewer and/or assignee are not set. — Robert Stupp @snazy
Re: I want to develop transactions for Cassandra and I want your feedback
that original data can be restored.
Query rewriting seems like a complex functionality. I tried few simple and
a little bit more complex statements and in general for basic stuff
algorithm is not that complicated, but to support everything CQL has to
offer it might be hard.
Still such transactional system might have some restrictions over CQL
statements used, because first of all when someone wants to have these
transactions they already want something non standard.
I will skip details of that approach for now.
Rollback: Appending to seperate table.
Image we have table A that we want to have transactions on.
This requires another table A_tx which has same schema as A, but has *1
more clustering column* and few new columns. A_tx will be additionally
clustered by transaction id.
New columns are:
- is_committed boolean
- is_rolledback boolean
- is_applied boolean
General idea is:
1. During transaction append changes to XXX_tx tables.
2. For rollback: nothing needs to be done (besides cleaning XXX_tx tables
of useless data scheduled for rollback)
3. For commit: rows in each XXX_tx are marked as committed. This can be
done using BATCH update so that all rows affected by transactions are
committed. These changes will be eventually merged back into original row.
Committed changes are visible during query, because query has to select
from 2 tables. If you query for XXX table then you have to query that
table, but also XXX_TX and get all committed data, merge result and return
that to client.
Here committed data eventually lands into proper row - during read as
background process for example (this is this is_applied column) results are
merged and inserted into original row, plus additionally modifications can
be marked as _applied_.
Uncommitted data can also be eventually cleaned up.
*Important note:* since partitioning key stays the same for {{XXX}} table
and {{XXX_TX}} table, data will reside on same nodes so that queries and
application of data can be done locally.
### What happens next ###
Assuming I get any feedback I'll post more detailed descriptions of two
approaches.
I would love to hear your feedback on whole subject. Just to begin
discussion and pick your interest.
What you think about having more heavy transactions?
Does this experiment has sense at all?
regards
--
Marek Lewandowski
—
Robert Stupp
@snazy
Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)
I’ve got one - UDF using ecj instead of javassist (https://issues.apache.org/jira/browse/CASSANDRA-8241 https://issues.apache.org/jira/browse/CASSANDRA-8241). Not sure whether the licensing thing is fine that way (about what ”appropriately labeled“ really means in https://www.apache.org/legal/resolved.html#category-b https://www.apache.org/legal/resolved.html#category-b). One thing that may annoy using UDFs w/ tuples UDTs is #9186. It’s about frozen“ getting lost in the signature. Probably also include #9229 (timeuuid to date/time conversion) ? Am 12.05.2015 um 09:05 schrieb Marcus Eriksson krum...@gmail.com: We should get https://issues.apache.org/jira/browse/CASSANDRA-8568 in 2.2 as well (it is patch avail and I'll get it reviewed this week) /Marcus On Mon, May 11, 2015 at 9:42 PM, Jonathan Ellis jbel...@gmail.com wrote: Sounds good. I will add the new version to Jira. Planned tickets to block 2.2 beta for: #8374 #8984 #9190 Any others? (If it's not code complete today we should not block for it.) On Mon, May 11, 2015 at 1:59 PM, Aleksey Yeschenko alek...@apache.org wrote: So I think EOLing 2.0.x when 2.2 comes out is reasonable, especially considering that 2.2 is realistically a month or two away even if we can get a beta out this week. Given how long 2.0.x has been alive now, and the stability of 2.1.x at the moment, I’d say it’s fair enough to EOL 2.0 as soon as 2.2 gets out. Can’t argue here. If push comes to shove I'm okay being ambiguous here, but can we just say when 3.0 is released we EOL 2.1? Under our current projections, that’ll be exactly “a few months after 2.2 is released”, so I’m again fine with it. P.S. The area I'm most concerned about introducing destabilizing changes in 2.2 is commitlog So long as you don’t you compressed CL, you should be solid. You are probably solid even if you do use compressed CL. Here are my only concerns: 1. New authz are not opt-in. If a user implements their own custom authenticator or authorized, they’d have to upgrade them sooner. The test coverage for new authnz, however, is better than the coverage we used to have before. 2. CQL2 is gone from 2.2. Might force those who use it migrate faster. In practice, however, I highly doubt that anybody using CQL2 is also someone who’d already switch to 2.1.x or 2.2.x. -- AY On May 11, 2015 at 21:12:26, Jonathan Ellis (jbel...@gmail.com) wrote: On Sun, May 10, 2015 at 2:42 PM, Aleksey Yeschenko alek...@apache.org wrote: 3.0, however, will require a stabilisation period, just by the nature of it. It might seem like 2.2 and 3.0 are closer to each other than 2.1 and 2.2 are, if you go purely by the feature list, but in fact the opposite is true. You are probably right. But let me push back on some of the extra work you're proposing just a little: 1) 2.0.x branch goes EOL when 3.0 is out, as planned 3.0 was, however unrealistically, planned for April. And it's moving the goalposts to say the plan was always to keep 2.0.x for three major releases; the plan was to EOL with the next major release after 2.1 whether that was called 3.0 or not. So I think EOLing 2.0.x when 2.2 comes out is reasonable, especially considering that 2.2 is realistically a month or two away even if we can get a beta out this week. 2) 3.0.x LTS branch stays, as planned, and helps us stabilise the new storage engine Yes. 3) in a few months after 2.2 gets released, we EOL 2.1. Users upgrade to 2.2, get the same stability as with 2.1.7, plus a few new features If push comes to shove I'm okay being ambiguous here, but can we just say when 3.0 is released we EOL 2.1? P.S. The area I'm most concerned about introducing destabilizing changes in 2.2 is commitlog; I will follow up to make sure we have a solid QA plan there. -- Jonathan Ellis Project Chair, Apache Cassandra co-founder, http://www.datastax.com @spyced -- Jonathan Ellis Project Chair, Apache Cassandra co-founder, http://www.datastax.com @spyced — Robert Stupp @snazy
Re: [discuss] Modernization of Cassandra build system
are reported due that. First of all - I want to note that I am not born enemy of Ant itself. I never used it. I am also aware of problems with custom builds made with Maven, however I don’t really want to discuss any particular replacement, yet I want to note that Cassandra JIRA project contains about 116 issues related somehow to maven (http://bit.ly/1GRoXl5 http://bit.ly/1GRoXl5 http://bit.ly/1GRoXl5 http://bit.ly/1GRoXl5, project=CASSANDRA, text ~ maven). Depends on the point of view it might be a lot or a little. By simple statistics it is around 21 issues a year or almost 2 issues a month, many of them breaking maintanance/major releases from user point of view. From other hand it’s not bad considering how project is being built. Current structure has a very big disadvantage - ONE source root for multiple artifacts published in maven repositories and copying classes to jar AFTER they are compiled. Obviously ant copy task doesn’t follow import statements and does not include dependant classes. For example just by making test relocations and extraction of clientutil jar on master branch into separate source root I have found a bug where ListSerializer depends on org.apache.cassandra.transpor package. More over clientutil (MapSerializer) does depends on org.apache.cassandra.db.marshal package leading to the fact that it can not be used without cassandra-all present at classpath. Luckily for cassandra CQL as a new interface reduces thrift and clientutil usage reducing amount of issues reported around these, however this just hides a real problem in previous paragraph. I have found a handy tool and made a graph of circular dependencies in cassandra-all.jar. Graph of results can found here: http://grab.by/FRnO http://grab.by/FRnO http://grab.by/FRnO http://grab.by/FRnO. As you can see this graph has multiple levels and solving it is not a simple task. I am afraid a current way of building and packaging cassandra can create huge hiccups when it will come to code rafactorings cause entire cassandra will become a house of cards. Restructuring project into smaller pieces is also beneficiary for community since solving bugs in smaller units is definitelly easier. At the end of this mail I would like to propose moving Cassandra build system forward, regardless of tool which will be choosen for it. Personally I can volunteer in maven related changes to extract cassandra-thrift, cassandra-clientutil and cassandra-all to make regular maven build. It might be seen as a switch from one big XML into couple smaller. :-) All this depends on Cassandra developers decission to devide source roots or not. Kind regards, Łukasz Dywicki — l...@code-house.org Twitter: ldywicki Blog: http://dywicki.pl Code-House - http://code-house.org -- Tyler Hobbs DataStax http://datastax.com/ http://datastax.com/ — Robert Stupp @snazy
Re: 3.0 and the Cassandra release process
branch will only get bug fixes. We will maintain backwards compatibility for all of 3.x; eventually (no less than a year) we will pick a release to be 4.0, and drop deprecated features and old backwards compatibilities. Otherwise there will be nothing special about the 4.0 designation. (Note that with an “odd releases have new features, even releases only have bug fixes” policy, 4.0 will actually be *more* stable than 3.11.) Larger features can continue to be developed in separate branches, the way 8099 is being worked on today, and committed to trunk when ready. So this is not saying that we are limited only to features we can build in a single month. Some things will have to change with our dev process, for the better. In particular, with one month to commit new features, we don’t have room for committing sloppy work and stabilizing it later. Trunk has to be stable at all times. I asked Ariel Weisberg to put together his thoughts separately on what worked for his team at VoltDB, and how we can apply that to Cassandra -- see his email from Friday http://bit.ly/1MHaOKX. (TLDR: Redefine “done” to include automated tests. Infrastructure to run tests against github branches before merging to trunk. A new test harness for long-running regression tests.) I’m optimistic that as we improve our process this way, our even releases will become increasingly stable. If so, we can skip sub-minor releases (3.2.x) entirely, and focus on keeping the release train moving. In the meantime, we will continue delivering 2.1.x stability releases. This won’t be an entirely smooth transition. In particular, you will have noticed that 3.1 will get more than a month’s worth of new features while we stabilize 3.0 as the last of the old way of doing things, so some patience is in order as we try this out. By 3.4 and 3.6 later this year we should have a good idea if this is working, and we can make adjustments as warranted. -- Jonathan Ellis Project Chair, Apache Cassandra co-founder, http://www.datastax.com @spyced — Robert Stupp @snazy
Re: Latest Code from Trunk - Server is not starting
Try to clear the data + commitlog directory. At least the primary key for system.schema_functions table has changed in an incompatible way. Am 18.11.2014 um 21:43 schrieb Rajanarayanan Thottuvaikkatumana rnambood...@gmail.com: I have taken the latest code from trunk, compiled (I have some changes in some of the local files also). But when I start the Cassandra server, I am getting exceptions. The exceptions are not seeming to be from the classed where I changed OR has any relationship with the ones that are showing error. Any idea? Anybody else is getting same error? Rajanarayanans-MacBook-Pro:cassandra-trunk RajT$ ./bin/cassandra -f objc[4284]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.7.0_67.jdk/Contents/Home/bin/java and /Library/Java/JavaVirtualMachines/jdk1.7.0_67.jdk/Contents/Home/jre/lib/libinstrument.dylib. One of the two will be used. Which one is undefined. INFO 20:34:21 reading saved cache ./bin/../data/saved_caches/system-local-7ad54392bcdd35a684174e047860b377-KeyCache-b.db ERROR 20:34:21 Exception encountered during startup java.lang.RuntimeException: java.lang.ClassCastException: org.apache.cassandra.db.composites.CompoundComposite cannot be cast to org.apache.cassandra.db.composites.CellName at org.apache.cassandra.config.Schema.updateVersion(Schema.java:373) ~[main/:na] at org.apache.cassandra.config.DatabaseDescriptor.loadSchemas(DatabaseDescriptor.java:643) ~[main/:na] at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:257) [main/:na] at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:482) [main/:na] at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:574) [main/:na] Caused by: java.lang.ClassCastException: org.apache.cassandra.db.composites.CompoundComposite cannot be cast to org.apache.cassandra.db.composites.CellName at org.apache.cassandra.db.OnDiskAtom$Serializer.deserializeFromSSTable(OnDiskAtom.java:87) ~[main/:na] at org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:53) ~[main/:na] at org.apache.cassandra.db.AbstractCell$1.computeNext(AbstractCell.java:47) ~[main/:na] at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) ~[guava-16.0.jar:na] at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) ~[guava-16.0.jar:na] at org.apache.cassandra.io.sstable.SSTableIdentityIterator.hasNext(SSTableIdentityIterator.java:115) ~[main/:na] at org.apache.cassandra.db.filter.QueryFilter$2.getNext(QueryFilter.java:172) ~[main/:na] at org.apache.cassandra.db.filter.QueryFilter$2.hasNext(QueryFilter.java:155) ~[main/:na] at org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:146) ~[main/:na] at org.apache.cassandra.utils.MergeIterator$ManyToOne.init(MergeIterator.java:89) ~[main/:na] at org.apache.cassandra.utils.MergeIterator.get(MergeIterator.java:48) ~[main/:na] at org.apache.cassandra.db.filter.QueryFilter.collateColumns(QueryFilter.java:103) ~[main/:na] at org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:81) ~[main/:na] at org.apache.cassandra.db.RowIteratorFactory$2.getReduced(RowIteratorFactory.java:99) ~[main/:na] at org.apache.cassandra.db.RowIteratorFactory$2.getReduced(RowIteratorFactory.java:71) ~[main/:na] at org.apache.cassandra.utils.MergeIterator$ManyToOne.consume(MergeIterator.java:117) ~[main/:na] at org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:100) ~[main/:na] at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) ~[guava-16.0.jar:na] at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) ~[guava-16.0.jar:na] at org.apache.cassandra.db.ColumnFamilyStore$8.computeNext(ColumnFamilyStore.java:1931) ~[main/:na] at org.apache.cassandra.db.ColumnFamilyStore$8.computeNext(ColumnFamilyStore.java:1927) ~[main/:na] at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) ~[guava-16.0.jar:na] at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) ~[guava-16.0.jar:na] at org.apache.cassandra.db.ColumnFamilyStore.filter(ColumnFamilyStore.java:2079) ~[main/:na] at org.apache.cassandra.db.ColumnFamilyStore.getRangeSlice(ColumnFamilyStore.java:2038) ~[main/:na] at org.apache.cassandra.db.ColumnFamilyStore.getRangeSlice(ColumnFamilyStore.java:1972) ~[main/:na] at org.apache.cassandra.db.SystemKeyspace.serializedSchema(SystemKeyspace.java:942) ~[main/:na] at
RFC try for s/ant/gradle/
Hi, Since there were some IRC posts regarding realclean when dependencies change, I thought about replacing ant with something else. It's not just because of that particular realclean but also on dependencies that don't get actually updated or even out-of-date IDE project files (.classpath) causing problems. This something better should have proper dependency management, doesn't require us to have dependency jars in git and be supported my major IDEs (IDEA / Eclipse). (Someone using Eclipse?). But such a change should not result in a folder or code refactoring game... Maven could be an option - but it has some drawbacks regarding the current folder structure. Maven can basically only emit one artifact per pom properly (plus some other files like -javadoc.jar or -sources.jar). So it might be required to change the folder structure (don't want that - merging would become a nightmare, if possible at all...). Grade would be a nice option. It is more a scripting language than a static construct like Maven's pom.xml. It is very flexible and seems to have all required features. Gradle has native support for Maven repositories. Gradle does not require the user to install Gradle (you can, but do not need to) - it comes with a small wrapper that fetches a Gradle binary. I've identified these non-standard blocks in build.xml: gen-cli-grammar: basically just a conditional exec gen-cql3-grammar: basically just a conditional exec generate-cql-html: basically just an exec write-java-license-headers / rat: basically just an exec emitting multiple jars (cassandra.jar, cassandra-thrift.jar, cassandra-clientutil.jar) from the same folder (build/classes/main+thrift): difficult with Maven gen-thrift-py: basically just an exec several test targets: is possible with Maven, but let's the pom.xml explode and is not easy to read By using Gradle I hope to get rid of dependency problems realclean dependency differences between build.xml and IDE since .project/.classpath not updated .project/.classpath cannot be generated because compilation fails due to dependency changes make the build file smaller remove binaries (dependencies) from git proper IDE support for IDEA + Eclipse? If Gradle works, it could be introduced like that: Keep both build.xml and Gradle build file up to date After a while change build.xml to act basically just as a wrapper for Gradle. Just to not disturb existing processes (Jenkins/CI) and give users a chance to recognize the change. Remove build.xml after some time Would be great to get some feedback what you think about this. Robert signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [jira] [Created] (CASSANDRA-7611) incomplete CREATE/DROP USER help and tab completion
I've informed the docs people yesturday -- Sent from my iPhone Am 24.07.2014 um 18:28 schrieb Kristine Hahn (JIRA) j...@apache.org: Kristine Hahn created CASSANDRA-7611: Summary: incomplete CREATE/DROP USER help and tab completion Key: CASSANDRA-7611 URL: https://issues.apache.org/jira/browse/CASSANDRA-7611 Project: Cassandra Issue Type: Bug Components: Documentation website Reporter: Kristine Hahn Priority: Trivial IF NOT EXISTS/IF EXISTS doesn't appear in the online help and tab completion. -- This message was sent by Atlassian JIRA (v6.2#6252)
