Re: Proposal: require Java7 for Cassandra 2.0
+1 On Feb 6, 2013 5:22 PM, "Jonathan Ellis" wrote: > Java 6 EOL is this month. Java 7 will be two years old when C* 2.0 > comes out (July). Anecdotally, a bunch of people are running C* on > Java7 with no issues, except for the Snappy-on-OS-X problem (which > will be moot if LZ4 becomes our default, as looks likely). > > Upgrading to Java7 lets us take advantage of new (two year old) > features as well as simplifying interoperability with other > dependencies, e.g., Jetty's BlockingArrayQueue requires java7. > > Thoughts? > > -- > Jonathan Ellis > Project Chair, Apache Cassandra > co-founder, http://www.datastax.com > @spyced >
Re: Node side processing
Hi David, Check out the ongoing discussion in https://issues.apache.org/jira/browse/CASSANDRA-6704 as well as some related tickets linked to from that one. No consensus at this point, but I'm personally hoping to see something along the general lines of Hive's UDFs. -Tupshin On Thu, Feb 27, 2014 at 8:50 AM, David Semeria wrote: > Hi List, > > I was wondering whether there have been any past proposals for > implementing node side processing (NSP) in C*. By NSP, I mean the passing a > reference to a Java class which would then process the result set before it > being returned to the client. > > In our particular use case our clients typically loop through result sets > of a million or more rows to produce a tiny amount of output (sums, means, > variance, etc). The bottleneck -- quite obviously -- is the need to > transfer a million rows to the client before processing can take place. It > would be extremely useful to execute this processing on the coordinator > node and only transfer the results to the client. > > I mention this here because I can imagine other C* users having similar > requirements. > > Thanks > > D. >
Re: Pointers on writing your own Compaction Strategy
In addition to what Markus said, take a look at the latest patch in
https://issues.apache.org/jira/browse/CASSANDRA-6602 for a relevant
example.
-Tupshin
On Sep 4, 2014 2:28 PM, "Marcus Eriksson" wrote:
> 1. create a class that extends AbstractCompactionStrategy (i would keep it
> in-tree while developing to avoid having classpath issues etc)
> 2. Implement the abstract methods
>- getNextBackgroundTask - called when cassandra wants to do a new minor
> (background) compaction - return a CompactionTask with the sstables you
> want compacted
>- getMaximalTask - called when a user triggers a major compaction
>- getUserDefinedTask - when a user triggers a user defined compaction
> from JMX
>- getEstimatedRemainingTasks - return the guessed number of tasks before
> we are "done"
>- getMaxSSTableBytes - if your compaction strategy puts a limit on the
> size of sstables
> 3. Execute this in cqlsh to enable your compaction strategy: ALTER TABLE
> foo WITH compaction = { class: ‘Bar’ }
> 4. Things to think about:
> - make sure you mark sstables as compacting before returning them from
> the compaction strategy (and check the return value!):
>
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/SizeTieredCompactionStrategy.java#L271
> - if you do this on 2.1 - dont mix repaired and unrepaired sstables
> (SSTableReader#isRepaired)
>
> Let me know if you need any more information
>
> /Marcus
>
>
>
> On Thu, Sep 4, 2014 at 6:50 PM, Ghosh, Mainak
> wrote:
>
> > Hello,
> >
> > I am planning to write a new compaction strategy and I was hoping if
> > anyone can point me to the relevant functions and how they are related in
> > the call hierarchy.
> >
> > Thanks for the help.
> >
> > Regards,
> > Mainak.
> >
>
Re: 0.6.3
Contrary to my expectations and Jonathan's, Cassandra rebuilds cleanly against the latest thrift source (and any recent snapshot), with no code changes. This is important because it includes the patches for https://issues.apache.org/jira/browse/THRIFT-601 which, in turn, causes https://issues.apache.org/jira/browse/CASSANDRA-475 #475 is targetted for 0.7 release, but I believe that was only because of the belief that it would require medium-scale change to the Cassandra source, where, in fact, it requires none. I have been running stock 0.6.2 rebuilt against a recent thrift build for the past week and have seen no regressions and a complete fix for the thrift exceptions (followed by OOMs) that I was previously seeing. I would like to nominate #475 for inclusion in 0.6.3. It would require picking a stable recent snapshot of the thrift libs, replacing the existing libthrift jar, and rebuilding interface/thrift/gen-java. Thoughts? -Tupshin On 6/18/2010 12:12 PM, Eric Evans wrote: If there aren't any objections, I'd like to target the end of this month for the next point release, 0.6.3. If you have any show-stoppers that you feel should absolutely make it into the next release, please let me know, otherwise I'll plan on tagging 0.6.3 a week from today, Friday June 25th (open 0.6.3 issues will be moved to 0.6.4 at that time). Leaning into it,
Re: 0.6.3
On 6/18/2010 1:24 PM, Eric Evans wrote: On Fri, 2010-06-18 at 12:25 -0700, Tupshin Harper wrote: I would like to nominate #475 for inclusion in 0.6.3. It would require picking a stable recent snapshot of the thrift libs, replacing the existing libthrift jar, and rebuilding interface/thrift/gen-java. If it means rebuilding our generated code, then it means (some )users will need to do the same, which means incorporating Thrift up/downgrades into their upgrade/rollback procedures. I think it's also important to realize that as nasty as this bug is, it's not a recent regression (it's not a regression at all per say), and 0.7.0 will be a long relatively soon. I'd be interested to hear what others think, but I'm personally not very comfortable introducing such a change into a minor release. I would also like to hear other opinions, but if the consensus is that this is too big a change to introduce to 0.6.3, I'm fine with that too. I'm rolling my own releases now, and can continue to do so. I just know that the thrift problem has bitten a number of people and can be a hard one for new adopters to figure out. -Tupshin
Re: network compatibility from 0.6 to 0.7
As long as network compatibility is in place, it is possible to incrementally upgrade a cluster by restricting thrift clients to only talk to the 0.6 nodes until half the cluster is upgraded and then modify them to talk to the 0.7 nodes. If networking compatibility breaks, there is no way to avoid downtime or even test 0.7 under production load. On Jul 22, 2010 9:50 AM, "Jonathan Ellis" wrote: How useful is this to insist on, given that 0.7 thrift api is fairly incompatible with 0.6's? (timestamp -> Clock change being the biggest problem there) -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
