Re: [VOTE CLOSED] Release Apache Cassandra 1.2.13 (Strike 2)
Well. I feel stupid now :) On Dec 16, 2013, at 10:49 PM, Sylvain Lebresne sylv...@datastax.com wrote: On Tue, Dec 17, 2013 at 7:43 AM, Michael Kjellman mkjell...@barracuda.comwrote: I¹ve also seen behavior where prepared statements are lost during a rolling restart..haven¹t had a chance to debug/git bisect yet. Anyone else seen anything similar? I'd be somewhat surprised if someone hasn't. We don't persists prepared statements over node restart. it's supposed to be the client job to re-prepare statements when a node is restarted. -- Sylvain On 12/16/13, 10:40 PM, Sylvain Lebresne sylv...@datastax.com wrote: Alright, this vote is thus close. I'll re-roll when we've made sure we fixed all the regressions so we'll see when that is. -- Sylvain On Tue, Dec 17, 2013 at 1:01 AM, Brandon Williams dri...@gmail.com wrote: Or rather: https://issues.apache.org/jira/browse/CASSANDRA-6493 I would still prefer a 24h vote after resolution though. On Mon, Dec 16, 2013 at 5:56 PM, Brandon Williams dri...@gmail.com wrote: Changing to -1 as https://issues.apache.org/jira/browse/CASSANDRA-6488seems to be a real problem. On Mon, Dec 16, 2013 at 12:12 PM, Brandon Williams dri...@gmail.com wrote: +1 On Mon, Dec 16, 2013 at 3:38 AM, Sylvain Lebresne sylv...@datastax.com wrote: So now that CASSANDRA-6485 has been committed, I propose the following artifacts for release as 1.2.13. sha1: 4be9e6720d9f94a83aa42153c3e71ae1e557d2d9 Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/ tags/1.2.13-tentative Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-050 /org/apache/cassandra/apache-cassandra/1.2.13/ Staging repository: https://repository.apache.org/content/repositories/orgapachecassandra-050 / The artifacts as well as the debian package are also available here: http://people.apache.org/~slebresne/ Since it is a re-roll, I propose an expedited vote so the vote will be open for 24 hours (but longer if needed). [1]: http://goo.gl/j4xUAK (CHANGES.txt) [2]: http://goo.gl/iu5Og9 (NEWS.txt) === Find out how eSigning generates significant financial benefit. Read the Barracuda SignNow ROI whitepaper at https://signnow.com/l/business/esignature_roi === Find out how eSigning generates significant financial benefit. Read the Barracuda SignNow ROI whitepaper at https://signnow.com/l/business/esignature_roi
Best avenue for reporting security issues
Hi guys We’ve come across a bug with potential security implications and in the spirit of responsible disclosure whats the best path for reporting it / submitting patches without making the issue public until a fixed version of Cassandra is released? As a follow up I would propose that the Cassandra project should have secur...@cassandra.apache.org mailing address, where sensitive issues can be reported to the core dev team without it being made public. Regards Ben Bromhead Instaclustr | www.instaclustr.com | @instaclustr | +61 415 936 359
Re: Best avenue for reporting security issues
Hi Ben, Send it to me, I'll handle it. Thanks On Wed, Dec 18, 2013 at 2:30 AM, Ben Bromhead b...@instaclustr.com wrote: Hi guys We’ve come across a bug with potential security implications and in the spirit of responsible disclosure whats the best path for reporting it / submitting patches without making the issue public until a fixed version of Cassandra is released? As a follow up I would propose that the Cassandra project should have secur...@cassandra.apache.org mailing address, where sensitive issues can be reported to the core dev team without it being made public. Regards Ben Bromhead Instaclustr | www.instaclustr.com | @instaclustr | +61 415 936 359
Re: Best avenue for reporting security issues
No worries, message sent Ben Bromhead Instaclustr | www.instaclustr.com | @instaclustr | +61 415 936 359 On 18 Dec 2013, at 10:35 am, Aleksey Yeschenko alek...@apache.org wrote: Hi Ben, Send it to me, I'll handle it. Thanks On Wed, Dec 18, 2013 at 2:30 AM, Ben Bromhead b...@instaclustr.com wrote: Hi guys We’ve come across a bug with potential security implications and in the spirit of responsible disclosure whats the best path for reporting it / submitting patches without making the issue public until a fixed version of Cassandra is released? As a follow up I would propose that the Cassandra project should have secur...@cassandra.apache.org mailing address, where sensitive issues can be reported to the core dev team without it being made public. Regards Ben Bromhead Instaclustr | www.instaclustr.com | @instaclustr | +61 415 936 359
Dimensional SUM, COUNT, DISTINCT in C* (replacing Acunu)
We are seeking to replace Acunu in our technology stack / platform. It is the only component in our stack that is not open source. In preparation, over the last few weeks I’ve migrated Virgil to CQL. The vision is that Virgil could receive a REST request to upsert/delete data (hierarchical JSON to support collections). Virgil would lookup the dimensions/aggregations for that table, add the key to the pertinent dimensional tables (e.g. DISTINCT), incorporate values into aggregations (e.g. SUMs) and increment/decrement relevant counters (COUNT). (using additional CF’s) This seems straight-forward, but appears to require a read-before-write. (e.g. read the current value of a SUM, incorporate the new value, then use the lightweight transactions of C* 2.0 to conditionally update the value.) Before I go down this path, I was wondering if anyone is designing/working on the same, perhaps at a lower level? (CQL?) Is there any intent to support aggregations/filters (COUNT, SUM, DISTINCT, etc) at the CQL level? If so, is there a preliminary design? I can see a lower-level approach, which would leverage the commit logs (and mem/sstables) and perform the aggregation during read-operations (and flush/compaction). thoughts? i'm open to all ideas. -brian -- Brian ONeill Chief Architect, Health Market Science (http://healthmarketscience.com) mobile:215.588.6024 blog: http://brianoneill.blogspot.com/ twitter: @boneill42
