[jira] [Commented] (CASSANDRA-16765) Update Cassandra build CI script for new website
[
https://issues.apache.org/jira/browse/CASSANDRA-16765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472437#comment-17472437
]
Anthony Grasso commented on CASSANDRA-16765:
> {color:#505f79}_It might be cumbersome to have to update the file after every
> release. Releases are a lot more frequent than release branches._{color}
{color:#505f79}_Is there a way that the run.sh could detect all releases
(>=3.11.2, >=4.0.2) ?_{color}
Yes, {{run.sh}} could detect releases. We do something similar in the [Anotra
YAML generation
script|https://github.com/apache/cassandra-website/blob/trunk/site-content/bin/site_yaml_generator.py#L35-L45].
However, I think I misunderstand the problem. My current understanding was we
generate documents for each branch (i.e. major version; 3.11, 4.0, etc).
I need help understanding the problem we want to solve. Do we want to build the
docs for each branch and tag (i.e. minor release version; 3.11.11, 4.0.1, etc)
or a subset of that?
> Update Cassandra build CI script for new website
>
>
> Key: CASSANDRA-16765
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16765
> Project: Cassandra
> Issue Type: Task
> Components: Build, CI, Documentation/Website
>Reporter: Anthony Grasso
>Assignee: Michael Semb Wever
>Priority: Normal
>
> Update the apache/cassandra-build repository has [.groovy job
> script|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy]
> to use the new tooling to build the website.
> The apache/cassandra-build repository has [.groovy job
> script|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy].
> It [builds and deploys the
> website|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy#L1255-L1268]
> to cassandra-website staging when the cassandra-website is updated.
> We need to change the commands in the .groovy script to at least rebuild the
> site when a change happens in the cassandra-website repository.
> It would be also good to build the docs when a change happens to doc/source
> directory in the cassandra repository.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16765) Update Cassandra build CI script for new website
[
https://issues.apache.org/jira/browse/CASSANDRA-16765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472433#comment-17472433
]
Anthony Grasso commented on CASSANDRA-16765:
> {color:#505f79}_Can we spin off separate tickets? The CI patch can go in, and
> get updates latter on._{color}
Works for me. I will complete the review of the CI changes. We can then work on
removing the CI hacks and fixing generation of the robots.txt, .htaccess, and
sitemap.xml files.
> Update Cassandra build CI script for new website
>
>
> Key: CASSANDRA-16765
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16765
> Project: Cassandra
> Issue Type: Task
> Components: Build, CI, Documentation/Website
>Reporter: Anthony Grasso
>Assignee: Michael Semb Wever
>Priority: Normal
>
> Update the apache/cassandra-build repository has [.groovy job
> script|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy]
> to use the new tooling to build the website.
> The apache/cassandra-build repository has [.groovy job
> script|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy].
> It [builds and deploys the
> website|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy#L1255-L1268]
> to cassandra-website staging when the cassandra-website is updated.
> We need to change the commands in the .groovy script to at least rebuild the
> site when a change happens in the cassandra-website repository.
> It would be also good to build the docs when a change happens to doc/source
> directory in the cassandra repository.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17221) Add Math functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472399#comment-17472399
]
Simon Chess commented on CASSANDRA-17221:
-
[~blerer] looks like you've marked it patch available for me, thank you.
> Add Math functions
> ---
>
> Key: CASSANDRA-17221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17221
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Labels: AdventCalendar2021, lhf
>
> We should add native Maths functions for the most common operations:
> * {{abs\(x)}} returns the absolute value of the x
> * {{exp\(x)}} returns the value of e (the base of natural logarithms) raised
> to the power of x
> * {{log\(x)}} returns the natural logarithm (base e) of x
> * {{log10\(x)}} returns the base-10 logarithm of x
> * {{round\(x)}} returns the closest integer to x
> +Additional information for newcomers:+
> The new functions should be put in a new class {{MathFcts}} similar to
> {{TimeFcts}}.
> The {{MathsFcts.all()}} method should be called in
> {{SystemKeyspace.functions}}
> The unit tests for the functions should be put in a {{MathFctsTest}} similar
> to {{TimeFctsTest}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17068) Failed inbound internode authentication failures generate ugly warning with stack trace
[ https://issues.apache.org/jira/browse/CASSANDRA-17068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472365#comment-17472365 ] Jon Meredith edited comment on CASSANDRA-17068 at 1/11/22, 12:45 AM: - [Branch|https://github.com/jonmeredith/cassandra/tree/C17068-downgrade-inbound-internode-auth-error-logs] [Trunk PR|https://github.com/apache/cassandra/pull/1384] [CircleCI|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=C17068-downgrade-inbound-internode-auth-error-logs=all] was (Author: jonmeredith): [Branch|https://github.com/jonmeredith/cassandra/tree/C17068-downgrade-inbound-internode-auth-error-logs] [Trunk PR|https://github.com/apache/cassandra/pull/1384] [CircleCI|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=/C17068-downgrade-inbound-internode-auth-error-logs=all] > Failed inbound internode authentication failures generate ugly warning with > stack trace > --- > > Key: CASSANDRA-17068 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17068 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Internode >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > Fix For: 4.0.x > > > Inbound connections can come from anywhere and the warning / stack trace is > unhelpful so I'd like to downgrade to a simple single-line INFO message when > authorization fails to reduce clutter in the logs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17068) Failed inbound internode authentication failures generate ugly warning with stack trace
[ https://issues.apache.org/jira/browse/CASSANDRA-17068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472365#comment-17472365 ] Jon Meredith edited comment on CASSANDRA-17068 at 1/11/22, 12:45 AM: - [Branch|https://github.com/jonmeredith/cassandra/tree/C17068-downgrade-inbound-internode-auth-error-logs] [Trunk PR|https://github.com/apache/cassandra/pull/1384] [CircleCI|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=/C17068-downgrade-inbound-internode-auth-error-logs=all] was (Author: jonmeredith): [Branch|https://github.com/jonmeredith/cassandra/tree/C17068-downgrade-inbound-internode-auth-error-logs] [Trunk PR|https://github.com/apache/cassandra/pull/1384] > Failed inbound internode authentication failures generate ugly warning with > stack trace > --- > > Key: CASSANDRA-17068 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17068 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Internode >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > Fix For: 4.0.x > > > Inbound connections can come from anywhere and the warning / stack trace is > unhelpful so I'd like to downgrade to a simple single-line INFO message when > authorization fails to reduce clutter in the logs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17254) nodetool toppartitions can fail because ByteBuffer.array() returns more bytes than would be considered valid by UTF8Serializer.validate
[
https://issues.apache.org/jira/browse/CASSANDRA-17254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472381#comment-17472381
]
Jordan West commented on CASSANDRA-17254:
-
https://github.com/apache/cassandra/compare/cassandra-3.0...jrwest:jwest/17254-3.0
> nodetool toppartitions can fail because ByteBuffer.array() returns more bytes
> than would be considered valid by UTF8Serializer.validate
> ---
>
> Key: CASSANDRA-17254
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17254
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> The error below is caused by the use of
> [{{ByteBuffer.array()}}|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L1628].
> Doing so not only makes the hex key potentially incorrect but causes invalid
> data to be passed to {{AbstractType.getString}} and ultimately
> {{UTF8Validator.validate}}.
> {code}
> error: String didn't validate.
> -- StackTrace --
> org.apache.cassandra.serializers.MarshalException: String didn't validate.
> at
> org.apache.cassandra.serializers.UTF8Serializer.validate(UTF8Serializer.java:35)
> at
> org.apache.cassandra.db.marshal.AbstractType.getString(AbstractType.java:129)
> at
> org.apache.cassandra.db.ColumnFamilyStore.finishLocalSampling(ColumnFamilyStore.java:1633)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17251) USING writetime + ttl is non-idempotent leading to non-deterministic merge iteration results
[
https://issues.apache.org/jira/browse/CASSANDRA-17251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472374#comment-17472374
]
Jordan West edited comment on CASSANDRA-17251 at 1/11/22, 12:43 AM:
https://github.com/apache/cassandra/compare/cassandra-3.0...jrwest:jwest/17251-3.0
was (Author: jrwest):
https://github.com/apache/cassandra/compare/trunk...jrwest:jwest/17251-3.0
> USING writetime + ttl is non-idempotent leading to non-deterministic merge
> iteration results
>
>
> Key: CASSANDRA-17251
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17251
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> The combination of {{USING writetime = timestamp and ttl = ttl}} can result
> in non-deterministic MergeIterator results causing DigestMismatchExceptions
> and increased latencies. The increased latencies are caused by additional
> round trips due to the digest mismatch as well as read repair rewriting the
> data. The additional writes lead to an increase in the number of sstables the
> key is stored in and must be scanned on read.
> The order of events is:
> 1. for a given partition a write is performed with {{USING timestamp =
> sometime and ttl = ttl1}}.
> 2. Cassandra records this write with timestamp = sometime, ttl = ttl1,
> expires_at = now + ttl1
> 3. after N seconds, for the same partition, another write is performed with
> {{USING timestamp = sometime and ttl = ttl2 where ttl2 = ttl1 - N}}. This
> write only makes it to a subset of replicas* for some reason (e.g. partial
> write, node down, etc).
> 4. Cassandra records this write with timestamp = sometime, ttl = ttl2,
> expires_at = now + ttl2. Its important to note that at this point, expires_at
> in 2 above is equal to expires at here. This is because it is calculated
> relative to the current write time not the provided timestamp and the ttl has
> been adjusted by the time passed. This write also makes it to a subset of
> replicas*.
> 5. A read of the data is performed.
> 5a. The MergeIterator resolves conflicts locally (accross sstables) using
> {{Conflicts.resolveRegular}} or {{Cells.resolveRegular}}. The resolution
> takes into account the write timestamp , the liveness of the cell, the values
> themselves, and how much time is left to live via the expires_at field. In
> this scenario, all of these fields are equal, leading to Cassandra picking
> the sstable "on the right" – this is non-deterministic. The only item that
> differs is the ttl itself.
> 5b. One node returns the non-deterministically chosen value for the row, the
> other two calculate and send a digest to the coordinator. The digest includes
> the relative ttl field which may not match. This results in a
> DigestMismatchException at the coordinator.
> 6. Read repair is triggered
> *NOTE: its not strictly necessary for the write to make it to a subset of
> replicas. sstables can also be ordered in random orders for reasons like
> compaction or repair when returned from the live set which can lead to the
> same behavior. This also affects repair from what we can tell.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17252) ConnectionLimitHandler may leaks connection count if remote connection drops
[
https://issues.apache.org/jira/browse/CASSANDRA-17252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Meredith updated CASSANDRA-17252:
-
Test and Documentation Plan: Rely on existing client tests. The exception
is hard to reliably provoke - I ended up running many iterations on my laptop
with breakpoints set to hit the null while looping connections.
Status: Patch Available (was: Open)
Branches
[3.0|https://github.com/jonmeredith/cassandra/tree/C17252-connection-limit-handler-may-leak-per-ip-count-3.0]
[3.11|https://github.com/jonmeredith/cassandra/tree/C17252-connection-limit-handler-may-leak-per-ip-count-3.11]
[4.0|https://github.com/jonmeredith/cassandra/tree/C17252-connection-limit-handler-may-leak-per-ip-count-4.0]
[trunk|https://github.com/jonmeredith/cassandra/tree/C17252-connection-limit-handler-may-leak-per-ip-count-trunk]
[PR for 3.0/3.11 version|https://github.com/apache/cassandra/pull/1385]
[PR for 4.0/trunk version|https://github.com/apache/cassandra/pull/1386]
noSpamLogger is the only difference.
CircleCI
[3.0|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=C17252-connection-limit-handler-may-leak-per-ip-count-3.0=all]
[3.11|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=C17252-connection-limit-handler-may-leak-per-ip-count-3.11=all]
[4.0|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=C17252-connection-limit-handler-may-leak-per-ip-count-4.0=all]
[trunk|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=C17252-connection-limit-handler-may-leak-per-ip-count-trunk=all]
> ConnectionLimitHandler may leaks connection count if remote connection drops
>
>
> Key: CASSANDRA-17252
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17252
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> In some cases, Netty does not return the original IP used for per-IP counting
> when the channel becomes inactive,
> which throws an NPE before decrementing the active per-IP count.
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.transport.ConnectionLimitHandler.channelInactive(ConnectionLimitHandler.java:101)
>at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:262)
>at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:248)
>at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:241)
>at
> io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:389)
>at
> io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:354)
>at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:262)
>at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:248)
>at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:241)
>at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1405)
>at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:262)
>at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:248)
>at
> io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:901)
>at
> io.netty.channel.AbstractChannel$AbstractUnsafe$8.run(AbstractChannel.java:819)
>at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
>at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
>at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:497)
>at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
>at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
>at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail:
[jira] [Updated] (CASSANDRA-17254) nodetool toppartitions can fail because ByteBuffer.array() returns more bytes than would be considered valid by UTF8Serializer.validate
[
https://issues.apache.org/jira/browse/CASSANDRA-17254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan West updated CASSANDRA-17254:
Bug Category: Parent values: Degradation(12984)Level 1 values: Other
Exception(12998)
Complexity: Normal
Component/s: Tool/nodetool
Discovered By: User Report
Fix Version/s: 3.0.x
3.11.x
Severity: Normal
Status: Open (was: Triage Needed)
> nodetool toppartitions can fail because ByteBuffer.array() returns more bytes
> than would be considered valid by UTF8Serializer.validate
> ---
>
> Key: CASSANDRA-17254
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17254
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> The error below is caused by the use of
> [{{ByteBuffer.array()}}|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L1628].
> Doing so not only makes the hex key potentially incorrect but causes invalid
> data to be passed to {{AbstractType.getString}} and ultimately
> {{UTF8Validator.validate}}.
> {code}
> error: String didn't validate.
> -- StackTrace --
> org.apache.cassandra.serializers.MarshalException: String didn't validate.
> at
> org.apache.cassandra.serializers.UTF8Serializer.validate(UTF8Serializer.java:35)
> at
> org.apache.cassandra.db.marshal.AbstractType.getString(AbstractType.java:129)
> at
> org.apache.cassandra.db.ColumnFamilyStore.finishLocalSampling(ColumnFamilyStore.java:1633)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17254) nodetool toppartitions can fail because ByteBuffer.array() returns more bytes than would be considered valid by UTF8Serializer.validate
Jordan West created CASSANDRA-17254:
---
Summary: nodetool toppartitions can fail because
ByteBuffer.array() returns more bytes than would be considered valid by
UTF8Serializer.validate
Key: CASSANDRA-17254
URL: https://issues.apache.org/jira/browse/CASSANDRA-17254
Project: Cassandra
Issue Type: Bug
Reporter: Jordan West
Assignee: Jordan West
The error below is caused by the use of
[{{ByteBuffer.array()}}|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L1628].
Doing so not only makes the hex key potentially incorrect but causes invalid
data to be passed to {{AbstractType.getString}} and ultimately
{{UTF8Validator.validate}}.
{code}
error: String didn't validate.
-- StackTrace --
org.apache.cassandra.serializers.MarshalException: String didn't validate.
at
org.apache.cassandra.serializers.UTF8Serializer.validate(UTF8Serializer.java:35)
at
org.apache.cassandra.db.marshal.AbstractType.getString(AbstractType.java:129)
at
org.apache.cassandra.db.ColumnFamilyStore.finishLocalSampling(ColumnFamilyStore.java:1633)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17253) Dead links on website
[ https://issues.apache.org/jira/browse/CASSANDRA-17253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472378#comment-17472378 ] Brandon Williams commented on CASSANDRA-17253: -- /cc [~mck] I can confirm these are broken. > Dead links on website > -- > > Key: CASSANDRA-17253 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17253 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Alexander Huerta >Priority: Normal > Attachments: Screen Shot 2022-01-10 at 7.27.32 PM.png > > > It seems all of the links in the Nav bar are dead. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17253) Dead links on website
[ https://issues.apache.org/jira/browse/CASSANDRA-17253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17253: - Bug Category: Parent values: Correctness(12982) Complexity: Normal Component/s: Documentation/Website Discovered By: User Report Severity: Normal Status: Open (was: Triage Needed) > Dead links on website > -- > > Key: CASSANDRA-17253 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17253 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Alexander Huerta >Priority: Normal > Attachments: Screen Shot 2022-01-10 at 7.27.32 PM.png > > > It seems all of the links in the Nav bar are dead. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17253) Dead links on website
Alexander Huerta created CASSANDRA-17253: Summary: Dead links on website Key: CASSANDRA-17253 URL: https://issues.apache.org/jira/browse/CASSANDRA-17253 Project: Cassandra Issue Type: Bug Reporter: Alexander Huerta Attachments: Screen Shot 2022-01-10 at 7.27.32 PM.png It seems all of the links in the Nav bar are dead. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17251) USING writetime + ttl is non-idempotent leading to non-deterministic merge iteration results
[
https://issues.apache.org/jira/browse/CASSANDRA-17251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan West updated CASSANDRA-17251:
Test and Documentation Plan: Added {{ConflictsTest}}
Status: Patch Available (was: Open)
https://github.com/apache/cassandra/compare/trunk...jrwest:jwest/17251-3.0
> USING writetime + ttl is non-idempotent leading to non-deterministic merge
> iteration results
>
>
> Key: CASSANDRA-17251
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17251
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> The combination of {{USING writetime = timestamp and ttl = ttl}} can result
> in non-deterministic MergeIterator results causing DigestMismatchExceptions
> and increased latencies. The increased latencies are caused by additional
> round trips due to the digest mismatch as well as read repair rewriting the
> data. The additional writes lead to an increase in the number of sstables the
> key is stored in and must be scanned on read.
> The order of events is:
> 1. for a given partition a write is performed with {{USING timestamp =
> sometime and ttl = ttl1}}.
> 2. Cassandra records this write with timestamp = sometime, ttl = ttl1,
> expires_at = now + ttl1
> 3. after N seconds, for the same partition, another write is performed with
> {{USING timestamp = sometime and ttl = ttl2 where ttl2 = ttl1 - N}}. This
> write only makes it to a subset of replicas* for some reason (e.g. partial
> write, node down, etc).
> 4. Cassandra records this write with timestamp = sometime, ttl = ttl2,
> expires_at = now + ttl2. Its important to note that at this point, expires_at
> in 2 above is equal to expires at here. This is because it is calculated
> relative to the current write time not the provided timestamp and the ttl has
> been adjusted by the time passed. This write also makes it to a subset of
> replicas*.
> 5. A read of the data is performed.
> 5a. The MergeIterator resolves conflicts locally (accross sstables) using
> {{Conflicts.resolveRegular}} or {{Cells.resolveRegular}}. The resolution
> takes into account the write timestamp , the liveness of the cell, the values
> themselves, and how much time is left to live via the expires_at field. In
> this scenario, all of these fields are equal, leading to Cassandra picking
> the sstable "on the right" – this is non-deterministic. The only item that
> differs is the ttl itself.
> 5b. One node returns the non-deterministically chosen value for the row, the
> other two calculate and send a digest to the coordinator. The digest includes
> the relative ttl field which may not match. This results in a
> DigestMismatchException at the coordinator.
> 6. Read repair is triggered
> *NOTE: its not strictly necessary for the write to make it to a subset of
> replicas. sstables can also be ordered in random orders for reasons like
> compaction or repair when returned from the live set which can lead to the
> same behavior. This also affects repair from what we can tell.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17252) ConnectionLimitHandler may leaks connection count if remote connection drops
[
https://issues.apache.org/jira/browse/CASSANDRA-17252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Meredith updated CASSANDRA-17252:
-
Bug Category: Parent values: Degradation(12984)Level 1 values: Resource
Management(12995)
Complexity: Normal
Component/s: Messaging/Client
Discovered By: User Report
Fix Version/s: 3.0.x
3.11.x
4.0.x
4.x
Severity: Low
Assignee: Jon Meredith
Status: Open (was: Triage Needed)
Looks like the issue was present since
initial commit in CASSANDRA-8086 / e56d9efb7c1 , but perhaps Netty behaved
differently pre-tcnative.
> ConnectionLimitHandler may leaks connection count if remote connection drops
>
>
> Key: CASSANDRA-17252
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17252
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> In some cases, Netty does not return the original IP used for per-IP counting
> when the channel becomes inactive,
> which throws an NPE before decrementing the active per-IP count.
> {code:java}
> java.lang.NullPointerException
> at
> org.apache.cassandra.transport.ConnectionLimitHandler.channelInactive(ConnectionLimitHandler.java:101)
>at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:262)
>at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:248)
>at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:241)
>at
> io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:389)
>at
> io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:354)
>at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:262)
>at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:248)
>at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:241)
>at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1405)
>at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:262)
>at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:248)
>at
> io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:901)
>at
> io.netty.channel.AbstractChannel$AbstractUnsafe$8.run(AbstractChannel.java:819)
>at
> io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
>at
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
>at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:497)
>at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
>at
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
>at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17252) ConnectionLimitHandler may leaks connection count if remote connection drops
Jon Meredith created CASSANDRA-17252:
Summary: ConnectionLimitHandler may leaks connection count if
remote connection drops
Key: CASSANDRA-17252
URL: https://issues.apache.org/jira/browse/CASSANDRA-17252
Project: Cassandra
Issue Type: Bug
Reporter: Jon Meredith
In some cases, Netty does not return the original IP used for per-IP counting
when the channel becomes inactive,
which throws an NPE before decrementing the active per-IP count.
{code:java}
java.lang.NullPointerException
at
org.apache.cassandra.transport.ConnectionLimitHandler.channelInactive(ConnectionLimitHandler.java:101)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:262)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:248)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:241)
at
io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:389)
at
io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:354)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:262)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:248)
at
io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:241)
at
io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1405)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:262)
at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:248)
at
io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:901)
at
io.netty.channel.AbstractChannel$AbstractUnsafe$8.run(AbstractChannel.java:819)
at
io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
at
io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:497)
at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
at
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:834)
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17251) USING writetime + ttl is non-idempotent leading to non-deterministic merge iteration results
[
https://issues.apache.org/jira/browse/CASSANDRA-17251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan West updated CASSANDRA-17251:
Bug Category: Parent values: Correctness(12982)Level 1 values:
Consistency(12989)
Complexity: Normal
Component/s: Local/Other
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> USING writetime + ttl is non-idempotent leading to non-deterministic merge
> iteration results
>
>
> Key: CASSANDRA-17251
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17251
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Other
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> The combination of {{USING writetime = timestamp and ttl = ttl}} can result
> in non-deterministic MergeIterator results causing DigestMismatchExceptions
> and increased latencies. The increased latencies are caused by additional
> round trips due to the digest mismatch as well as read repair rewriting the
> data. The additional writes lead to an increase in the number of sstables the
> key is stored in and must be scanned on read.
> The order of events is:
> 1. for a given partition a write is performed with {{USING timestamp =
> sometime and ttl = ttl1}}.
> 2. Cassandra records this write with timestamp = sometime, ttl = ttl1,
> expires_at = now + ttl1
> 3. after N seconds, for the same partition, another write is performed with
> {{USING timestamp = sometime and ttl = ttl2 where ttl2 = ttl1 - N}}. This
> write only makes it to a subset of replicas* for some reason (e.g. partial
> write, node down, etc).
> 4. Cassandra records this write with timestamp = sometime, ttl = ttl2,
> expires_at = now + ttl2. Its important to note that at this point, expires_at
> in 2 above is equal to expires at here. This is because it is calculated
> relative to the current write time not the provided timestamp and the ttl has
> been adjusted by the time passed. This write also makes it to a subset of
> replicas*.
> 5. A read of the data is performed.
> 5a. The MergeIterator resolves conflicts locally (accross sstables) using
> {{Conflicts.resolveRegular}} or {{Cells.resolveRegular}}. The resolution
> takes into account the write timestamp , the liveness of the cell, the values
> themselves, and how much time is left to live via the expires_at field. In
> this scenario, all of these fields are equal, leading to Cassandra picking
> the sstable "on the right" – this is non-deterministic. The only item that
> differs is the ttl itself.
> 5b. One node returns the non-deterministically chosen value for the row, the
> other two calculate and send a digest to the coordinator. The digest includes
> the relative ttl field which may not match. This results in a
> DigestMismatchException at the coordinator.
> 6. Read repair is triggered
> *NOTE: its not strictly necessary for the write to make it to a subset of
> replicas. sstables can also be ordered in random orders for reasons like
> compaction or repair when returned from the live set which can lead to the
> same behavior. This also affects repair from what we can tell.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17251) USING writetime + ttl is non-idempotent leading to non-deterministic merge iteration results
Jordan West created CASSANDRA-17251:
---
Summary: USING writetime + ttl is non-idempotent leading to
non-deterministic merge iteration results
Key: CASSANDRA-17251
URL: https://issues.apache.org/jira/browse/CASSANDRA-17251
Project: Cassandra
Issue Type: Bug
Reporter: Jordan West
Assignee: Jordan West
The combination of {{USING writetime = timestamp and ttl = ttl}} can result in
non-deterministic MergeIterator results causing DigestMismatchExceptions and
increased latencies. The increased latencies are caused by additional round
trips due to the digest mismatch as well as read repair rewriting the data. The
additional writes lead to an increase in the number of sstables the key is
stored in and must be scanned on read.
The order of events is:
1. for a given partition a write is performed with {{USING timestamp = sometime
and ttl = ttl1}}.
2. Cassandra records this write with timestamp = sometime, ttl = ttl1,
expires_at = now + ttl1
3. after N seconds, for the same partition, another write is performed with
{{USING timestamp = sometime and ttl = ttl2 where ttl2 = ttl1 - N}}. This write
only makes it to a subset of replicas* for some reason (e.g. partial write,
node down, etc).
4. Cassandra records this write with timestamp = sometime, ttl = ttl2,
expires_at = now + ttl2. Its important to note that at this point, expires_at
in 2 above is equal to expires at here. This is because it is calculated
relative to the current write time not the provided timestamp and the ttl has
been adjusted by the time passed. This write also makes it to a subset of
replicas*.
5. A read of the data is performed.
5a. The MergeIterator resolves conflicts locally (accross sstables) using
{{Conflicts.resolveRegular}} or {{Cells.resolveRegular}}. The resolution takes
into account the write timestamp , the liveness of the cell, the values
themselves, and how much time is left to live via the expires_at field. In this
scenario, all of these fields are equal, leading to Cassandra picking the
sstable "on the right" – this is non-deterministic. The only item that differs
is the ttl itself.
5b. One node returns the non-deterministically chosen value for the row, the
other two calculate and send a digest to the coordinator. The digest includes
the relative ttl field which may not match. This results in a
DigestMismatchException at the coordinator.
6. Read repair is triggered
*NOTE: its not strictly necessary for the write to make it to a subset of
replicas. sstables can also be ordered in random orders for reasons like
compaction or repair when returned from the live set which can lead to the same
behavior. This also affects repair from what we can tell.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17251) USING writetime + ttl is non-idempotent leading to non-deterministic merge iteration results
[
https://issues.apache.org/jira/browse/CASSANDRA-17251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jordan West updated CASSANDRA-17251:
Fix Version/s: 3.0.x
3.11.x
4.0.x
> USING writetime + ttl is non-idempotent leading to non-deterministic merge
> iteration results
>
>
> Key: CASSANDRA-17251
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17251
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> The combination of {{USING writetime = timestamp and ttl = ttl}} can result
> in non-deterministic MergeIterator results causing DigestMismatchExceptions
> and increased latencies. The increased latencies are caused by additional
> round trips due to the digest mismatch as well as read repair rewriting the
> data. The additional writes lead to an increase in the number of sstables the
> key is stored in and must be scanned on read.
> The order of events is:
> 1. for a given partition a write is performed with {{USING timestamp =
> sometime and ttl = ttl1}}.
> 2. Cassandra records this write with timestamp = sometime, ttl = ttl1,
> expires_at = now + ttl1
> 3. after N seconds, for the same partition, another write is performed with
> {{USING timestamp = sometime and ttl = ttl2 where ttl2 = ttl1 - N}}. This
> write only makes it to a subset of replicas* for some reason (e.g. partial
> write, node down, etc).
> 4. Cassandra records this write with timestamp = sometime, ttl = ttl2,
> expires_at = now + ttl2. Its important to note that at this point, expires_at
> in 2 above is equal to expires at here. This is because it is calculated
> relative to the current write time not the provided timestamp and the ttl has
> been adjusted by the time passed. This write also makes it to a subset of
> replicas*.
> 5. A read of the data is performed.
> 5a. The MergeIterator resolves conflicts locally (accross sstables) using
> {{Conflicts.resolveRegular}} or {{Cells.resolveRegular}}. The resolution
> takes into account the write timestamp , the liveness of the cell, the values
> themselves, and how much time is left to live via the expires_at field. In
> this scenario, all of these fields are equal, leading to Cassandra picking
> the sstable "on the right" – this is non-deterministic. The only item that
> differs is the ttl itself.
> 5b. One node returns the non-deterministically chosen value for the row, the
> other two calculate and send a digest to the coordinator. The digest includes
> the relative ttl field which may not match. This results in a
> DigestMismatchException at the coordinator.
> 6. Read repair is triggered
> *NOTE: its not strictly necessary for the write to make it to a subset of
> replicas. sstables can also be ordered in random orders for reasons like
> compaction or repair when returned from the live set which can lead to the
> same behavior. This also affects repair from what we can tell.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17068) Failed inbound internode authentication failures generate ugly warning with stack trace
[ https://issues.apache.org/jira/browse/CASSANDRA-17068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Meredith updated CASSANDRA-17068: - Test and Documentation Plan: In-jvm dtest included Status: Patch Available (was: Open) [Branch|https://github.com/jonmeredith/cassandra/tree/C17068-downgrade-inbound-internode-auth-error-logs] [Trunk PR|https://github.com/apache/cassandra/pull/1384] > Failed inbound internode authentication failures generate ugly warning with > stack trace > --- > > Key: CASSANDRA-17068 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17068 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Internode >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > Fix For: 4.0.x > > > Inbound connections can come from anywhere and the warning / stack trace is > unhelpful so I'd like to downgrade to a simple single-line INFO message when > authorization fails to reduce clutter in the logs. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17250) Move cleaning of the cassandra jar to the clean task
[ https://issues.apache.org/jira/browse/CASSANDRA-17250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17250: - Description: Currently, you have to run 'realclean' if you have multiple apache-cassandra*.jar files, which CASSANDRA-17129 detects and tells you about, but this is probably better served as part of the normal 'clean' task. (was: Currently, you have to run 'realclean' if you have multiple apache-cassandra*.jar files, which CASSANDRA-17129 detect and tells you about, but this is probably better served as part of the normal 'clean' task.) > Move cleaning of the cassandra jar to the clean task > > > Key: CASSANDRA-17250 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17250 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > Currently, you have to run 'realclean' if you have multiple > apache-cassandra*.jar files, which CASSANDRA-17129 detects and tells you > about, but this is probably better served as part of the normal 'clean' task. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17250) Move cleaning of the cassandra jar to the clean task
[ https://issues.apache.org/jira/browse/CASSANDRA-17250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17250: - Change Category: Operability Complexity: Normal Component/s: Build Status: Open (was: Triage Needed) > Move cleaning of the cassandra jar to the clean task > > > Key: CASSANDRA-17250 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17250 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > Currently, you have to run 'realclean' if you have multiple > apache-cassandra*.jar files, which CASSANDRA-17129 detect and tells you > about, but this is probably better served as part of the normal 'clean' task. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17250) Move cleaning of the cassandra jar to the clean task
[ https://issues.apache.org/jira/browse/CASSANDRA-17250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-17250: Assignee: Brandon Williams > Move cleaning of the cassandra jar to the clean task > > > Key: CASSANDRA-17250 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17250 > Project: Cassandra > Issue Type: Improvement >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > Currently, you have to run 'realclean' if you have multiple > apache-cassandra*.jar files, which CASSANDRA-17129 detect and tells you > about, but this is probably better served as part of the normal 'clean' task. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17250) Move cleaning of the cassandra jar to the clean task
Brandon Williams created CASSANDRA-17250: Summary: Move cleaning of the cassandra jar to the clean task Key: CASSANDRA-17250 URL: https://issues.apache.org/jira/browse/CASSANDRA-17250 Project: Cassandra Issue Type: Improvement Reporter: Brandon Williams Currently, you have to run 'realclean' if you have multiple apache-cassandra*.jar files, which CASSANDRA-17129 detect and tells you about, but this is probably better served as part of the normal 'clean' task. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16958) Prewarm role and credentials caches to avoid timeouts at startup
[ https://issues.apache.org/jira/browse/CASSANDRA-16958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-16958: -- Status: In Progress (was: Patch Available) > Prewarm role and credentials caches to avoid timeouts at startup > > > Key: CASSANDRA-16958 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16958 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Authorization >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.x > > > With our current auth querying setup, you can end up with a thundering herd > on reconnect due to delays on auth resolution. > We should instead allow the ability to do a 'select' on all roles and > pre-load the cache before turning on native transport. Notably, this could > present some unacceptable delays on start with a very large count of users > (thousands), or someone who uses a third party auth system rather than the > built-in authorizer so this should be configurable and opt-in. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15230) Resizing window aborts cqlsh COPY: Interrupted system call
[
https://issues.apache.org/jira/browse/CASSANDRA-15230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472247#comment-17472247
]
Brandon Williams commented on CASSANDRA-15230:
--
Looks like I broke something in the 4.0 and beyond merge.
> Resizing window aborts cqlsh COPY: Interrupted system call
> --
>
> Key: CASSANDRA-15230
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15230
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Johannes Weißl
>Assignee: Johannes Weißl
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Attachments: 15230-2.1.txt
>
>
> When resizing a terminal window running cqlsh COPY, the Python program aborts
> immediately with:
> {{:1:(4, 'Interrupted system call')}}
> This is very annoying, as COPY commands usually run for a long time, and e.g
> re-attaching to a screen session with a different terminal size aborts the
> command. This bug affects versions 2.1, 2.2, 3.0, 3.x, and trunk.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (902ac3e -> 32b4538)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard 902ac3e generate docs for b70dcb85 new 32b4538 generate docs for b70dcb85 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (902ac3e) \ N -- N -- N refs/heads/asf-staging (32b4538) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4740057 -> 4740057 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17249) Dead link in Docs
[ https://issues.apache.org/jira/browse/CASSANDRA-17249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17249: - Change Category: Semantic Complexity: Normal Component/s: Documentation/Website Status: Open (was: Triage Needed) > Dead link in Docs > - > > Key: CASSANDRA-17249 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17249 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Artem Chebotko >Priority: Normal > > The link for Kashlev Data Modeler at > [https://cassandra.apache.org/doc/latest/cassandra/data_modeling/data_modeling_tools.html] > needs to be updated to [http://kdm.kashliev.com/]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17249) Dead link in Docs
Artem Chebotko created CASSANDRA-17249: -- Summary: Dead link in Docs Key: CASSANDRA-17249 URL: https://issues.apache.org/jira/browse/CASSANDRA-17249 Project: Cassandra Issue Type: Improvement Reporter: Artem Chebotko The link for Kashlev Data Modeler at [https://cassandra.apache.org/doc/latest/cassandra/data_modeling/data_modeling_tools.html] needs to be updated to [http://kdm.kashliev.com/]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16765) Update Cassandra build CI script for new website
[ https://issues.apache.org/jira/browse/CASSANDRA-16765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472231#comment-17472231 ] Michael Semb Wever commented on CASSANDRA-16765: > If we want to build a new version of the docs, we would update the content > container environment variables. It might be cumbersome to have to update the file after every release. Releases are a lot more frequent than release branches. Is there a way that the run.sh could detect all releases (>=3.11.2, >=4.0.2) ? > Update Cassandra build CI script for new website > > > Key: CASSANDRA-16765 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16765 > Project: Cassandra > Issue Type: Task > Components: Build, CI, Documentation/Website >Reporter: Anthony Grasso >Assignee: Michael Semb Wever >Priority: Normal > > Update the apache/cassandra-build repository has [.groovy job > script|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy] > to use the new tooling to build the website. > The apache/cassandra-build repository has [.groovy job > script|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy]. > It [builds and deploys the > website|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy#L1255-L1268] > to cassandra-website staging when the cassandra-website is updated. > We need to change the commands in the .groovy script to at least rebuild the > site when a change happens in the cassandra-website repository. > It would be also good to build the docs when a change happens to doc/source > directory in the cassandra repository. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16765) Update Cassandra build CI script for new website
[ https://issues.apache.org/jira/browse/CASSANDRA-16765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472228#comment-17472228 ] Michael Semb Wever commented on CASSANDRA-16765: > That line should be able to collapse down to something that looks like this … fixed in patch (, running in CI as well) > Update Cassandra build CI script for new website > > > Key: CASSANDRA-16765 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16765 > Project: Cassandra > Issue Type: Task > Components: Build, CI, Documentation/Website >Reporter: Anthony Grasso >Assignee: Michael Semb Wever >Priority: Normal > > Update the apache/cassandra-build repository has [.groovy job > script|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy] > to use the new tooling to build the website. > The apache/cassandra-build repository has [.groovy job > script|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy]. > It [builds and deploys the > website|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy#L1255-L1268] > to cassandra-website staging when the cassandra-website is updated. > We need to change the commands in the .groovy script to at least rebuild the > site when a change happens in the cassandra-website repository. > It would be also good to build the docs when a change happens to doc/source > directory in the cassandra repository. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (a7bea8b -> 902ac3e)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. discard a7bea8b generate docs for b70dcb85 new 902ac3e generate docs for b70dcb85 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (a7bea8b) \ N -- N -- N refs/heads/asf-staging (902ac3e) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../doc/3.11.11/cassandra/architecture/dynamo.html | 2 +- .../3.11.11/cassandra/architecture/guarantees.html | 2 +- .../doc/3.11.11/cassandra/architecture/index.html | 2 +- .../3.11.11/cassandra/architecture/overview.html | 2 +- .../doc/3.11.11/cassandra/architecture/snitch.html | 2 +- .../cassandra/architecture/storage_engine.html | 2 +- .../configuration/cass_cl_archive_file.html| 2 +- .../cassandra/configuration/cass_env_sh_file.html | 2 +- .../configuration/cass_jvm_options_file.html | 2 +- .../configuration/cass_logback_xml_file.html | 2 +- .../cassandra/configuration/cass_rackdc_file.html | 2 +- .../cassandra/configuration/cass_topo_file.html| 2 +- .../cassandra/configuration/cass_yaml_file.html| 2 +- .../doc/3.11.11/cassandra/configuration/index.html | 2 +- content/doc/3.11.11/cassandra/cql/SASI.html| 2 +- content/doc/3.11.11/cassandra/cql/appendices.html | 2 +- content/doc/3.11.11/cassandra/cql/changes.html | 2 +- .../doc/3.11.11/cassandra/cql/cql_singlefile.html | 2 +- content/doc/3.11.11/cassandra/cql/ddl.html | 2 +- content/doc/3.11.11/cassandra/cql/definitions.html | 2 +- content/doc/3.11.11/cassandra/cql/dml.html | 2 +- content/doc/3.11.11/cassandra/cql/functions.html | 2 +- content/doc/3.11.11/cassandra/cql/index.html | 2 +- content/doc/3.11.11/cassandra/cql/indexes.html | 2 +- content/doc/3.11.11/cassandra/cql/json.html| 2 +- content/doc/3.11.11/cassandra/cql/mvs.html | 2 +- content/doc/3.11.11/cassandra/cql/operators.html | 2 +- content/doc/3.11.11/cassandra/cql/security.html| 2 +- content/doc/3.11.11/cassandra/cql/triggers.html| 2 +- content/doc/3.11.11/cassandra/cql/types.html | 2 +- .../data_modeling/data_modeling_conceptual.html| 2 +- .../data_modeling/data_modeling_logical.html | 2 +- .../data_modeling/data_modeling_physical.html | 2 +- .../data_modeling/data_modeling_queries.html | 2 +- .../data_modeling/data_modeling_rdbms.html | 2 +- .../data_modeling/data_modeling_refining.html | 2 +- .../data_modeling/data_modeling_schema.html| 2 +- .../data_modeling/data_modeling_tools.html | 2 +- .../doc/3.11.11/cassandra/data_modeling/index.html | 2 +- .../doc/3.11.11/cassandra/data_modeling/intro.html | 2 +- content/doc/3.11.11/cassandra/faq/index.html | 2 +- .../cassandra/getting_started/configuring.html | 2 +- .../3.11.11/cassandra/getting_started/drivers.html | 2 +- .../3.11.11/cassandra/getting_started/index.html | 2 +- .../cassandra/getting_started/installing.html | 2 +- .../cassandra/getting_started/production.html | 2 +- .../cassandra/getting_started/querying.html| 2 +- .../cassandra/getting_started/quickstart.html | 2 +- .../3.11.11/cassandra/operating/audit_logging.html | 2 +- .../doc/3.11.11/cassandra/operating/backups.html | 2 +- .../3.11.11/cassandra/operating/bloom_filters.html | 2 +- .../3.11.11/cassandra/operating/bulk_loading.html | 2 +- content/doc/3.11.11/cassandra/operating/cdc.html | 2 +- .../cassandra/operating/compaction/index.html | 2 +- .../cassandra/operating/compaction/lcs.html| 2 +- .../cassandra/operating/compaction/stcs.html | 2 +- .../cassandra/operating/compaction/twcs.html | 2 +- .../3.11.11/cassandra/operating/compression.html | 2 +- .../doc/3.11.11/cassandra/operating/hardware.html | 2 +- content/doc/3.11.11/cassandra/operating/hints.html | 2 +- content/doc/3.11.11/cassandra/operating/index.html | 2 +-
[jira] [Updated] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
miklosovic updated CASSANDRA-16956:
---
Attachment: signature.asc
yes you got these branches right.
Sent from ProtonMail mobile
\
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: signature.asc, signature.asc, signature.asc,
> signature.asc, signature.asc, signature.asc
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16765) Update Cassandra build CI script for new website
[ https://issues.apache.org/jira/browse/CASSANDRA-16765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472211#comment-17472211 ] Michael Semb Wever commented on CASSANDRA-16765: Can we spin off separate tickets? The CI patch can go in, and get updates latter on. For the sitemap.xml, ideally this is something that antora generates. (Antora only generates sitemaps when the url is filled) > Update Cassandra build CI script for new website > > > Key: CASSANDRA-16765 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16765 > Project: Cassandra > Issue Type: Task > Components: Build, CI, Documentation/Website >Reporter: Anthony Grasso >Assignee: Michael Semb Wever >Priority: Normal > > Update the apache/cassandra-build repository has [.groovy job > script|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy] > to use the new tooling to build the website. > The apache/cassandra-build repository has [.groovy job > script|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy]. > It [builds and deploys the > website|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy#L1255-L1268] > to cassandra-website staging when the cassandra-website is updated. > We need to change the commands in the .groovy script to at least rebuild the > site when a change happens in the cassandra-website repository. > It would be also good to build the docs when a change happens to doc/source > directory in the cassandra repository. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472201#comment-17472201
]
Brandon Williams edited comment on CASSANDRA-16956 at 1/10/22, 6:16 PM:
bq. Removal of code is not zero-risk, and this is 4.0 GA branch. Much like we
don't do small improvements on non-trunk branches, my understanding is the same
logic means we also don't do code removal / cruft cleanup / other refactors on
non-trunk as well.
I definitely agree with all of that. However, this is platform-specific code,
and it could be argued that not removing it when Windows support was deprecated
is a bug; after all CASSANDRA-16171 took a first pass. Significantly though,
the genesis of this ticket was the implications of this cruft on security in
CASSANDRA-14612.
It looks like after the holiday break there's been some branch->CI disconnect.
I've started runs against these branches, which I think is accurate, but please
correct me otherwise:
||branch||CI||
|[4.0|https://github.com/instaclustr/cassandra/tree/CASSANDRA-16956-4.0]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1358/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1358/pipeline]|
|[trunk|https://github.com/instaclustr/cassandra/tree/CASSANDRA-16956-trunk]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1359/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1359/pipeline]|
was (Author: brandon.williams):
bq. Removal of code is not zero-risk, and this is 4.0 GA branch. Much like we
don't do small improvements on non-trunk branches, my understanding is the same
logic means we also don't do code removal / cruft cleanup / other refactors on
non-trunk as well.
I definitely agree with all of that. However, this is platform-specific code,
and it could be argued that not removing it when Windows support was deprecated
is a bug; after all CASSANDRA-16171 took a first pass. Significantly though,
the genesis of this ticket was the implications of this cruft on security in
CASSANDRA-14612.
It looks like after the holiday break there's been some branch->CI disconnect.
I've started runs against these branches, which I think is accurate, but please
correct me otherwise:
||branch||CI||
|[4.0|https://github.com/instaclustr/cassandra/tree/CASSANDRA-16956-4.0]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1358/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1358/pipeline]|
[trunk|https://github.com/instaclustr/cassandra/tree/CASSANDRA-16956-trunk]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1359/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1359/pipeline]|
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: signature.asc, signature.asc, signature.asc,
> signature.asc, signature.asc
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472201#comment-17472201
]
Brandon Williams edited comment on CASSANDRA-16956 at 1/10/22, 6:14 PM:
bq. Removal of code is not zero-risk, and this is 4.0 GA branch. Much like we
don't do small improvements on non-trunk branches, my understanding is the same
logic means we also don't do code removal / cruft cleanup / other refactors on
non-trunk as well.
I definitely agree with all of that. However, this is platform-specific code,
and it could be argued that not removing it when Windows support was deprecated
is a bug; after all CASSANDRA-16171 took a first pass. Significantly though,
the genesis of this ticket was the implications of this cruft on security in
CASSANDRA-14612.
It looks like after the holiday break there's been some branch->CI disconnect.
I've started runs against these branches, which I think is accurate, but please
correct me otherwise:
||branch||CI||
|[4.0|https://github.com/instaclustr/cassandra/tree/CASSANDRA-16956-4.0]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1358/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1358/pipeline]|
[trunk|https://github.com/instaclustr/cassandra/tree/CASSANDRA-16956-trunk]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1359/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1359/pipeline]|
was (Author: brandon.williams):
bq. Removal of code is not zero-risk, and this is 4.0 GA branch. Much like we
don't do small improvements on non-trunk branches, my understanding is the same
logic means we also don't do code removal / cruft cleanup / other refactors on
non-trunk as well.
I definitely agree with all of that. However, this is platform-specific code,
and it could be argued that not removing it when Windows support was deprecated
is a bug; after all CASSANDRA-16171 took a first pass. Significantly though,
the genesis of this ticket was the implications of this cruft on security in
CASSANDRA-14612.
It looks like after the holiday break there's been some branch->CI disconnect.
I've started runs against these branches, which I think is accurate, but please
correct me otherwise:
||branch||CI||
|[4.0|https://github.com/instaclustr/cassandra/tree/CASSANDRA-16956-4.0]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1358/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1358/pipeline]|
[[trunk|https://github.com/instaclustr/cassandra/tree/CASSANDRA-16956-trunk]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1359/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1359/pipeline]|
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: signature.asc, signature.asc, signature.asc,
> signature.asc, signature.asc
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472201#comment-17472201
]
Brandon Williams commented on CASSANDRA-16956:
--
bq. Removal of code is not zero-risk, and this is 4.0 GA branch. Much like we
don't do small improvements on non-trunk branches, my understanding is the same
logic means we also don't do code removal / cruft cleanup / other refactors on
non-trunk as well.
I definitely agree with all of that. However, this is platform-specific code,
and it could be argued that not removing it when Windows support was deprecated
is a bug; after all CASSANDRA-16171 took a first pass. Significantly though,
the genesis of this ticket was the implications of this cruft on security in
CASSANDRA-14612.
It looks like after the holiday break there's been some branch->CI disconnect.
I've started runs against these branches, which I think is accurate, but please
correct me otherwise:
||branch||CI||
|[4.0|https://github.com/instaclustr/cassandra/tree/CASSANDRA-16956-4.0]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1358/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1358/pipeline]|
[[trunk|https://github.com/instaclustr/cassandra/tree/CASSANDRA-16956-trunk]|[!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1359/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1359/pipeline]|
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: signature.asc, signature.asc, signature.asc,
> signature.asc, signature.asc
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15230) Resizing window aborts cqlsh COPY: Interrupted system call
[
https://issues.apache.org/jira/browse/CASSANDRA-15230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472202#comment-17472202
]
Johannes Weißl commented on CASSANDRA-15230:
[~brandon.williams] thanks a lot!
> Resizing window aborts cqlsh COPY: Interrupted system call
> --
>
> Key: CASSANDRA-15230
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15230
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Johannes Weißl
>Assignee: Johannes Weißl
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Attachments: 15230-2.1.txt
>
>
> When resizing a terminal window running cqlsh COPY, the Python program aborts
> immediately with:
> {{:1:(4, 'Interrupted system call')}}
> This is very annoying, as COPY commands usually run for a long time, and e.g
> re-attaching to a screen session with a different terminal size aborts the
> command. This bug affects versions 2.1, 2.2, 3.0, 3.x, and trunk.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472185#comment-17472185
]
Josh McKenzie commented on CASSANDRA-16956:
---
{quote}bq. why keep cruft around?
{quote}
Removal of code is not zero-risk, and this is 4.0 GA branch. Much like we don't
do small improvements on non-trunk branches, my understanding is the same logic
means we also don't do code removal / cruft cleanup / other refactors on
non-trunk as well.
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: signature.asc, signature.asc, signature.asc,
> signature.asc, signature.asc
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
miklosovic updated CASSANDRA-16956:
---
Attachment: signature.asc
I want to explain myself fully because I feel like something in missing.
Initially, I also had doubts if it should go to 4.0.x but if one looks at it,
the thing is this should be already removed since 4.0.0, included. We just
havent done it but we claimed we dont support Windows anymore (right?). Now we
are just cleaning it up. If we said that we dont support Windows since 4.0, a
user should not run that on Windows even the code is still there. Hence I dont
see any excuse why it should be in 4.0.x still ...
Sent from ProtonMail mobile
\
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: signature.asc, signature.asc, signature.asc,
> signature.asc, signature.asc
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17226) Consistency Level Considered Connectivity Checker
[
https://issues.apache.org/jira/browse/CASSANDRA-17226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-17226:
--
Reviewers: Chris Lohfink
Status: Review In Progress (was: Patch Available)
> Consistency Level Considered Connectivity Checker
> -
>
> Key: CASSANDRA-17226
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17226
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Startup and Shutdown
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The connectivity checker runs during the startup of Cassandra, more
> specifically right after {{CassandraDaemon#setup}}. In general, it blocks for
> a certain period of time in order to establish connections with the peers in
> the cluster. The blocking is a best-effort one, meaning that the checker
> allows Cassandra to continue booting even if the criteria is not met.
> The Consistency Level Considered Connectivity Checker prioritizes the peers
> to connect, while still satisfying the desired Consistency Level. The goal of
> the new connectivity checker is to solve the read unavailable/timeout.
> The Consistency Level Considered Connectivity Checker (CL checker) uses the
> consistency level specified by the {{block_for_peers_consistency_level}}
> property to determine the number of peers to wait for in the local or remote
> datacenter before offering itself as a coordinator. Subject to the timeout
> specified by {{block_for_peers_timeout_in_secs}}.
> The supported values for the CL checker are {{ALL}}, {{QUORUM}},
> {{LOCAL_QUORUM}}, and {{EACH_QUORUM}}. The value is specified in the
> {{block_for_peers_consistency_level}} property defined in {{cassandra.yaml}}.
> The default consistency level is {{LOCAL_QUORUM}}.
> During the connectivity checker execution, peers are categorized into primary
> and secondary peers, such that primary peers are the sufficient number of
> peers required to satisfy the consistency level specified in
> {{block_for_peers_consistency_level}}. If the connection fails to any of the
> primary peers, additional connections are performed to secondary peers, and
> after the {{block_for_peers_timeout_in_secs}} timeout, validation is
> performed to make sure the CL is satisfied for all the natural replicas for
> every node.
> The CL checker does not support vnodes.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17243) Fix BYTES_PER_MEGABIT in StreamManager
[
https://issues.apache.org/jira/browse/CASSANDRA-17243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña reassigned CASSANDRA-17243:
-
Assignee: Andres de la Peña
> Fix BYTES_PER_MEGABIT in StreamManager
> --
>
> Key: CASSANDRA-17243
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17243
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
>Reporter: Ekaterina Dimitrova
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> While working on CASSANDRA-15234 I noticed BYTES_PER_MEGABIT constant in the
> {code:java}
> StreamManager
> {code}
> class. It was introduced in CASSANDRA-16959.
> The current formula converts actually bytes to mebibits.
> The change needed for 3.0, 3.11 and 4.0(I am currently changing rate
> parameters to be in MiB/s for trunk as part of CASSANDRA-15234):
> {code:java}
> public static final double BYTES_PER_MEGABIT = (1000 * 1000) / 8; // from bits
> {code}
> CC [~adelapena]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
miklosovic updated CASSANDRA-16956:
---
Attachment: signature.asc
I was counting on removal from 4.0.x too, code / branches are ready. I am a
deletion guy so I would get rid of that in 4.0.2 anyway.
Sent from ProtonMail mobile
\
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: signature.asc, signature.asc, signature.asc,
> signature.asc
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17248) Fix Prepared Statements behaviours after 15252
[ https://issues.apache.org/jira/browse/CASSANDRA-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-17248: Description: [CASSANDRA-15252] has fixed an important issue: unwanted hash changes when preparing fully qualified prepared statements which was causing cluster-killing re-prepare loops. However, the fix introduced a regression: non-qualified statements can get prepared against one keyspace but then executed on another under some circumstances. This patch reconciles all behaviours. > Fix Prepared Statements behaviours after 15252 > -- > > Key: CASSANDRA-17248 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17248 > Project: Cassandra > Issue Type: Bug >Reporter: Alex Petrov >Priority: Normal > > [CASSANDRA-15252] has fixed an important issue: unwanted hash changes when > preparing fully qualified prepared statements which was causing > cluster-killing re-prepare loops. However, the fix introduced a regression: > non-qualified statements can get prepared against one keyspace but then > executed on another under some circumstances. This patch reconciles all > behaviours. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17248) Fix Prepared Statements behaviours after 15252
[ https://issues.apache.org/jira/browse/CASSANDRA-17248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-17248: Summary: Fix Prepared Statements behaviours after 15252 (was: TBA) > Fix Prepared Statements behaviours after 15252 > -- > > Key: CASSANDRA-17248 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17248 > Project: Cassandra > Issue Type: Bug >Reporter: Alex Petrov >Priority: Normal > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15230) Resizing window aborts cqlsh COPY: Interrupted system call
[
https://issues.apache.org/jira/browse/CASSANDRA-15230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472125#comment-17472125
]
Brandon Williams commented on CASSANDRA-15230:
--
||Branch||CI||
|[3.0|https://github.com/driftx/cassandra/tree/CASSANDRA-15230-3.0]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-15230-3.0=all]|
|[3.11|https://github.com/driftx/cassandra/tree/CASSANDRA-15230-3.11]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-15230-3.11=all]|
|[4.0|https://github.com/driftx/cassandra/tree/CASSANDRA-15230-4.0]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-15230-4.0=all]|
|[trunk|https://github.com/driftx/cassandra/tree/CASSANDRA-15230-trunk]|[circle|https://app.circleci.com/pipelines/github/driftx/cassandra?branch=CASSANDRA-15230-trunk=all]|
> Resizing window aborts cqlsh COPY: Interrupted system call
> --
>
> Key: CASSANDRA-15230
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15230
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Johannes Weißl
>Assignee: Johannes Weißl
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Attachments: 15230-2.1.txt
>
>
> When resizing a terminal window running cqlsh COPY, the Python program aborts
> immediately with:
> {{:1:(4, 'Interrupted system call')}}
> This is very annoying, as COPY commands usually run for a long time, and e.g
> re-attaching to a screen session with a different terminal size aborts the
> command. This bug affects versions 2.1, 2.2, 3.0, 3.x, and trunk.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17168) Don't block gossip when clearing snapshots for failing repairs
[ https://issues.apache.org/jira/browse/CASSANDRA-17168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472105#comment-17472105 ] Marcus Eriksson commented on CASSANDRA-17168: - updated the trunk patch to not change the protocol, feels unnecessary to break compatibility for something this small > Don't block gossip when clearing snapshots for failing repairs > -- > > Key: CASSANDRA-17168 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17168 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0.x, 4.x > > > We clear snapshots in the GossipTasks thread when a repair session fails due > to a replica shutting down. If there are many tables/repair sessions ongoing > this can take a long time. With enough tables being repaired at the same time > even checking if the snapshots exists can take long enough to mark nodes down. > We should clear snapshots in a separate thread and add a flag to tell us > whether this repair session can have snapshots to avoid checking if the > directory exists. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472102#comment-17472102
]
Brandon Williams commented on CASSANDRA-16956:
--
If 4.0 doesn't support windows (and it doesn't even work), why keep cruft
around? That doesn't make sense to me. I checked and I tagged this 4.0.x from
the start so I'm not sure why we're having this conversation now, but I guess
if you want to push to a follow up ticket we can do that.
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: signature.asc, signature.asc, signature.asc
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472101#comment-17472101
]
Josh McKenzie commented on CASSANDRA-16956:
---
I don't think we should go in removing Windows code (or any code just for the
sake of removing it) from 4.0; this is much like an improvement and should be
trunk only IMO.
Any concerns with that [~brandon.williams]? Our support or lack thereof for
Windows is more a stated documented thing and less a code thing; nobody was
maintaining windows support from roughly 3.6 or so up through 4.0 so it doesn't
work out of the box atm anyway.
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: signature.asc, signature.asc, signature.asc
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16951) Dtest cluster reusage
[
https://issues.apache.org/jira/browse/CASSANDRA-16951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-16951:
--
Reviewers: Josh McKenzie
> Dtest cluster reusage
> -
>
> Key: CASSANDRA-16951
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16951
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x
>
>
> Dtests are very heavy but in some instances most of the time is spent
> restarting nodes in between test methods. Not all of them, but many seem
> could benefit form reusing a common cluster sparing the restarts. Obviously
> that is not the case for tests that manipulate the nodes itself during the
> test. The ones that follow a setup node/do test seem to benefit greatly in
> terms of time execution.
> Some classes run time can be cut form 10m to 1,5m. Others only from 30m to
> 25m. But taking a 5m shave and considering it will probably get ran *
> with/without vnodes * j8/j11/j8j11 * 4.0/trunk turns the 5m cut into a 60m
> cut. That should be a nice reduction in CI usage. Unfortunately run time will
> mostly remain the same until we have a majority of tests reusing nodes as the
> 'longest pole' will be the determining factor.
> How it works? It's an opt-in. Annotate the first test with
> {{@reuse_cluster(new_cluster=True)}} and the following ones with
> {{@reuse_cluster}}. Best effort to reuse the cluster will be made. Stop using
> the annotation at any test method and it will start a new one.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17247) Remove unused dependencies from pylib/requirements.txt
[
https://issues.apache.org/jira/browse/CASSANDRA-17247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Schoening updated CASSANDRA-17247:
---
Description:
The dependency 'cql' appears to be obsolete in requirements.txt and is not
imported by the python code.
The package 'cql' was last updated in 2012 and has been deprecated by its
authors
[https://pypi.org/project/cql/]
A DB-API 2.0 compliant client library for Cassandra/CQL
This driver has been {*}deprecated{*}. Please use python-driver
[https://github.com/datastax/python-driver] instead.
was:
The dependency 'cql' appears to be obsolete in requirements.txt and is not
imported by the python code.
The package 'cql' was last updated in 2012 and has been deprecated by its
authors
A DB-API 2.0 compliant client library for Cassandra/CQL
This driver has been {*}deprecated{*}. Please use python-driver
[https://github.com/datastax/python-driver] instead.
[https://pypi.org/project/cql/]
> Remove unused dependencies from pylib/requirements.txt
> --
>
> Key: CASSANDRA-17247
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17247
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: 17247-removed-obsolete-cql-dependency.patch
>
>
> The dependency 'cql' appears to be obsolete in requirements.txt and is not
> imported by the python code.
> The package 'cql' was last updated in 2012 and has been deprecated by its
> authors
> [https://pypi.org/project/cql/]
> A DB-API 2.0 compliant client library for Cassandra/CQL
> This driver has been {*}deprecated{*}. Please use python-driver
> [https://github.com/datastax/python-driver] instead.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17248) TBA
Alex Petrov created CASSANDRA-17248: --- Summary: TBA Key: CASSANDRA-17248 URL: https://issues.apache.org/jira/browse/CASSANDRA-17248 Project: Cassandra Issue Type: Bug Reporter: Alex Petrov -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17247) Remove unused dependencies from pylib/requirements.txt
[
https://issues.apache.org/jira/browse/CASSANDRA-17247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17247:
-
Bug Category: Parent values: Code(13163)
Complexity: Low Hanging Fruit
Discovered By: User Report
Fix Version/s: 4.0.x
4.x
Severity: Low
Assignee: Brad Schoening
Status: Open (was: Triage Needed)
> Remove unused dependencies from pylib/requirements.txt
> --
>
> Key: CASSANDRA-17247
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17247
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: 17247-removed-obsolete-cql-dependency.patch
>
>
> The dependency 'cql' appears to be obsolete in requirements.txt and is not
> imported by the python code.
> The package 'cql' was last updated in 2012 and has been deprecated by its
> authors
> A DB-API 2.0 compliant client library for Cassandra/CQL
> This driver has been {*}deprecated{*}. Please use python-driver
> [https://github.com/datastax/python-driver] instead.
> [https://pypi.org/project/cql/]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16262) 4.0 Quality: Coordination & Replication Fuzz Testing
[ https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-16262: Reviewers: Abe Ratnofsky, Caleb Rackliffe Status: Review In Progress (was: Patch Available) > 4.0 Quality: Coordination & Replication Fuzz Testing > > > Key: CASSANDRA-16262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16262 > Project: Cassandra > Issue Type: Task > Components: Test/fuzz >Reporter: Caleb Rackliffe >Assignee: Alex Petrov >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > > CASSANDRA-16180, CASSANDRA-16181, and CASSANDRA-15977 have largely focused on > auditing the existing tests around coordination, replication, and > read-repair, respectively. We've expanded existing test cases, added coverage > around components that we've refactored along the way, and added in-JVM dtest > upgrade tests where possible. > What remains is verifying the distributed read and write paths in the face of > common operational events, namely node restarts, bootstrapping, decommission, > and cleanup. If we can find a way to simulate these events, > [Harry|https://github.com/apache/cassandra-harry] seems like a good candidate > to host the verification logic itself. > To keep things simple initially, I would propose that we start by testing > simple read-only and write-only workloads (the former without read repair). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16262) 4.0 Quality: Coordination & Replication Fuzz Testing
[ https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-16262: Test and Documentation Plan: This is mostly testing patch. Status: Patch Available (was: Open) > 4.0 Quality: Coordination & Replication Fuzz Testing > > > Key: CASSANDRA-16262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16262 > Project: Cassandra > Issue Type: Task > Components: Test/fuzz >Reporter: Caleb Rackliffe >Assignee: Alex Petrov >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > > CASSANDRA-16180, CASSANDRA-16181, and CASSANDRA-15977 have largely focused on > auditing the existing tests around coordination, replication, and > read-repair, respectively. We've expanded existing test cases, added coverage > around components that we've refactored along the way, and added in-JVM dtest > upgrade tests where possible. > What remains is verifying the distributed read and write paths in the face of > common operational events, namely node restarts, bootstrapping, decommission, > and cleanup. If we can find a way to simulate these events, > [Harry|https://github.com/apache/cassandra-harry] seems like a good candidate > to host the verification logic itself. > To keep things simple initially, I would propose that we start by testing > simple read-only and write-only workloads (the former without read repair). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16262) 4.0 Quality: Coordination & Replication Fuzz Testing
[
https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472002#comment-17472002
]
Alex Petrov commented on CASSANDRA-16262:
-
[patch|https://github.com/apache/cassandra/pull/1382]
This introduces several ways to test Cassandra with Harry.
1. Creating unit tests using the history builder
{code}
test(new SchemaGenerators.Builder("harry")
.partitionKeySpec(1, 5)
.clusteringKeySpec(1, 5)
.regularColumnSpec(1, 10)
.generator(),
historyBuilder -> {
historyBuilder.nextPartition()
.simultaneously()
.randomOrder()
.partitionDeletion()
.rangeDeletion()
.finish();
});
{code}
2. Generating SSTables
{code}
SSTableLoadingVisitor sstableVisitor = new SSTableLoadingVisitor(run,
1000);
LtsVisitor visitor = new GeneratingVisitor(run, sstableVisitor);
Set pds = new HashSet<>();
run.tracker.onLtsStarted((lts) -> {
pds.add(run.pdSelector.pd(lts, run.schemaSpec));
});
for (int i = 0; i < 1000; i++)
visitor.visit();
sstableVisitor.forceFlush(0);
{code}
3. "normal" Harry capabilities (i.e. generate data using visitors and validate
them using the model).
> 4.0 Quality: Coordination & Replication Fuzz Testing
>
>
> Key: CASSANDRA-16262
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16262
> Project: Cassandra
> Issue Type: Task
> Components: Test/fuzz
>Reporter: Caleb Rackliffe
>Assignee: Alex Petrov
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.x
>
>
> CASSANDRA-16180, CASSANDRA-16181, and CASSANDRA-15977 have largely focused on
> auditing the existing tests around coordination, replication, and
> read-repair, respectively. We've expanded existing test cases, added coverage
> around components that we've refactored along the way, and added in-JVM dtest
> upgrade tests where possible.
> What remains is verifying the distributed read and write paths in the face of
> common operational events, namely node restarts, bootstrapping, decommission,
> and cleanup. If we can find a way to simulate these events,
> [Harry|https://github.com/apache/cassandra-harry] seems like a good candidate
> to host the verification logic itself.
> To keep things simple initially, I would propose that we start by testing
> simple read-only and write-only workloads (the former without read repair).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15230) Resizing window aborts cqlsh COPY: Interrupted system call
[
https://issues.apache.org/jira/browse/CASSANDRA-15230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17471998#comment-17471998
]
Brandon Williams commented on CASSANDRA-15230:
--
There is a patch, PRs are not a requirement. I will run CI today.
> Resizing window aborts cqlsh COPY: Interrupted system call
> --
>
> Key: CASSANDRA-15230
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15230
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Johannes Weißl
>Assignee: Johannes Weißl
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Attachments: 15230-2.1.txt
>
>
> When resizing a terminal window running cqlsh COPY, the Python program aborts
> immediately with:
> {{:1:(4, 'Interrupted system call')}}
> This is very annoying, as COPY commands usually run for a long time, and e.g
> re-attaching to a screen session with a different terminal size aborts the
> command. This bug affects versions 2.1, 2.2, 3.0, 3.x, and trunk.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-6936) Make all byte representations of types comparable by their unsigned byte representation only
[ https://issues.apache.org/jira/browse/CASSANDRA-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17471990#comment-17471990 ] Benedict Elliott Smith commented on CASSANDRA-6936: --- I trust you to have made good choices, [~blambov]. I'll see if I can find some time to get an overview the work for some high level feedback about the serialisation format, but I haven't thought about this problem domain in a long time so my consideration may be less valuable than you imagine. I won't likely have the time to perform a full review either way. > Make all byte representations of types comparable by their unsigned byte > representation only > > > Key: CASSANDRA-6936 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6936 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Benedict Elliott Smith >Assignee: Branimir Lambov >Priority: Normal > Labels: compaction, performance > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > This could be a painful change, but is necessary for implementing a > trie-based index, and settling for less would be suboptimal; it also should > make comparisons cheaper all-round, and since comparison operations are > pretty much the majority of C*'s business, this should be easily felt (see > CASSANDRA-6553 and CASSANDRA-6934 for an example of some minor changes with > major performance impacts). No copying/special casing/slicing should mean > fewer opportunities to introduce performance regressions as well. > Since I have slated for 3.0 a lot of non-backwards-compatible sstable > changes, hopefully this shouldn't be too much more of a burden. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17084) startup fails if directories do not exist
[
https://issues.apache.org/jira/browse/CASSANDRA-17084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17084:
-
Status: Open (was: Patch Available)
> startup fails if directories do not exist
> -
>
> Key: CASSANDRA-17084
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17084
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1
>
>
> Prior to CASSANDRA-16926, having commitlog and data dirs defined that did not
> exist would be created on startup, but now we throw:
> {noformat}
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Unable check disk space in
> 'bin/../data/commitlog'. Perhaps the Cassandra user does not have the
> necessary permissions
> org.apache.cassandra.exceptions.ConfigurationException: Unable check disk
> space in 'bin/../data/commitlog'. Perhaps the Cassandra user does not have
> the necessary permissions
> at
> org.apache.cassandra.config.DatabaseDescriptor.lambda$tryGetSpace$3(DatabaseDescriptor.java:1188)
> at
> org.apache.cassandra.io.util.PathUtils.tryOnFileStore(PathUtils.java:639)
> at
> org.apache.cassandra.io.util.PathUtils.tryGetSpace(PathUtils.java:665)
> at
> org.apache.cassandra.config.DatabaseDescriptor.tryGetSpace(DatabaseDescriptor.java:1188)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySimpleConfig(DatabaseDescriptor.java:553)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:350)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:178)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:162)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:800)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:736)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:871)
> {noformat}
> This was at least convenient for development, but also may be relied upon by
> some tooling/automation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17190) Add support for String contatenation through the "+" operator
[
https://issues.apache.org/jira/browse/CASSANDRA-17190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17471980#comment-17471980
]
Manish Ghildiyal commented on CASSANDRA-17190:
--
yeah, would add one.
> Add support for String contatenation through the "+" operator
> -
>
> Key: CASSANDRA-17190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17190
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Manish Ghildiyal
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Since 4.0, Cassandra support operations on numeric types and on some temporal
> types.
> We should add support for string concatenations through the {{+}} operator.
> +Additional information for newcomers:+
> Cassandra has 2 string types: {{Text}} ({{UTF8Type}}) and ascii
> ({{AsciiType}}) both are sub-classes of ({{StringType}}). In order to add
> support for string concatenation you will need to add a new method to
> {{StringType}} and modify {{OperationFcts}} to add the new functions (one for
> each combination of types: ascii/ascii, ascii/text, text/ascii and text/text).
> The unit test should be added to {{OperationFctsTest}}.
> To allow for concatenating constants (eg: SELECT v1 + ' ' + v2 FROM ...) you
> will need to add a {{getPreferedTypeFor}} method to
> {{org.apache.cassandra.Constants.Type.STRING}} that determine the constant
> type based on its content (ascii or not).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-6936) Make all byte representations of types comparable by their unsigned byte representation only
[ https://issues.apache.org/jira/browse/CASSANDRA-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17471978#comment-17471978 ] Branimir Lambov commented on CASSANDRA-6936: [~benedict], I think it would be best if you review this, so that we can incorporate any ideas you may have into the encoding while it still isn't used in any persisted data and we can freely modify it. Do you think you will have the time to do so? > Make all byte representations of types comparable by their unsigned byte > representation only > > > Key: CASSANDRA-6936 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6936 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Benedict Elliott Smith >Assignee: Branimir Lambov >Priority: Normal > Labels: compaction, performance > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > This could be a painful change, but is necessary for implementing a > trie-based index, and settling for less would be suboptimal; it also should > make comparisons cheaper all-round, and since comparison operations are > pretty much the majority of C*'s business, this should be easily felt (see > CASSANDRA-6553 and CASSANDRA-6934 for an example of some minor changes with > major performance impacts). No copying/special casing/slicing should mean > fewer opportunities to introduce performance regressions as well. > Since I have slated for 3.0 a lot of non-backwards-compatible sstable > changes, hopefully this shouldn't be too much more of a burden. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17198) Allow to filter using LIKE predicates
[
https://issues.apache.org/jira/browse/CASSANDRA-17198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17471968#comment-17471968
]
Benjamin Lerer commented on CASSANDRA-17198:
[~subkanthi] Filtering does not need an index to work. As such the index logic
({{CassandraIndex}}) should not be modified. You should also test without
creating an index. :-)
> Allow to filter using LIKE predicates
> -
>
> Key: CASSANDRA-17198
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17198
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Kanthi Subramanian
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> {{LIKE}} predicates can only be used with the SASI indices. In several
> usecases (e.g. querying the {{settings}} virtual table) it makes sense to
> support them for filtering.
> +Additional information for newcomers:+
> There are some checks in the {{StatementRestrictions}} constructor and on
> {{LikeRestriction}} that need to be removed for allowing filtering using LIKE
> on clustering and regular columns.
> For filtering on partition columns the {{needFiltering}} methods in
> {{PartitionKeySingleRestrictionSet}} will need to be modified to return true
> when LIKE predicate are used.
> The unit tests should go in {{SelectTest}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17198) Allow to filter using LIKE predicates
[
https://issues.apache.org/jira/browse/CASSANDRA-17198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17198:
---
Description:
{{LIKE}} predicates can only be used with the SASI indices. In several usecases
(e.g. querying the {{settings}} virtual table) it makes sense to support them
for filtering.
+Additional information for newcomers:+
There are some checks in the {{StatementRestrictions}} constructor and on
{{LikeRestriction}} that need to be removed for allowing filtering using LIKE
on clustering and regular columns.
For filtering on partition columns the {{needFiltering}} methods in
{{PartitionKeySingleRestrictionSet}} will need to be modified to return true
when LIKE predicate are used.
The unit tests should go in {{SelectTest}}.
was:
{{LIKE}} predicates can only be used with the SASI indices. In several usecases
(e.g. querying the {{settings}} virtual table) it makes sense to support them
for filtering.
+ Additional information for newcomers:+
There are some checks in the {{StatementRestrictions}} constructor and on
{{LikeRestriction}} that need to be removed for allowing filtering using LIKE
on clustering and regular columns.
For filtering on partition columns the {{needFiltering}} methods in
{{PartitionKeySingleRestrictionSet}} will need to be modified to return true
when LIKE predicate are used.
The unit tests should go in {{SelectTest}}.
> Allow to filter using LIKE predicates
> -
>
> Key: CASSANDRA-17198
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17198
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Kanthi Subramanian
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> {{LIKE}} predicates can only be used with the SASI indices. In several
> usecases (e.g. querying the {{settings}} virtual table) it makes sense to
> support them for filtering.
> +Additional information for newcomers:+
> There are some checks in the {{StatementRestrictions}} constructor and on
> {{LikeRestriction}} that need to be removed for allowing filtering using LIKE
> on clustering and regular columns.
> For filtering on partition columns the {{needFiltering}} methods in
> {{PartitionKeySingleRestrictionSet}} will need to be modified to return true
> when LIKE predicate are used.
> The unit tests should go in {{SelectTest}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17190) Add support for String contatenation through the "+" operator
[
https://issues.apache.org/jira/browse/CASSANDRA-17190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17190:
---
Status: Patch Available (was: Open)
> Add support for String contatenation through the "+" operator
> -
>
> Key: CASSANDRA-17190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17190
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Manish Ghildiyal
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Since 4.0, Cassandra support operations on numeric types and on some temporal
> types.
> We should add support for string concatenations through the {{+}} operator.
> +Additional information for newcomers:+
> Cassandra has 2 string types: {{Text}} ({{UTF8Type}}) and ascii
> ({{AsciiType}}) both are sub-classes of ({{StringType}}). In order to add
> support for string concatenation you will need to add a new method to
> {{StringType}} and modify {{OperationFcts}} to add the new functions (one for
> each combination of types: ascii/ascii, ascii/text, text/ascii and text/text).
> The unit test should be added to {{OperationFctsTest}}.
> To allow for concatenating constants (eg: SELECT v1 + ' ' + v2 FROM ...) you
> will need to add a {{getPreferedTypeFor}} method to
> {{org.apache.cassandra.Constants.Type.STRING}} that determine the constant
> type based on its content (ascii or not).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17190) Add support for String contatenation through the "+" operator
[
https://issues.apache.org/jira/browse/CASSANDRA-17190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17190:
---
Status: Review In Progress (was: Patch Available)
> Add support for String contatenation through the "+" operator
> -
>
> Key: CASSANDRA-17190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17190
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Manish Ghildiyal
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Since 4.0, Cassandra support operations on numeric types and on some temporal
> types.
> We should add support for string concatenations through the {{+}} operator.
> +Additional information for newcomers:+
> Cassandra has 2 string types: {{Text}} ({{UTF8Type}}) and ascii
> ({{AsciiType}}) both are sub-classes of ({{StringType}}). In order to add
> support for string concatenation you will need to add a new method to
> {{StringType}} and modify {{OperationFcts}} to add the new functions (one for
> each combination of types: ascii/ascii, ascii/text, text/ascii and text/text).
> The unit test should be added to {{OperationFctsTest}}.
> To allow for concatenating constants (eg: SELECT v1 + ' ' + v2 FROM ...) you
> will need to add a {{getPreferedTypeFor}} method to
> {{org.apache.cassandra.Constants.Type.STRING}} that determine the constant
> type based on its content (ascii or not).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17190) Add support for String contatenation through the "+" operator
[
https://issues.apache.org/jira/browse/CASSANDRA-17190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17471957#comment-17471957
]
Benjamin Lerer commented on CASSANDRA-17190:
The test does not work anymore as it used to because the patch improve the
logic determining which function should be used. It now automatically detect
that it can used the {{overloaded(ascii)}} function.
This
[assertion|https://github.com/apache/cassandra-dtest/blob/trunk/user_functions_test.py#L150}}
can be replaced by an {{assert_none}}.
[~manish.c.ghildi...@gmail.com] if you do a PR for the DTest repo we can run CI
with both of your branches. :-)
> Add support for String contatenation through the "+" operator
> -
>
> Key: CASSANDRA-17190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17190
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Manish Ghildiyal
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Since 4.0, Cassandra support operations on numeric types and on some temporal
> types.
> We should add support for string concatenations through the {{+}} operator.
> +Additional information for newcomers:+
> Cassandra has 2 string types: {{Text}} ({{UTF8Type}}) and ascii
> ({{AsciiType}}) both are sub-classes of ({{StringType}}). In order to add
> support for string concatenation you will need to add a new method to
> {{StringType}} and modify {{OperationFcts}} to add the new functions (one for
> each combination of types: ascii/ascii, ascii/text, text/ascii and text/text).
> The unit test should be added to {{OperationFctsTest}}.
> To allow for concatenating constants (eg: SELECT v1 + ' ' + v2 FROM ...) you
> will need to add a {{getPreferedTypeFor}} method to
> {{org.apache.cassandra.Constants.Type.STRING}} that determine the constant
> type based on its content (ascii or not).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (cc0eb4b -> a7bea8b)
This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a change to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git.
discard cc0eb4b generate docs for b70dcb85
new a7bea8b generate docs for b70dcb85
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (cc0eb4b)
\
N -- N -- N refs/heads/asf-staging (a7bea8b)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
.../4.1/cassandra/tools/nodetool/bootstrap.html| 7 +-
...lidatekeycache.html => getauthcacheconfig.html} | 14 ++--
.../doc/4.1/cassandra/tools/nodetool/import.html | 6 +-
.../doc/4.1/cassandra/tools/nodetool/nodetool.html | 14 +++-
.../4.1/cassandra/tools/nodetool/repair_admin.html | 88 +++--
...achekeystosave.html => setauthcacheconfig.html} | 40 ++
.../latest/cassandra/tools/nodetool/bootstrap.html | 7 +-
.../tools/nodetool/getauthcacheconfig.html}| 14 ++--
.../latest/cassandra/tools/nodetool/import.html| 6 +-
.../latest/cassandra/tools/nodetool/nodetool.html | 14 +++-
.../cassandra/tools/nodetool/repair_admin.html | 88 +++--
.../tools/nodetool/setauthcacheconfig.html}| 40 ++
.../trunk/cassandra/tools/nodetool/bootstrap.html | 7 +-
.../tools/nodetool/getauthcacheconfig.html}| 14 ++--
.../doc/trunk/cassandra/tools/nodetool/import.html | 6 +-
.../trunk/cassandra/tools/nodetool/nodetool.html | 14 +++-
.../cassandra/tools/nodetool/repair_admin.html | 88 +++--
.../tools/nodetool/setauthcacheconfig.html}| 40 ++
content/search-index.js| 2 +-
site-ui/build/ui-bundle.zip| Bin 4740057 -> 4740057
bytes
20 files changed, 295 insertions(+), 214 deletions(-)
copy content/doc/4.1/cassandra/tools/nodetool/{invalidatekeycache.html =>
getauthcacheconfig.html} (98%)
copy content/doc/4.1/cassandra/tools/nodetool/{setcachekeystosave.html =>
setauthcacheconfig.html} (96%)
copy content/doc/{4.1/cassandra/tools/nodetool/invalidatekeycache.html =>
latest/cassandra/tools/nodetool/getauthcacheconfig.html} (98%)
copy content/doc/{4.1/cassandra/tools/nodetool/setcachekeystosave.html =>
latest/cassandra/tools/nodetool/setauthcacheconfig.html} (96%)
copy content/doc/{4.1/cassandra/tools/nodetool/invalidatekeycache.html =>
trunk/cassandra/tools/nodetool/getauthcacheconfig.html} (98%)
copy content/doc/{4.1/cassandra/tools/nodetool/setcachekeystosave.html =>
trunk/cassandra/tools/nodetool/setauthcacheconfig.html} (96%)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17221) Add Math functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17471903#comment-17471903
]
Benjamin Lerer edited comment on CASSANDRA-17221 at 1/10/22, 11:44 AM:
---
[~xvade] do not hesitate to mark your patch as {{PATCH AVAILABLE}} using the
{{Submit Patch}} button. That will allow people to notice that your patch is
ready for review :-)
Thanks a lot for the nice work.
was (Author: blerer):
[~xvade] do not hesitate to mark your patch as {{PATCH AVAILABLE}} using the
{{Submit Patch}} button. That will allow people to notice that your patch is
ready for review :-)
> Add Math functions
> ---
>
> Key: CASSANDRA-17221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17221
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Labels: AdventCalendar2021, lhf
>
> We should add native Maths functions for the most common operations:
> * {{abs\(x)}} returns the absolute value of the x
> * {{exp\(x)}} returns the value of e (the base of natural logarithms) raised
> to the power of x
> * {{log\(x)}} returns the natural logarithm (base e) of x
> * {{log10\(x)}} returns the base-10 logarithm of x
> * {{round\(x)}} returns the closest integer to x
> +Additional information for newcomers:+
> The new functions should be put in a new class {{MathFcts}} similar to
> {{TimeFcts}}.
> The {{MathsFcts.all()}} method should be called in
> {{SystemKeyspace.functions}}
> The unit tests for the functions should be put in a {{MathFctsTest}} similar
> to {{TimeFctsTest}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17221) Add Math functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17221:
---
Test and Documentation Plan: The patch add new tests
Status: Patch Available (was: In Progress)
> Add Math functions
> ---
>
> Key: CASSANDRA-17221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17221
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Labels: AdventCalendar2021, lhf
>
> We should add native Maths functions for the most common operations:
> * {{abs\(x)}} returns the absolute value of the x
> * {{exp\(x)}} returns the value of e (the base of natural logarithms) raised
> to the power of x
> * {{log\(x)}} returns the natural logarithm (base e) of x
> * {{log10\(x)}} returns the base-10 logarithm of x
> * {{round\(x)}} returns the closest integer to x
> +Additional information for newcomers:+
> The new functions should be put in a new class {{MathFcts}} similar to
> {{TimeFcts}}.
> The {{MathsFcts.all()}} method should be called in
> {{SystemKeyspace.functions}}
> The unit tests for the functions should be put in a {{MathFctsTest}} similar
> to {{TimeFctsTest}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17221) Add Math functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17471903#comment-17471903
]
Benjamin Lerer commented on CASSANDRA-17221:
[~xvade] do not hesitate to mark your patch as {{PATCH AVAILABLE}} using the
{{Submit Patch}} button. That will allow people to notice that your patch is
ready for review :-)
> Add Math functions
> ---
>
> Key: CASSANDRA-17221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17221
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Labels: AdventCalendar2021, lhf
>
> We should add native Maths functions for the most common operations:
> * {{abs\(x)}} returns the absolute value of the x
> * {{exp\(x)}} returns the value of e (the base of natural logarithms) raised
> to the power of x
> * {{log\(x)}} returns the natural logarithm (base e) of x
> * {{log10\(x)}} returns the base-10 logarithm of x
> * {{round\(x)}} returns the closest integer to x
> +Additional information for newcomers:+
> The new functions should be put in a new class {{MathFcts}} similar to
> {{TimeFcts}}.
> The {{MathsFcts.all()}} method should be called in
> {{SystemKeyspace.functions}}
> The unit tests for the functions should be put in a {{MathFctsTest}} similar
> to {{TimeFctsTest}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17225) Add a virtual table for exposing batch metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-17225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17225:
---
Reviewers: Benjamin Lerer, Ekaterina Dimitrova (was: Ekaterina Dimitrova)
> Add a virtual table for exposing batch metrics
> --
>
> Key: CASSANDRA-17225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17225
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Benjamin Lerer
>Assignee: Michael Burman
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are some existing metrics within BatchMetrics that provide metrics
> about related to the different types of Batches being executed. We should
> expose those through a virtual table.
> +Additional information for newcomers:+
> A new class should be created for representing the new Virtual Table in
> {{org.apache.cassandra.db.virtual}}. You can look at {{ThreadPoolsTable}} for
> an example of virtual table implementation and to {{TableMetricTables}} for
> how Histogram metrics can be exposed. The new table will need to be
> registered in {{SystemViewsKeyspace}}.
> Some unit tests should be added. For some example of virtual table tests you
> can look at {{SystemPropertiesTableTest}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17225) Add a virtual table for exposing batch metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-17225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17225:
---
Test and Documentation Plan: The patch add new unit tests
Status: Patch Available (was: In Progress)
> Add a virtual table for exposing batch metrics
> --
>
> Key: CASSANDRA-17225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17225
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Benjamin Lerer
>Assignee: Michael Burman
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are some existing metrics within BatchMetrics that provide metrics
> about related to the different types of Batches being executed. We should
> expose those through a virtual table.
> +Additional information for newcomers:+
> A new class should be created for representing the new Virtual Table in
> {{org.apache.cassandra.db.virtual}}. You can look at {{ThreadPoolsTable}} for
> an example of virtual table implementation and to {{TableMetricTables}} for
> how Histogram metrics can be exposed. The new table will need to be
> registered in {{SystemViewsKeyspace}}.
> Some unit tests should be added. For some example of virtual table tests you
> can look at {{SystemPropertiesTableTest}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17229) Add a Virtual table to expose Streaming metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-17229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17471900#comment-17471900
]
Benjamin Lerer commented on CASSANDRA-17229:
Sorry for the delay of my answer.
The metrics we should expose are explained
[here|https://cassandra.apache.org/doc/latest/cassandra/operating/metrics.html#streaming-metrics].
You can find them in the {{StreamingMetrics}} class.
> Add a Virtual table to expose Streaming metrics
> ---
>
> Key: CASSANDRA-17229
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17229
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Benjamin Lerer
>Assignee: Manish Ghildiyal
>Priority: Normal
> Labels: AdventCalendar2021, lhf
>
> The streaming metrics for the different nodes should be exposed through a
> virtual table.
> +Additional information for newcomers:+
> A new class should be created for representing the new Virtual Table in
> {{org.apache.cassandra.db.virtual}}. You can look at {{ThreadPoolsTable}} for
> an example of virtual table implementation and to
> {{TableMetricTables#buildMetadata}} for how {{Timer}} metrics can be exposed.
> The new table will need to be registered in SystemViewsKeyspace.
> For the unit tests the easiest way is to add them at {{StreamingMetrics}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13047) Point cqlsh help to the new doc
[ https://issues.apache.org/jira/browse/CASSANDRA-13047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17471883#comment-17471883 ] Berenguer Blasi commented on CASSANDRA-13047: - Docs seem to have just moved into the state we needed them. I will jump again into this one :-) > Point cqlsh help to the new doc > --- > > Key: CASSANDRA-13047 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13047 > Project: Cassandra > Issue Type: Bug > Components: Legacy/CQL >Reporter: Sylvain Lebresne >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 3.11.x, 4.0.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > Cqlsh still points to the "old" textile CQL doc, but that's not really > maintain anymore now that we have the new doc (which include everything the > old doc had and more). We should update cqlsh to point to the new doc so we > can remove the old one completely. > Any takers? -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-harry] branch trunk updated (5aea1cf -> 275f188)
This is an automated email from the ASF dual-hosted git repository. ifesdjeen pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-harry.git. discard 5aea1cf Features: * Implement lookbehind via tracker callbacks * Improve DSL * Rename maxLts to peek * Split lts visitors from visitors * Allow create table if not exists * Allow sampler to be triggered at every LTS * Allow local state validator to always run * Add Staged Runner * Add wait for token ranges * Make keyspace DDL configurable * Rename PartitionVisitor to Visitor new 275f188 Features: * Implement lookbehind via tracker callbacks * Improve DSL * Rename maxLts to peek * Split lts visitors from visitors * Allow create table if not exists * Allow sampler to be triggered at every LTS * Allow local state validator to always run * Add Staged Runner * Add wait for token ranges * Make keyspace DDL configurable * Rename PartitionVisitor to Visitor This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (5aea1cf) \ N -- N -- N refs/heads/trunk (275f188) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../test/harry/model/HistoryBuilderIntegrationTest.java | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-10537) CONTAINS and CONTAINS KEY support for Lightweight Transactions
[
https://issues.apache.org/jira/browse/CASSANDRA-10537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17471853#comment-17471853
]
Benjamin Lerer edited comment on CASSANDRA-10537 at 1/10/22, 10:41 AM:
---
{quote}Modifications are quite light so i haven't started the refactoring of
ColumnCondition mentioned by Alex Petrov (even if i'm agree on its
benefits).{quote}
The comment from [~ifesdjeen] is an old one. We did refactor the code since
then :-)
Thanks a lot for the patch :-). I will review it.
was (Author: blerer):
{quote}Modifications are quite light so i haven't started the refactoring of
ColumnCondition mentioned by Alex Petrov (even if i'm agree on its
benefits).{quote}
The comment from [~ifesdjeen] is an old one. We did refactor the code since
then :-)
> CONTAINS and CONTAINS KEY support for Lightweight Transactions
> --
>
> Key: CASSANDRA-10537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10537
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Nimi Wariboko Jr.
>Assignee: ROCHETEAU Antoine
>Priority: Normal
> Labels: AdventCalendar2021, CQL, lhf
> Fix For: 4.x
>
>
> Conditional updates currently do not support CONTAINS and CONTAINS KEY
> conditions. Queries such as
> {{UPDATE mytable SET somefield = 4 WHERE pk = 'pkv' IF set_column CONTAINS
> 5;}}
> are not possible.
> Would it also be possible to support the negation of these (ex. testing that
> a value does not exist inside a set)?
> +Additional Information for newcomers:+
> Negation should not be supported as for the moment we do not support it
> within restrictions either.
> One way to approch this bug is to use test driven development. You can modify
> {{InsertUpdateIfConditionCollectionsTest}} to allow CONTAINS and CONTAINS KEY
> operators and go through the different failures.
> The following changes will need to be done.
> * The {{columnCondition}} rule from the ANTLR {{Parser.g}} file should be
> updated to accept {{containsOperator}}.
> * {{ColumnCondition.Raw#prepareTerms}} should be modified in the case where
> the operator is a CONTAINS or CONTAINS KEY as the {{receiver}} is not the
> collection but keys or values of the collection. Look at
> {{SingleColumnRelation#makeCollectionReceiver}}.
> * {{ColumnCollection.MultiCellCollectionBound#valueAppliesTo}} will need to
> be changed for {{Map}} and {{Set}} to process CONTAINS operators.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10537) CONTAINS and CONTAINS KEY support for Lightweight Transactions
[
https://issues.apache.org/jira/browse/CASSANDRA-10537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17471853#comment-17471853
]
Benjamin Lerer commented on CASSANDRA-10537:
{quote}Modifications are quite light so i haven't started the refactoring of
ColumnCondition mentioned by Alex Petrov (even if i'm agree on its
benefits).{quote}
The comment from [~ifesdjeen] is an old one. We did refactor the code since
then :-)
> CONTAINS and CONTAINS KEY support for Lightweight Transactions
> --
>
> Key: CASSANDRA-10537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10537
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Nimi Wariboko Jr.
>Assignee: ROCHETEAU Antoine
>Priority: Normal
> Labels: AdventCalendar2021, CQL, lhf
> Fix For: 4.x
>
>
> Conditional updates currently do not support CONTAINS and CONTAINS KEY
> conditions. Queries such as
> {{UPDATE mytable SET somefield = 4 WHERE pk = 'pkv' IF set_column CONTAINS
> 5;}}
> are not possible.
> Would it also be possible to support the negation of these (ex. testing that
> a value does not exist inside a set)?
> +Additional Information for newcomers:+
> Negation should not be supported as for the moment we do not support it
> within restrictions either.
> One way to approch this bug is to use test driven development. You can modify
> {{InsertUpdateIfConditionCollectionsTest}} to allow CONTAINS and CONTAINS KEY
> operators and go through the different failures.
> The following changes will need to be done.
> * The {{columnCondition}} rule from the ANTLR {{Parser.g}} file should be
> updated to accept {{containsOperator}}.
> * {{ColumnCondition.Raw#prepareTerms}} should be modified in the case where
> the operator is a CONTAINS or CONTAINS KEY as the {{receiver}} is not the
> collection but keys or values of the collection. Look at
> {{SingleColumnRelation#makeCollectionReceiver}}.
> * {{ColumnCollection.MultiCellCollectionBound#valueAppliesTo}} will need to
> be changed for {{Map}} and {{Set}} to process CONTAINS operators.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10537) CONTAINS and CONTAINS KEY support for Lightweight Transactions
[
https://issues.apache.org/jira/browse/CASSANDRA-10537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-10537:
---
Test and Documentation Plan: The PR updates existing unit tests
Status: Patch Available (was: Open)
> CONTAINS and CONTAINS KEY support for Lightweight Transactions
> --
>
> Key: CASSANDRA-10537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10537
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Nimi Wariboko Jr.
>Assignee: ROCHETEAU Antoine
>Priority: Normal
> Labels: AdventCalendar2021, CQL, lhf
> Fix For: 4.x
>
>
> Conditional updates currently do not support CONTAINS and CONTAINS KEY
> conditions. Queries such as
> {{UPDATE mytable SET somefield = 4 WHERE pk = 'pkv' IF set_column CONTAINS
> 5;}}
> are not possible.
> Would it also be possible to support the negation of these (ex. testing that
> a value does not exist inside a set)?
> +Additional Information for newcomers:+
> Negation should not be supported as for the moment we do not support it
> within restrictions either.
> One way to approch this bug is to use test driven development. You can modify
> {{InsertUpdateIfConditionCollectionsTest}} to allow CONTAINS and CONTAINS KEY
> operators and go through the different failures.
> The following changes will need to be done.
> * The {{columnCondition}} rule from the ANTLR {{Parser.g}} file should be
> updated to accept {{containsOperator}}.
> * {{ColumnCondition.Raw#prepareTerms}} should be modified in the case where
> the operator is a CONTAINS or CONTAINS KEY as the {{receiver}} is not the
> collection but keys or values of the collection. Look at
> {{SingleColumnRelation#makeCollectionReceiver}}.
> * {{ColumnCollection.MultiCellCollectionBound#valueAppliesTo}} will need to
> be changed for {{Map}} and {{Set}} to process CONTAINS operators.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-10537) CONTAINS and CONTAINS KEY support for Lightweight Transactions
[
https://issues.apache.org/jira/browse/CASSANDRA-10537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-10537:
--
Assignee: ROCHETEAU Antoine
> CONTAINS and CONTAINS KEY support for Lightweight Transactions
> --
>
> Key: CASSANDRA-10537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10537
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Nimi Wariboko Jr.
>Assignee: ROCHETEAU Antoine
>Priority: Normal
> Labels: AdventCalendar2021, CQL, lhf
> Fix For: 4.x
>
>
> Conditional updates currently do not support CONTAINS and CONTAINS KEY
> conditions. Queries such as
> {{UPDATE mytable SET somefield = 4 WHERE pk = 'pkv' IF set_column CONTAINS
> 5;}}
> are not possible.
> Would it also be possible to support the negation of these (ex. testing that
> a value does not exist inside a set)?
> +Additional Information for newcomers:+
> Negation should not be supported as for the moment we do not support it
> within restrictions either.
> One way to approch this bug is to use test driven development. You can modify
> {{InsertUpdateIfConditionCollectionsTest}} to allow CONTAINS and CONTAINS KEY
> operators and go through the different failures.
> The following changes will need to be done.
> * The {{columnCondition}} rule from the ANTLR {{Parser.g}} file should be
> updated to accept {{containsOperator}}.
> * {{ColumnCondition.Raw#prepareTerms}} should be modified in the case where
> the operator is a CONTAINS or CONTAINS KEY as the {{receiver}} is not the
> collection but keys or values of the collection. Look at
> {{SingleColumnRelation#makeCollectionReceiver}}.
> * {{ColumnCollection.MultiCellCollectionBound#valueAppliesTo}} will need to
> be changed for {{Map}} and {{Set}} to process CONTAINS operators.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15230) Resizing window aborts cqlsh COPY: Interrupted system call
[
https://issues.apache.org/jira/browse/CASSANDRA-15230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17471833#comment-17471833
]
Berenguer Blasi commented on CASSANDRA-15230:
-
Hi [~weisslj],
at this point afaik we would expect PRs for all the affected versions +
matching CI runs. I can do the CI runs for you once the PRs are up if you want.
> Resizing window aborts cqlsh COPY: Interrupted system call
> --
>
> Key: CASSANDRA-15230
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15230
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Johannes Weißl
>Assignee: Johannes Weißl
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Attachments: 15230-2.1.txt
>
>
> When resizing a terminal window running cqlsh COPY, the Python program aborts
> immediately with:
> {{:1:(4, 'Interrupted system call')}}
> This is very annoying, as COPY commands usually run for a long time, and e.g
> re-attaching to a screen session with a different terminal size aborts the
> command. This bug affects versions 2.1, 2.2, 3.0, 3.x, and trunk.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15230) Resizing window aborts cqlsh COPY: Interrupted system call
[
https://issues.apache.org/jira/browse/CASSANDRA-15230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-15230:
Reviewers: Berenguer Blasi, Brandon Williams (was: Brandon Williams)
> Resizing window aborts cqlsh COPY: Interrupted system call
> --
>
> Key: CASSANDRA-15230
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15230
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Johannes Weißl
>Assignee: Johannes Weißl
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Attachments: 15230-2.1.txt
>
>
> When resizing a terminal window running cqlsh COPY, the Python program aborts
> immediately with:
> {{:1:(4, 'Interrupted system call')}}
> This is very annoying, as COPY commands usually run for a long time, and e.g
> re-attaching to a screen session with a different terminal size aborts the
> command. This bug affects versions 2.1, 2.2, 3.0, 3.x, and trunk.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
miklosovic updated CASSANDRA-16956:
---
Attachment: signature.asc
Btw if you want just finish that and put me in co-authors, it is the group
effort anyway. We are just losing time waiting for me to move it forward. This
is 99% done. Somebody just gotta run the builds.
Sent from ProtonMail mobile
\
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: signature.asc, signature.asc, signature.asc
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16765) Update Cassandra build CI script for new website
[
https://issues.apache.org/jira/browse/CASSANDRA-16765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17471808#comment-17471808
]
Anthony Grasso commented on CASSANDRA-16765:
[~mck] , good questions in the previous two comments. I will start work on
updates to the cassandra-website tooling with the aim of removing hacks and
hardcoded issues in the CI build.
See my comments below for answers to some of the questions raised.
{quote}the branches we can build in-tree docs becomes hardcoded in the jenkins
config, both in what to build] and in what changes to listen for to trigger off
a build,
{quote}
We can remove the hard coded versions from the [Jenkins
file|https://github.com/apache/cassandra-builds/compare/trunk...thelastpickle:mck/16765#diff-1f760d89dfb81ea05a11d862007a4e4e586b38aac7ae87f62c5b2e86571809c0R1270].
The default documentation branches to generate are specified in the [content
container environment
variables|https://github.com/apache/cassandra-website/blob/trunk/site-content/Dockerfile#L93].
In addition, we can remove the hardcoded UI bundle ZIP file path from the
command as well. That line should be able to collapse down to something that
looks like this
{code:java}
./run.sh website container -a BUILD_USER_ARG:`whoami` -a UID_ARG:`id -u` -a
GID_ARG:`id -g` ;
./run.sh website build -g;
{code}
What changes to listen for will have to remain in Jenkins. The triggering of CI
is outside the scope of the {{run.sh}} script.
{quote}no released versions are listed, i.e. git tags. how will they be
introduced into this line
{quote}
If we want to build a new version of the docs, we would update the [content
container environment
variables|https://github.com/apache/cassandra-website/blob/trunk/site-content/Dockerfile#L93].
In this way, CI remains untouched and what to build remains in a single
repository.
{quote}the notions of stable and latest docs are hardcoded by jenkins here, is
this something that can be put into antora?
{quote}
This is a very good point. I believe this is something Antora can do. We should
be able to control this in the [Antora YAML template
file|https://github.com/apache/cassandra-website/blob/trunk/site-content/site.template.yaml#L41].
I will need to speak to [~polandll] about this.
{quote}we need to switch references from /doc/latest to /doc/stable
{quote}
This should be a quick fix.
{quote}robots.txt, .htaccess, and sitemap.xml were missing. manually added back
in with this commit, but this should be part of antora generation
{quote}
Agreed. I will discuss with [~polandll] first about how we could make these
changes. We may need to involve [~paul-travers-todd] as well.
{quote}all the hack steps need to solved and/or part of the run.sh
{quote}
Agreed. I will work out what Antora can do for us automatically, then offload
the remaining tasks to the {{run.sh}} script.
> Update Cassandra build CI script for new website
>
>
> Key: CASSANDRA-16765
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16765
> Project: Cassandra
> Issue Type: Task
> Components: Build, CI, Documentation/Website
>Reporter: Anthony Grasso
>Assignee: Michael Semb Wever
>Priority: Normal
>
> Update the apache/cassandra-build repository has [.groovy job
> script|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy]
> to use the new tooling to build the website.
> The apache/cassandra-build repository has [.groovy job
> script|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy].
> It [builds and deploys the
> website|https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy#L1255-L1268]
> to cassandra-website staging when the cassandra-website is updated.
> We need to change the commands in the .groovy script to at least rebuild the
> site when a change happens in the cassandra-website repository.
> It would be also good to build the docs when a change happens to doc/source
> directory in the cassandra repository.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
miklosovic updated CASSANDRA-16956:
---
Attachment: signature.asc
Btw ask Josh what exact branches are, I dont remember anymore, I think
"cassandta-4.0" and CASSANDRA-16956-trunk in instaslustr repo.
We might go with trunk branch only too if we think this is too much for 4.0.x
but Brandon seems to eant that happen, I dont mind.
Sent from ProtonMail mobile
\
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: signature.asc, signature.asc
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17084) startup fails if directories do not exist
[
https://issues.apache.org/jira/browse/CASSANDRA-17084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17471803#comment-17471803
]
Berenguer Blasi commented on CASSANDRA-17084:
-
They seem to be failing [~brandon.williams]?
> startup fails if directories do not exist
> -
>
> Key: CASSANDRA-17084
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17084
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1
>
>
> Prior to CASSANDRA-16926, having commitlog and data dirs defined that did not
> exist would be created on startup, but now we throw:
> {noformat}
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Unable check disk space in
> 'bin/../data/commitlog'. Perhaps the Cassandra user does not have the
> necessary permissions
> org.apache.cassandra.exceptions.ConfigurationException: Unable check disk
> space in 'bin/../data/commitlog'. Perhaps the Cassandra user does not have
> the necessary permissions
> at
> org.apache.cassandra.config.DatabaseDescriptor.lambda$tryGetSpace$3(DatabaseDescriptor.java:1188)
> at
> org.apache.cassandra.io.util.PathUtils.tryOnFileStore(PathUtils.java:639)
> at
> org.apache.cassandra.io.util.PathUtils.tryGetSpace(PathUtils.java:665)
> at
> org.apache.cassandra.config.DatabaseDescriptor.tryGetSpace(DatabaseDescriptor.java:1188)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySimpleConfig(DatabaseDescriptor.java:553)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:350)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:178)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:162)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:800)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:736)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:871)
> {noformat}
> This was at least convenient for development, but also may be relied upon by
> some tooling/automation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
miklosovic updated CASSANDRA-16956:
---
Attachment: signature.asc
I am off till February, I pushed one dead code removal for trunk so you might
see different stuff but it is all same.
Sent from ProtonMail mobile
\
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: signature.asc
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17084) startup fails if directories do not exist
[
https://issues.apache.org/jira/browse/CASSANDRA-17084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17084:
Reviewers: Berenguer Blasi
> startup fails if directories do not exist
> -
>
> Key: CASSANDRA-17084
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17084
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.1
>
>
> Prior to CASSANDRA-16926, having commitlog and data dirs defined that did not
> exist would be created on startup, but now we throw:
> {noformat}
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Unable check disk space in
> 'bin/../data/commitlog'. Perhaps the Cassandra user does not have the
> necessary permissions
> org.apache.cassandra.exceptions.ConfigurationException: Unable check disk
> space in 'bin/../data/commitlog'. Perhaps the Cassandra user does not have
> the necessary permissions
> at
> org.apache.cassandra.config.DatabaseDescriptor.lambda$tryGetSpace$3(DatabaseDescriptor.java:1188)
> at
> org.apache.cassandra.io.util.PathUtils.tryOnFileStore(PathUtils.java:639)
> at
> org.apache.cassandra.io.util.PathUtils.tryGetSpace(PathUtils.java:665)
> at
> org.apache.cassandra.config.DatabaseDescriptor.tryGetSpace(DatabaseDescriptor.java:1188)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySimpleConfig(DatabaseDescriptor.java:553)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:350)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:178)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:162)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:800)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:736)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:871)
> {noformat}
> This was at least convenient for development, but also may be relied upon by
> some tooling/automation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17471776#comment-17471776
]
Berenguer Blasi edited comment on CASSANDRA-16956 at 1/10/22, 9:29 AM:
---
Hi [~stefan.miklosovic],
I see you posted CI results for 4.0 and trunk but I have trouble connecting all
the dots. I.e. circle 4.0 run is on SHA 31f5b7e but I can't find that SHA
either on the PR or the branch mentioned (I might have also missed sthg). Would
you be so kind to post PR/CI pairs links for 4.0 and trunk please?
Also given this is touching shell and python I would suggest running all circle
tests like the upgrade ones and also including a jenkins dev-branch run. On top
of that I would ping Mick just to sanity check if there are any 'release' jobs
we could run to test they still work. We've had instances of files removal
breaking releases bc some rpm or God knows what starts to fail.
Makes sense?
was (Author: bereng):
Hi [~stefan.miklosovic],
I see you posted CI results for 4.0 and trunk but I have trouble connecting all
the dots. I.e. circle 4.0 run is on SHA 31f5b7e but I can't find that SHA
either on the PR or the branch mentioned (I might have also missed sthg). Would
you be so kind to post PR/CI pairs links for 4.0 and trunk please?
Also given this is touching shell and python I would suggest running all circle
tests like the upgrade ones and also including a jenkins dev-branch run.
Makes sense?
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17063) Make capacity/validity/updateinterval/activeupdate for Auth Caches configurable via nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-17063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-17063:
--
Fix Version/s: 4.1
(was: 4.x)
Source Control Link:
https://github.com/apache/cassandra/commit/bc20bddcebd6a37b14cfbdd50c359be4c9743f73
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Make capacity/validity/updateinterval/activeupdate for Auth Caches
> configurable via nodetool
>
>
> Key: CASSANDRA-17063
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17063
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.1
>
>
> Currently Auth Caches configuration options
> (capacity/validity/updateinterval/activeupdate) exposed via JMX or yaml only.
> We need to introduce a _nodetool setauthcachecconfig_ and _nodetool
> getauthcachecconfig_ commands.
> Also we could think of some VT-based alternative to {_}nodetool{_}. But I
> feel there is no need to have a separate table for Auth Caches configs. It
> would be an overhead. Ideally we need to have a separate VT that shows/sets
> all the configs, but it is out of the scope.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Make capacity/validity/updateinterval/activeupdate for Auth Caches configurable via nodetool
This is an automated email from the ASF dual-hosted git repository.
azotcsit pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new bc20bdd Make capacity/validity/updateinterval/activeupdate for Auth
Caches configurable via nodetool
bc20bdd is described below
commit bc20bddcebd6a37b14cfbdd50c359be4c9743f73
Author: Aleksei Zotov
AuthorDate: Mon Dec 20 21:26:41 2021 +0400
Make capacity/validity/updateinterval/activeupdate for Auth Caches
configurable via nodetool
patch by Aleksei Zotov; reviewed by Josh McKenzie for CASSANDRA-17063
---
CHANGES.txt| 1 +
NEWS.txt | 1 +
src/java/org/apache/cassandra/tools/NodeProbe.java | 20 +++
src/java/org/apache/cassandra/tools/NodeTool.java | 2 +
.../tools/nodetool/GetAuthCacheConfig.java | 47 +
.../tools/nodetool/InvalidatePermissionsCache.java | 2 +-
.../tools/nodetool/SetAuthCacheConfig.java | 114 +
.../tools/nodetool/GetAuthCacheConfigTest.java | 141 +++
.../nodetool/InvalidateCredentialsCacheTest.java | 14 +-
.../InvalidateJmxPermissionsCacheTest.java | 21 ++-
.../InvalidateNetworkPermissionsCacheTest.java | 12 +-
.../nodetool/InvalidatePermissionsCacheTest.java | 16 +-
.../tools/nodetool/InvalidateRolesCacheTest.java | 12 +-
.../tools/nodetool/SetAuthCacheConfigTest.java | 189 +
14 files changed, 549 insertions(+), 43 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 9cf76fd..2ef9307 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.1
+ * Make capacity/validity/updateinterval/activeupdate for Auth Caches
configurable via nodetool (CASSANDRA-17063)
* Added startup check for read_ahead_kb setting (CASSANDRA-16436)
* Avoid unecessary array allocations and initializations when performing
query checks (CASSANDRA-17209)
* Add guardrail for list operations that require read before write
(CASSANDRA-17154)
diff --git a/NEWS.txt b/NEWS.txt
index b46fb56..ffa909d 100644
--- a/NEWS.txt
+++ b/NEWS.txt
@@ -38,6 +38,7 @@ using the provided 'sstableupgrade' tool.
New features
+- Added ability to configure auth caches through corresponding `nodetool`
commands.
- CDC data flushing now can be configured to be non-blocking with the
configuration cdc_block_writes. Setting to true,
any writes to the CDC-enabled tables will be blocked when reaching to
the limit for CDC data on disk, which is the
existing and the default behavior. Setting to false, the writes to the
CDC-enabled tables will be accepted and
diff --git a/src/java/org/apache/cassandra/tools/NodeProbe.java
b/src/java/org/apache/cassandra/tools/NodeProbe.java
index 1347aa0..73d2cbf 100644
--- a/src/java/org/apache/cassandra/tools/NodeProbe.java
+++ b/src/java/org/apache/cassandra/tools/NodeProbe.java
@@ -61,6 +61,7 @@ import org.apache.cassandra.audit.AuditLogOptions;
import org.apache.cassandra.audit.AuditLogOptionsCompositeData;
import com.google.common.collect.ImmutableMap;
import org.apache.cassandra.auth.AuthCache;
+import org.apache.cassandra.auth.AuthCacheMBean;
import org.apache.cassandra.auth.NetworkPermissionsCache;
import org.apache.cassandra.auth.NetworkPermissionsCacheMBean;
import org.apache.cassandra.auth.PasswordAuthenticator;
@@ -569,6 +570,25 @@ public class NodeProbe implements AutoCloseable
cacheService.invalidateRowCache();
}
+public AuthCacheMBean getAuthCacheMBean(String cacheName)
+{
+switch (cacheName)
+{
+case PasswordAuthenticator.CredentialsCacheMBean.CACHE_NAME:
+return ccProxy;
+case AuthorizationProxy.JmxPermissionsCacheMBean.CACHE_NAME:
+return jpcProxy;
+case NetworkPermissionsCacheMBean.CACHE_NAME:
+return npcProxy;
+case PermissionsCacheMBean.CACHE_NAME:
+return pcProxy;
+case RolesCacheMBean.CACHE_NAME:
+return rcProxy;
+default:
+throw new IllegalArgumentException("Unknown cache name: " +
cacheName);
+}
+}
+
public void drain() throws IOException, InterruptedException,
ExecutionException
{
ssProxy.drain();
diff --git a/src/java/org/apache/cassandra/tools/NodeTool.java
b/src/java/org/apache/cassandra/tools/NodeTool.java
index dd85f10..f9422bd 100644
--- a/src/java/org/apache/cassandra/tools/NodeTool.java
+++ b/src/java/org/apache/cassandra/tools/NodeTool.java
@@ -129,6 +129,7 @@ public class NodeTool
GarbageCollect.class,
GcStats.class,
GetAuditLog.class,
+GetAuthCacheConfig.class,
GetBatchlogReplayTrottle.class,
GetColumnIndexSize.class,
[jira] [Comment Edited] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17471776#comment-17471776
]
Berenguer Blasi edited comment on CASSANDRA-16956 at 1/10/22, 9:04 AM:
---
Hi [~stefan.miklosovic],
I see you posted CI results for 4.0 and trunk but I have trouble connecting all
the dots. I.e. circle 4.0 run is on SHA 31f5b7e but I can't find that SHA
either on the PR or the branch mentioned (I might have also missed sthg). Would
you be so kind to post PR/CI pairs links for 4.0 and trunk please?
Also given this is touching shell and python I would suggest running all circle
tests like the upgrade ones and also including a jenkins dev-branch run.
Makes sense?
was (Author: bereng):
Hi [~stefan.miklosovic],
I see you posted CI results for 4.0 and trunk but I have trouble connecting all
the dots. I.e. circle 4.0 run is on SHA 31f5b7e but I can't find that SHA
either on the PR or the branch mentioned (I might have also missed sthg). Would
you be so kind to post PR/CI pairs links for 4.0 and trunk please?
Also given this is touching shell and python I would suggest running all circle
tests like the update ones and also including a jenkins dev-branch run.
Makes sense?
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16956) Remove windows-specific classes
[
https://issues.apache.org/jira/browse/CASSANDRA-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17471776#comment-17471776
]
Berenguer Blasi commented on CASSANDRA-16956:
-
Hi [~stefan.miklosovic],
I see you posted CI results for 4.0 and trunk but I have trouble connecting all
the dots. I.e. circle 4.0 run is on SHA 31f5b7e but I can't find that SHA
either on the PR or the branch mentioned (I might have also missed sthg). Would
you be so kind to post PR/CI pairs links for 4.0 and trunk please?
Also given this is touching shell and python I would suggest running all circle
tests like the update ones and also including a jenkins dev-branch run.
Makes sense?
> Remove windows-specific classes
> ---
>
> Key: CASSANDRA-16956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16956
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Brandon Williams
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> To continue the work CASSANDRA-16171 began, now that Windows support is no
> more there are some source files that can be removed.
> Just doing a naive grep on the source directory I see:
> {noformat}
> src/java/org/apache/cassandra/db/WindowsFailedSnapshotTracker.java
> src/java/org/apache/cassandra/utils/NativeLibraryWindows.java
> src/java/org/apache/cassandra/utils/WindowsTimer.java
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14879) Log DDL statements on coordinator
[
https://issues.apache.org/jira/browse/CASSANDRA-14879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-14879:
Reviewers: Berenguer Blasi
> Log DDL statements on coordinator
> -
>
> Key: CASSANDRA-14879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14879
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Sylvain Lebresne
>Assignee: Patrick Lee
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> People sometimes run into issues with schema, and that is often because they
> do concurrent schema changes, which are just not supported and we should fix
> that someday, but in the meantime, it's not always easy to even check if you
> may indeed have had concurrent schema changes.
> A very trivial way to make that easier would be to simply log DDL statements
> on the coordinator before they are executed. This is likely useful info for
> operators in the first place, and would allow in most case to track if
> concurrent schema was the likely cause of a particular issue seen.
> +Additional info for newcomers:+
> In order to implement this change you will need to modify
> {{org.apache.cassandra.cql3.QueryProcessor}} to log the schema change before
> it is executed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
