> The JVM version also isn’t a feature to deprecate, technically.
I agree with this. I think the JVM version the server runs under and how we
cycle those is a separate discussion from feature deprecation.
There can and has been some overlap there that would need to be handled on
a case by case ba
I think the default build should be to build and check everything. I think
that if someone is new it is better to have everything built and checked by
default to flag issues.
If someone knows what they are doing and wants to speed up the process it
is very easy to add the right settings to the an
+1
On Apr 17, 2025 at 10:58:24 AM, Josh McKenzie wrote:
> [DISCUSS] thread:
> https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq
>
> The proposed new versioning mechanism:
>
>1. We no longer use semver .MINOR
>2. Online upgrades are supported for all GA supported releases
+1 from me.
No more wondering what the next version number will be.
No more wondering what version I can upgrade from to use the new release.
-Jeremiah
On Apr 10, 2025 at 3:54:13 PM, Josh McKenzie wrote:
> This came up in the thread from Jon on "5.1 should be 6.0".
>
> I think it's important t
+1 to 6.0
On Thu, Apr 10, 2025 at 1:38 PM Josh McKenzie wrote:
> +1 to 6.0.
>
> On Thu, Apr 10, 2025, at 2:28 PM, Jon Haddad wrote:
>
> Bringing this back up.
>
> I don't think we have any reason to hold up renaming the version. We can
> have a separate discussion about what upgrade paths are s
+1 from me for that proposal.
On Apr 8, 2025 at 2:51:09 PM, Ekaterina Dimitrova
wrote:
> I’d say we mimic the current CASSANDRA tickets handling plus adding to the
> #cassandra-sidecar. That means:
>
> 1) Open and close notifications to #cassandra-dev and #cassandra-sidecar
> 2) all other notif
+1
On Mar 18, 2025 at 3:13:09 AM, Mick Semb Wever wrote:
> (general@incubator cc'd)
>
> Please vote on the acceptance of the Spark-Cassandra-Connector and its
> IP Clearance:
>
> https://incubator.apache.org/ip-clearance/cassandra-spark-cassandra-connector.html
>
> All consent from original aut
+1
On Sun, Mar 9, 2025 at 8:03 AM Brandon Williams wrote:
> +1
>
> Kind Regards,
> Brandon
>
> On Sun, Mar 9, 2025 at 7:18 AM Mick Semb Wever wrote:
> >
> > Please vote on the acceptance of the Cassandra Cluster Manager (CCM)
> > and its IP Clearance:
> > https://incubator.apache.org/ip-clearan
rging it
>>
>> On Wed, Mar 5, 2025, at 12:22 PM, Patrick McFadin wrote:
>>
>> You have my +1
>>
>> On Wed, Mar 5, 2025 at 12:16 PM Benedict wrote:
>> >
>> > Correct, these caveats should only apply to tables that have opted-in
>> to accord.
So great to see all this hard work about to pay off!
On the questions/concerns front, the only concern I would have towards
merging this to trunk is if any of the caveats apply when someone is not
using Accord. Assuming they only apply when the feature flag is enabled, I
see no reason not to get
Congrats Caleb!
On Feb 20, 2025 at 4:06:19 PM, Jon Haddad wrote:
> The PMC for Apache Cassandra is delighted to announce that Caleb Rackliffe
> has joined it's membership!
>
> Caleb has been a member of the community for 10 years and is one of the
> most active committers on the project.
>
> Ple
Congrats to both of you! Thank you for the contributions you have been
making to the project!
On Feb 20, 2025 at 11:47:05 AM, Štefan Miklošovič
wrote:
> The Project Management Committee (PMC) for Apache Cassandra
> has invited Maxwell Guo and Dmitry Konstantinov to become committers and
> we ar
Thanks all! Excited to continue being a part of the project in this new
role.
-Jeremiah Jordan
On Feb 14, 2025 at 12:23:17 PM, Francisco Guerrero
wrote:
> Congrats!
>
> On 2025/02/14 18:20:02 Yifan Cai wrote:
>
> Congrats!
>
>
> On Fri, Feb 14, 2025 at 10:
Given we do not have any end users that use SimpleClient, and now that the
java driver is part of the project, I would suggest we focus more on use of
the java driver.
I think it is important that the end to end integration tests that are
using a driver be using one that actual clients will use.
AFAIK this EMPTY stuff goes back to thrift days. We let people insert
these zero length values back then, so we have to support those zero length
values existing for ever :/.
How useful is such a distinction? I don’t know. Is anybody actually doing
this? Well Andres brought up
https://issues.
Having thought about this in the past, some options that have come up in
those discussions were:
1. Constraints forcing users to always specify a value for a given
column or all columns. Only allow NOT NULL for columns with such a
constraint applied.
2. Similar to the above but only
Rather than changing the default, I would be +1 to making a system
property so that an operator who knows what they are doing could change
it. A little hesitant of just changing it outright in a patch release.
On Feb 6, 2025 at 1:10:28 PM, Caleb Rackliffe
wrote:
> Hey everyone!
>
> I'll keep
On Jan 29, 2025 at 3:32:13 PM, Josh McKenzie wrote:
> My opinion is that it would be valuable to take this discussion as a
> forcing function to determine how we plan to handle releases broadly to
> answer the "5.1 should be 6.0" question. Assuming we move away from ad hoc
> per-release debate. I
This got way off topic from 5.1 should be 6.0, so maybe there should be a
new DISCUSS thread with the correct title to have a discussion around
codifying our upgrade paths?
FWIW this mostly agrees with my thoughts around upgrade support.
T-2 online upgrade supported, T-1 API compatible, deprecat
For commit log archiving we already have the concept of “commands” to be
executed. Maybe a similar concept would be useful for snapshots? Maybe a
new “user snapshot with command” nodetool action could be added. The
server would make its usual hard links inside a snapshot folder and then it
could
aleb Rackliffe
> wrote:
>
>> You mean like to control the tokenization/analysis of query terms?
>>
>> On Fri, Dec 20, 2024 at 4:38 PM Jeremiah Jordan <
>> jeremiah.jor...@gmail.com> wrote:
>>
>>> Rather than WITH INDEX/WITHOUT INDEX what about W
Rather than WITH INDEX/WITHOUT INDEX what about WITH OPTIONS {}. If we
move into allowing analysis/tokenization on indexed items, then a more
general WITH OPTIONS would be useful for that too. That would let us add
any other new options to a SELECT without needing to modify the grammar
further.
>
> TL;DR - in progress migration off 2.2 to 5.0 is annoying as there were
>> different bugs in the past we have to support again. Out of process
>> migration to me feels far more plausible, but feels annoying without
>> splitting off our reader/writer… doable… just more annoying…
>
>
This is your
My expectation is that in trunk SCM CASSANDRA_4 would change to SCM
CASSANDRA_5. I think we should be striving to support full
downgrade/rollback ability to the previous major version from trunk.
With TCM I would expect that when running in CASSANDRA_5 mode that
initializing TCM would not be poss
uence/pages/viewpage.action?pageId=199530302#Patching,versioning,andLTSreleases-Versioningandtargeting
>>> :
>>> > >>
>>> > >> That's consistent w/semver itself: link:
>>> > >>
>>> > >> Given a version number MAJOR.
I agree with Aleksey and Patrick. We should define terminology and then
stick to it. My preferred list would be:
1. Preview - Ready to be tried by end users but has caveats and most
likely is not api stable.
2. Beta - Feature complete/API stable but has not had enough testing to
be
The question is if we are signaling compatibility or purely marketing with
the release number.
We dropped compatibility with a few things in 5.0, which was the reason for
the .0 rather than 4.2. I don’t know if we are breaking any compatibility
with current trunk? Though maybe some of the TCM st
I think you are talking about the SASL handshake? The authenticator can
override the SASL handler for the connections. The negotiating authenticator
just needs to implement that override? You can then implement the flow you
mentioned.
At DataStax we do basically exactly that to support negoti
monolith has always been a pain point. Is there anyway it makes sense for
this to be an external process rather than a new thread pool inside the C*
process?
-Jeremiah Jordan
On Oct 18, 2024 at 2:58:15 PM, Mick Semb Wever wrote:
>
> This is looking strong, thanks Jaydeep.
>
> I would
Did we add new metrics for index queries? The only issue I see is that
this change will mix index queries into the regular read metrics, where
before they were in the range metrics, so maybe some changes to metrics
should go with it. But I think this is a good change over all.
On Oct 1, 2024 at
I don’t really have an opinion on re-writing the existing one vs closing
that and making a new one.
But I do think we should have some CEP describing the "1.0 shippable
version" of the side car that is being proposed, then it can have a VOTE
thread, and there will be no issues voting the release m
> When it comes to alternatives, what about logback + slf4j? It has
> appenders where we want, it is sync / async, we can code some nio appender
> too I guess, it logs it as text into a file so we do not need any special
> tooling to review that. For tailing which Chronicle also offers, I guess
> "
movements can cause this, and that nodes can be rejecting writes when they
> are in fact correct hence causing “over-eager unavailability”. And
> furthermore, point people to TCM.
>
>
>
> On Thu, 12 Sept 2024 at 23:36, Jeremiah Jordan
> wrote:
>
>> JD we know it ha
>
> JD we know it had nothing to do with range movements and could/should have
> been prevented far simpler with operational correctness/checks.
>
“Be better” is not the answer. Also I think you are confusing our
incidents, the out of range token issue we saw was not because of an
operational “oop
Congrats Joey!
On Jul 24, 2024 at 10:12:21 AM, Abhijeet Dubey
wrote:
> Congratulations Joey :)
>
> On Wed, Jul 24, 2024 at 8:38 PM Josh McKenzie
> wrote:
>
>> Congrats Joey!
>>
>> On Wed, Jul 24, 2024, at 10:55 AM, Abe Ratnofsky wrote:
>>
>> Congratulations!
>>
>>
>>
>
> --
> *Abhijeet*
>
MAXWRITETIME yet.
Jeremiah Jordan
e. jerem...@datastax.com
w. www.datastax.com
On Jun 20, 2024 at 11:46:08 AM, Štefan Miklošovič
wrote:
> List,
>
> we need your opinions about CASSANDRA-18078.
>
> That ticket is about the removal of MAXWRITETIME function which was added
> in CASSANDRA
Welcome to the Chair role Dinesh! Congrats!
On Jun 20, 2024 at 10:50:37 AM, Josh McKenzie wrote:
> Another PMC Chair baton pass incoming! On behalf of the Apache Cassandra
> Project Management Committee (PMC) I would like to welcome and congratulate
> our next PMC Chair Dinesh Joshi (djoshi).
Congrats all!
On Apr 17, 2024 at 12:10:11 PM, Benjamin Lerer wrote:
> The Apache Cassandra PMC is pleased to announce that Alexandre Dutra,
> Andrew Tolbert, Bret McGuire and Olivier Michallat have accepted the
> invitation to become committers on the java driver sub-project.
>
> Thanks for you
Congrats!
On Feb 21, 2024 at 2:46:14 PM, Josh McKenzie wrote:
> The Apache Cassandra PMC is pleased to announce that Brad Schoening has
> accepted
> the invitation to become a committer.
>
> Your work on the integrated python driver, launch script environment, and
> tests
> has been a big help t
Here was the thread where it was removed:lists.apache.orgOn Jan 22, 2024, at 12:37 PM, J. D. Jordan wrote:I think we used to have this and removed them because it was breaking the encryption signature on messages or something which meant they were very likely to be treated as spam?Not saying we c
Congrats Maxim! Thanks for all of your contributions!
On Jan 8, 2024 at 12:19:04 PM, Josh McKenzie wrote:
> The Apache Cassandra PMC is pleased to announce that Maxim Muzafarov has
> accepted
> the invitation to become a committer.
>
> Thanks for all the hard work and collaboration on the proj
>
> from a maintenance and
> integration testing perspective I think it would be better to keep the
> ohc in-tree, so we will be aware of any issues immediately after the
> full CI run.
>From the original email bringing OHC in tree is not an option because the
current maintainer is not interested
Congrats Mike! Thanks for all your work on SAI and Vector index. Well
deserved!
On Dec 8, 2023 at 8:52:07 AM, Brandon Williams wrote:
> Congratulations Mike!
>
> Kind Regards,
> Brandon
>
> On Fri, Dec 8, 2023 at 8:41 AM Benjamin Lerer wrote:
>
>
> The PMC members are pleased to announce tha
Again I am coming at this from the operator/end user perspective.
Creating a metrics dashboard, and then I am looking at those metrics to
understand what my queries are doing. We have coordinator query level
metrics, and then we have lower level table metrics on the replicas. I
want to be able t
there's pros and cons to both approaches.
>
> All that said, I'm in favor of us continuing with this as a valid and
> ratified vote (technical norms == committer binding + simple majority). If
> we want to open a formal discussion about instead considering that a
> procedura
>
> My reading of ASF policy is that directing users to CEP preview releases
> that are not formally voted upon is not acceptable. The policy you quote
> indicates they should be intended only for active participants on dev@,
> whereas our explicit intention is to enable them to be advertised to us
re
> merged with failing or flaky tests.
>
> Either way, the vote and discussion specifically allow for this to be
> overridden.
>
> 🤷♀️
>
> On 31 Oct 2023, at 16:29, Jeremiah Jordan
> wrote:
>
>
> I never said there was a need for green CI for alpha.
cassandra-5.1 and/or
>>>> naming a preview release something other than 5.1-alpha1.
>>>>
>>>> But… the codebases and release process (and upgrade tests) do not
>>>> currently support releases with qualifiers that are not alpha, beta, or
>>>
ob that'd do
>> nightly docker container builds on trunk + feature branches, archived for N
>> days, and we make that generally known to the dev@ list here so folks
>> that want to poke at the current state of trunk or other branches could do
>> so with very low friction.
ect
> release to create a docker image.
>
> On Tue, Oct 24, 2023 at 11:54 AM Jeremiah Jordan <
> jeremiah.jor...@gmail.com> wrote:
>
>> If we decide to go the route of not merging TCM to the 5.0 branch. Do we
>> actually need to immediately cut a 5.1 branch? Can we work
If we decide to go the route of not merging TCM to the 5.0 branch. Do we
actually need to immediately cut a 5.1 branch? Can we work on stabilizing
things while it is in trunk and cut the 5.1 branch when we actually think
we are near releasing? I don’t see any reason we can not cut “preview”
art
+1 from me assuming we have tickets and two committer +1’s on them for
everything being committed to trunk, and CI is working/passing before it
merges. The usual things, but I want to make sure we do not compromise on
any of them as we try to “move fast” here.
-Jeremiah Jordan
On Oct 23, 2023
Agreed. -1 on selectively removing any of the libs. But +1 for removing
the whole thing if it is no longer used.
-Jeremiah
On Oct 20, 2023 at 9:28:55 AM, Mick Semb Wever wrote:
> Does anyone see any reason _not_ to do this?
>>
>
>
> Thanks for bring this to dev@
>
> I see reason not to do it
I think this is covered by the grant agreement?
https://www.apache.org/licenses/software-grant-template.pdf
2. Licensor represents that, to Licensor's knowledge, Licensor is
legally entitled to grant the above license. Licensor agrees to notify
the Foundation of any facts or circumstances of whi
+1 nb.
Thanks to everyone who has made this happen.
On Oct 2, 2023 at 11:52:47 PM, Mick Semb Wever wrote:
> The donation of the java-driver is ready for its IP Clearance vote.
> https://incubator.apache.org/ip-clearance/cassandra-java-driver.html
>
> The SGA has been sent to the ASF. This doe
I wonder if it can easily be replaced with Apache open-nlp? It also
provides an implementation of GloVe.
https://opennlp.apache.org/docs/2.3.0/apidocs/opennlp-tools/opennlp/tools/util/wordvector/Glove.html
On Sep 13, 2023 at 1:17:46 PM, Benedict wrote:
> There’s a distinction for spotbugs an
I don’t think anyone wants to remove the javadocs. This thread is about
removing the broken ant task which generates html files from them.
+1 from me on removing the ant task. If someone feels the task is useful
they can always implement one that does not crash and add it back.
-Jeremiah
On A
SASI just uses “=“ for the tokenized equality matching, which is the exact
thing this discussion is about changing/not liking.
> On Aug 2, 2023, at 7:18 PM, J. D. Jordan wrote:
>
> I do not think LIKE actually applies here. LIKE is used for prefix,
> contains, or suffix searches in SASI depen
I had a discussion with Mick on slack. His concern is not with enabling
ACCP. His concern is around the testing of the new C* yaml config code
which is included in the patch that is used to decide if ACCP should be
enabled or not, and if startup should fail if it can’t be enabled.
I agree. We s
+1 for the side car being the right location.
-Jeremiah
On Jul 25, 2023 at 1:16:14 PM, Chris Lohfink wrote:
> I think a CEP is the next step. Considering the number of companies
> involved, this might necessitate several drafts and rounds of discussions.
> I appreciate your initiative in start
Yes. Great to get this work merged. Thanks to everyone who worked on it
and to Ekaterina for leading the charge!
-Jeremiah
On Jul 24, 2023 at 9:27:10 PM, C. Scott Andreas
wrote:
> Ekaterina, thank you for spearheading JDK17 support for Apache Cassandra!
> Exciting to get to this point.
>
> -
want to give them the power to manage identities.
Jeremiah Jordan
e. jerem...@datastax.com
w. www.datastax.com
On Jun 30, 2023 at 1:35:41 PM, Dinesh Joshi wrote:
> Yuki, Jeremiah both are fair points. The mental model we're using for
> mTLS authentication is slightly different.
>
&
+100 I support making generate-idea-files auto setup everything in
IntelliJ for you. If you post a diff, I will test it.
On this proposal, I don’t really have an opinion one way or the other about
what the default is for local "ant jar”, if its slow I will figure out how
to turn it off, if its f
I like the idea of extending CREATE ROLE rather than adding a brand new ADD
IDENTITY syntax. Not sure how that can line up with one to many
relationships for an identity, but maybe that can just be done through role
hierarchy?
In either case, I don’t think IDENTITY related operations should be ti
Yes. -1 on forcing the patch release version, and possibly minor version,
for anything that is not absolutely necessary to do so. Especially for
things like Java or Python version, I would hope we just install the latest
Java 8, Java 11, or Java 17 JDK for the platform the image is built from
an
+1 from me.
On Jun 15, 2023 at 1:01:01 PM, Ekaterina Dimitrova
wrote:
> Hi everyone,
> Happy Thursday!
> Some time ago, Jacek raised the point that ant eclipse-warnings is generating
> too many false positives and not really working as expected. (CASSANDRA-18239)
>
> Reminder: ant eclipse-warn
+1 nb
On Jun 13, 2023 at 9:14:35 AM, Jeremy Hanna
wrote:
> Calling for a vote on CEP-8 [1].
>
> To clarify the intent, as Benjamin said in the discussion thread [2], the
> goal of this vote is simply to ensure that the community is in favor of
> the donation. Nothing more.
> The plan is to intr
As long as it is valid in the paging protocol to return a short page, but
still say “there are more pages”, I think that is fine to do that. For an
actual LIMIT that is part of the user query, I think the server must always
have returned all data that fits into the LIMIT when all pages have been
I have seen this same behavior in the past as well and came to the same
conclusions of where the issue is. It would be good to write this up in a
ticket. Giving people the option of using the DynamicEndpointSnitch to order
batch log replica selection could mitigate this exact issue, but may ha
Thanks Nate! And welcome to the role Mick!
> On Jul 11, 2022, at 7:54 AM, Paulo Motta wrote:
>
>
> Hi,
>
> I wanted to announce on behalf of the Apache Cassandra Project Management
> Committee (PMC) that Nate McCall (zznate) has stepped down from the PMC chair
> role. Thank you Nate for all
the CEP.
Thanks,
-Jeremiah Jordan
Hi Stefan,
That idea is not related to this CEP which is about the file formats of the
sstables, not file system access. But you should take a look at the work
recently committed in https://issues.apache.org/jira/browse/CASSANDRA-16926
to switch to using java.nio.file.Path for file access. This s
If you don’t know what you are doing you will have one rack which will also be
safe. If you are setting up racks then you most likely read something about
doing that, and should also be fine.
This discussion has gone off the rails 100 times with what ifs that are
“letting perfect be the enemy of
Can’t you currently open a PR with the right commit message, have do review
there with all comments posted back to JIRA, run CI on it and then merge it
closing the PR? This is the basic workflow you are proposing yes?
It is the reviewer and authors job to make sure CI ran and didn’t introduce n
Clients do negotiate the protocol version they use when connecting. If the
server bumped the protocol version then this larger paging state could be part
of the new protocol version. But that doesn’t solve the problem for existing
versions.
The special treatment of Integer.MAX_VALUE can be done
My suggestion would be to keep trunk on the latest LTS by default, but with
compatibility with the latest release if possible. Since Oracle LTS releases
are every 3 years, I would not want to tie us to that release cycle?
So until Java 11 is out that would mean trunk should work under Java 8, wi
that I should think about the case of data removing.
>
> I currently don't really care about TTL's, but its the case about I should
> think, thx.
>
> Jeremiah Jordan, thx for notice, but I don't really get what are you mean
> about replica aggregation optimizat
Don’t forget about deleted and missing data. The bane of all on replica
aggregation optimization’s.
> On Jan 14, 2018, at 12:07 AM, Jeff Jirsa wrote:
>
>
> You’re right it’s not stored in metadata now. Adding this to metadata isn’t
> hard, it’s just hard to do it right where it’s useful to p
+1 non-binding. That requirement always seemed silly to me.
> On Mar 29, 2017, at 8:21 AM, Jason Brown wrote:
>
> Hey all,
>
> Following up my thread from a week or two ago (
> https://lists.apache.org/thread.html/0665f40c7213654e99817141972c003a2131aba7a1c63d6765db75c5@%3Cdev.cassandra.apache.
In the original tick tock plan we would not have kept 4.0.x around. So I am
proposing a change for that and then we label the 3.x and 4.x releases as
"development releases" or some other thing and have "yearly" LTS releases with
.0.x.
Those are similar to the previous 1.2/2.0/2.1/2.2 and we are
As I understand it "COMPACT STORAGE" only has meaning in the CQL parser for
backwards compatibility as of 3.0. The on disk storage is not affected by its
usage.
> On Apr 11, 2016, at 3:33 PM, Benedict Elliott Smith
> wrote:
>
> Compact storage should really have been named "not wasteful stora
Cassandra-jdbc can do cql3 as well as cql2. The rub (and why I would never
recommend it) is that it does cql3 over thrift. So you lose out on all the
native protocol features.
> On May 11, 2015, at 2:53 PM, Brian Hess wrote:
>
> One thing that does jump out at me, though, is about CQL2. As
Everything should be good now. Thanks!
> On Aug 11, 2014, at 9:34 AM, Sylvain Lebresne wrote:
>
> Ok, ok, closing this vote for now. We'll re-roll as soon as the pig stuff
> are fixed.
>
>
> On Fri, Aug 8, 2014 at 10:07 PM, Jeremiah D Jordan
> wrote:
>
>> I'm -1 on this until we get CqlRecor
.com]
Sent: Thursday, October 25, 2012 4:09 PM
To: dev@cassandra.apache.org
Subject: Re: Write Timestamps
On Wed, Oct 24, 2012 at 9:13 PM, Jeremiah Jordan
wrote:
> How are you doing the write? CQL or Thrift? In thrift, the client specifies
> the timestamp, and you should always be seeing that
How are you doing the write? CQL or Thrift? In thrift, the client specifies
the timestamp, and you should always be seeing that as the timestamp. In CQL,
the CQL layer on the server adds the timestamp. I am less familiar with the
CQL code, maybe something screwy is going on there. 1.1.6 is
Cluster nodes don't talk on 9160. Pretty sure they talk on "storage_port:
7000" from the yaml file.
-Jeremiah
From: Niteesh kumar [nitees...@directi.com]
Sent: Tuesday, October 02, 2012 4:52 AM
To: dev@cassandra.apache.org
Subject: persistent connection
en throwing away the majority of the data I
pulled back that doesn't belong to o1 and o5
-Jeremiah
From: Jonathan Ellis [jbel...@gmail.com]
Sent: Thursday, March 29, 2012 11:23 AM
To: dev@cassandra.apache.org
Subject: Re: Document storage
On Thu, Mar 29,
Its not clear what 3647 actually is, there is no code attached, and no real
example in it.
Aside from that, the reason this would be useful to me (if we could get
indexing of attributes working), is that I already have my data in
JSON/Thrift/ProtoBuff, depending how large the data is, it isn't
Its not clear what 3647 actually is, there is no code attached, and no real
example in it.
Aside from that, the reason this would be useful to me (if we could get
indexing of attributes working), is that I already have my data in
JSON/Thrift/ProtoBuff, depending how large the data is, it isn't
Sounds interesting to me. I looked into adding protocol buffer support at one
point, and it didn't look like it would be too much work. The tricky part was
I also wanted to add indexing support for attributes of the inserted protocol
buffers. That looked a little trickier, but still not impos
whole cluster, not just your neighbor. etc. etc.
-Jeremiah Jordan
From: Rick Branson [rbran...@datastax.com]
Sent: Monday, March 19, 2012 5:16 PM
To: dev@cassandra.apache.org
Subject: Re: RFC: Cassandra Virtual Nodes
I think if we could go back and r
10-15 KS should be fine. The issue is when you want to have hundreds or
thousands of KS/CF.
-Jeremiah
-Original Message-
From: Subrahmanya Harve [mailto:subrahmanyaha...@gmail.com]
Sent: Thursday, February 02, 2012 1:43 AM
To: dev@cassandra.apache.org
Subject: Re: Queries on AuthN and A
Bring it up here: https://issues.apache.org/jira/browse/INFRA
On 01/10/2012 11:40 PM, Dave Brosius wrote:
Greetings,
I wanted to mention this to folks who may be running into this
issue. A user on IRC reporting that cloning the cassandra repo on the
apache servers
http://git-wip-us.apach
Unless you need the new features, you don't need to upgrade. And the current
version won't stop getting updates. As mentioned in the thread where the
project moved to a 4 month major version cycle, smaller changes between major
versions means they will be more stable. Even with the smaller cy
Another option is to have multiple threads reading from the queue and
writing to their own commit log files. If you have multiple commit log
directories with each having its own task writing to it, you can keep
the "only sequential writes" optimization. Multiple writers to one disk
only makes
+1 for a separate jar (and a second download link that doesn't include this
jar, though I would make the primary link include it with BIG BOLD PRINT saying
it is in there)
+1 for a config option to turn off auto-post (defaulted on in the download that
has the jar)
+1 for a nodetool command to du
Ah =). Searching "cassandra-dbapi2" on pypi doesn't find it, guess they don't
index the homepage links...
On Nov 12, 2011, at 10:45 AM, Jonathan Ellis wrote:
> http://pypi.python.org/pypi/cql/
>
> On Sat, Nov 12, 2011 at 10:29 AM, Jeremiah Jordan
> wrote:
Someone should add it to pypi
On Nov 12, 2011, at 10:25 AM, Jonathan Ellis wrote:
> http://code.google.com/a/apache-extras.org/p/cassandra-dbapi2/issues/detail?id=6
> and
> http://code.google.com/a/apache-extras.org/p/cassandra-dbapi2/issues/detail?id=7
> will address the dependency problem ade
I am pretty sure the way you have K1 configured it will be placed across
both DC's as if you had large ring. If you want it only in DC1 you need
to say DC1:1, DC2:0.
If you are writing and reading at ONE you are not guaranteed to get the
data if RF > 1. If RF = 2, and you write with ONE, you d
Been a while since 0.7.6 and a bunch of stuff has been fixed in JIRA,
including https://issues.apache.org/jira/browse/CASSANDRA-2654 which I
think may be affecting some of our servers.
Jeremiah Jordan
Application Developer
Morningstar, Inc.
Morningstar
1 - 100 of 105 matches
Mail list logo
