[jira] [Comment Edited] (CASSANDRA-16919) cassandra local_quorum query is inconsistent
[
https://issues.apache.org/jira/browse/CASSANDRA-16919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411625#comment-17411625
]
Brandon Williams edited comment on CASSANDRA-16919 at 9/8/21, 2:06 AM:
---
2.0.17 became 8 years old 4 days ago, I'm not sure how much older 2.0.15 is but
the entire 2.0 line's ship has sailed many years ago. An upgrade to 2.0.17 may
help, otherwise please upgrade to at least the minimum version where we can
assist you: https://cassandra.apache.org/_/download.html
was (Author: brandon.williams):
2.0.17 became 8 years old 4 days ago, I'm not sure how much older 2.0.15 is but
then 2.0 line's ship has sailed many years ago. An upgrade to 2.0.17 may help,
otherwise please upgrade to at least the minimum version where we can assist
you: https://cassandra.apache.org/_/download.html
> cassandra local_quorum query is inconsistent
>
>
> Key: CASSANDRA-16919
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16919
> Project: Cassandra
> Issue Type: Bug
>Reporter: HUANG DUICAN
>Priority: Normal
>
> cassandra version: 2.0.15
> Number of nodes: dc1: 80, dc2: 80
> problem:
> Our copy strategy is as follows:
> WITH REPLICATION = \{'class':'NetworkTopologyStrategy','dc1': 3,'dc2': 3};
> We encountered a problem with cassandra, and it was inconsistent when
> querying with local_quorum. We will only read and write in dc1.
> We also use local_quorum for writing, and then use local_quorum for queries.
> But there is a phenomenon, use the following statement:
> select count(*) from table where partitionKey=?
> The results of the query were initially inconsistent and eventually
> consistent.
> Assuming that the first is 1, the second is 9998, and the third is 9997,
> it may remain at 10001 in the end(Maybe it was triggered to read repair,
> which led to the final stabilization) .
> During this period, we have done a large-scale expansion. And make sure that
> every machine is cleaned up. And we also found that the results of using
> getEndpointon different machines are inconsistent.
> In the end, we found that the result of getEndpoint has 4 machines in dc1.
> Then we executed getSstable on the corresponding 4 machines, only 3 machines
> showed the results, and the other machine did not show the results. At the
> same time, we encountered a similar problem with another partitionKey, but
> this partitionKey was only queried once, because we recorded the total number
> of partitionKey in another place, and we can confirm that the total number of
> partitionKey is incorrect.
> After we restarted each machine of dc1 one by one, this problem was solved.
> The total number of partitionKey is consistent with the result recorded by
> us, and if the same query is done multiple times, the result will not change.
> Therefore, I suspect that the gossip synchronization node information is too
> slow, which may lead to inconsistent final results when selecting nodes for
> query.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16919) cassandra local_quorum query is inconsistent
[
https://issues.apache.org/jira/browse/CASSANDRA-16919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16919:
-
Resolution: Won't Fix
Status: Resolved (was: Triage Needed)
2.0.17 became 8 years old 4 days ago, I'm not sure how much older 2.0.15 is but
then 2.0 line's ship has sailed many years ago. An upgrade to 2.0.17 may help,
otherwise please upgrade to at least the minimum version where we can assist
you: https://cassandra.apache.org/_/download.html
> cassandra local_quorum query is inconsistent
>
>
> Key: CASSANDRA-16919
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16919
> Project: Cassandra
> Issue Type: Bug
>Reporter: HUANG DUICAN
>Priority: Normal
>
> cassandra version: 2.0.15
> Number of nodes: dc1: 80, dc2: 80
> problem:
> Our copy strategy is as follows:
> WITH REPLICATION = \{'class':'NetworkTopologyStrategy','dc1': 3,'dc2': 3};
> We encountered a problem with cassandra, and it was inconsistent when
> querying with local_quorum. We will only read and write in dc1.
> We also use local_quorum for writing, and then use local_quorum for queries.
> But there is a phenomenon, use the following statement:
> select count(*) from table where partitionKey=?
> The results of the query were initially inconsistent and eventually
> consistent.
> Assuming that the first is 1, the second is 9998, and the third is 9997,
> it may remain at 10001 in the end(Maybe it was triggered to read repair,
> which led to the final stabilization) .
> During this period, we have done a large-scale expansion. And make sure that
> every machine is cleaned up. And we also found that the results of using
> getEndpointon different machines are inconsistent.
> In the end, we found that the result of getEndpoint has 4 machines in dc1.
> Then we executed getSstable on the corresponding 4 machines, only 3 machines
> showed the results, and the other machine did not show the results. At the
> same time, we encountered a similar problem with another partitionKey, but
> this partitionKey was only queried once, because we recorded the total number
> of partitionKey in another place, and we can confirm that the total number of
> partitionKey is incorrect.
> After we restarted each machine of dc1 one by one, this problem was solved.
> The total number of partitionKey is consistent with the result recorded by
> us, and if the same query is done multiple times, the result will not change.
> Therefore, I suspect that the gossip synchronization node information is too
> slow, which may lead to inconsistent final results when selecting nodes for
> query.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-16919) cassandra local_quorum query is inconsistent
HUANG DUICAN created CASSANDRA-16919:
Summary: cassandra local_quorum query is inconsistent
Key: CASSANDRA-16919
URL: https://issues.apache.org/jira/browse/CASSANDRA-16919
Project: Cassandra
Issue Type: Bug
Reporter: HUANG DUICAN
cassandra version: 2.0.15
Number of nodes: dc1: 80, dc2: 80
problem:
Our copy strategy is as follows:
WITH REPLICATION = \{'class':'NetworkTopologyStrategy','dc1': 3,'dc2': 3};
We encountered a problem with cassandra, and it was inconsistent when querying
with local_quorum. We will only read and write in dc1.
We also use local_quorum for writing, and then use local_quorum for queries.
But there is a phenomenon, use the following statement:
select count(*) from table where partitionKey=?
The results of the query were initially inconsistent and eventually consistent.
Assuming that the first is 1, the second is 9998, and the third is 9997, it
may remain at 10001 in the end(Maybe it was triggered to read repair, which led
to the final stabilization) .
During this period, we have done a large-scale expansion. And make sure that
every machine is cleaned up. And we also found that the results of using
getEndpointon different machines are inconsistent. In
the end, we found that the result of getEndpoint has 4 machines in dc1.
Then we executed getSstable on the corresponding 4 machines, only 3 machines
showed the results, and the other machine did not show the results. At the same
time, we encountered a similar problem with another partitionKey, but this
partitionKey was only queried once, because we recorded the total number of
partitionKey in another place, and we can confirm that the total number of
partitionKey is incorrect.
After we restarted each machine of dc1 one by one, this problem was solved.
The total number of partitionKey is consistent with the result recorded by us,
and if the same query is done multiple times, the result will not change.
Therefore, I suspect that the gossip synchronization node information is too
slow, which may lead to inconsistent final results when selecting nodes for
query.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15975) SEP.shutdownAndWait does not wait for termination and SEPExecutor.awaitTermination may hang
[ https://issues.apache.org/jira/browse/CASSANDRA-15975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411511#comment-17411511 ] Benedict Elliott Smith commented on CASSANDRA-15975: Sorry, I guess this one well entirely off my plate. Don't even remember it! No objection, of course. > SEP.shutdownAndWait does not wait for termination and > SEPExecutor.awaitTermination may hang > --- > > Key: CASSANDRA-15975 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15975 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > > SharedExecutorPool.shutdownAndWait calls shutdownNow on the executors it > owns, which has the side effect of removing the executor from the list, then > uses the same emptied list to try and wait for them to complete shutting > down, which completes immediately. > > Once fixed by copying the list in SEP.shutdownAndWait, the SEPExecutorTest > suite fails with a timeout due to a startup race in SEPWorker. > > If a SEPExecutor is shutdown immediately after maybeSchedule creates a new > SEPWorker, > but before it is able to execute the first task then it exits immediately on > entering the work loop with a work and task permit reserved for it, which > invalidates the work/task permit accounting and prevents calling the shutdown > SimpleCondition.signalAll when the last SEPWorker exits. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16841) Unexpectedly ignored dtests
[
https://issues.apache.org/jira/browse/CASSANDRA-16841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411510#comment-17411510
]
Ekaterina Dimitrova commented on CASSANDRA-16841:
-
{quote}However the message is not printed on stdout with the default config.
{quote}
Yes, that's what I meant but as I said, we can always do it as a separate
improvement if we want to.
I am in for preserving the behavior around the two flags, the rest looks good
and that was definitely a good catch that the tests are not running. Thanks!
> Unexpectedly ignored dtests
> ---
>
> Key: CASSANDRA-16841
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16841
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ruslan Fomkin
>Assignee: Ruslan Fomkin
>Priority: Normal
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> An issue, which I was hit:
> When one class in a dtest file is marked as resource intensive, then all
> tests in all classes are treated as resource intensive. For example,
> [repair_tests/repair_test.py|https://github.com/apache/cassandra-dtest/blob/trunk/repair_tests/repair_test.py]
> contains three classes and the last class is marked as resource intensive:
> {code:java}
> @pytest.mark.resource_intensive
> class TestRepairDataSystemTable(Tester):
> {code}
> So if I try to run an unmarked class:
> {code:java}
> pytest --cassandra-dir=../cassandra repair_tests/repair_test.py::TestRepair
> --collect-only --skip-resource-intensive-tests
> {code}
> then all tests are ignored
> {code:java}
> collected 36 items / 36 deselected
> {code}
> This is because a test is treated to be marked if any class in the same file
> has the mark. This bug was introduced in the fix of CASS-16399. Before only
> upgrade tests had such behaviour, i.e., if a class is marked as upgrade test,
> then all tests are upgrade test in the file.
>
> This bug, for example, means that if the same file contains one class marked
> with vnodes and another class with no_vnodes, then no tests will be executed
> in the file.
> I also noticed another issue that If a test run is executed with the argument
> {{-only-resource-intensive-tests}} and there is no sufficient resources for
> resource intensive tests, then no tests were executed. Thus it was necessary
> to provide {{-force-resource-intensive-tests}} in addition.
> Suggestions for the solutions:
> # Require to mark each class and remove the special case of upgrade tests.
> This will simplify the implementation and might be more obvious for new
> comers.
> # Treat {{-only-resource-intensive-tests}} in the same way as
> {{-force-resource-intensive-tests}}, so it will be enough to just specify it
> even with no sufficient resources.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15975) SEP.shutdownAndWait does not wait for termination and SEPExecutor.awaitTermination may hang
[ https://issues.apache.org/jira/browse/CASSANDRA-15975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411489#comment-17411489 ] Jon Meredith commented on CASSANDRA-15975: -- Not any more! At the time it was needing a second committer, but I can bring it up to date and merge it myself now as long as [~benedict] doesn't object. > SEP.shutdownAndWait does not wait for termination and > SEPExecutor.awaitTermination may hang > --- > > Key: CASSANDRA-15975 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15975 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > > SharedExecutorPool.shutdownAndWait calls shutdownNow on the executors it > owns, which has the side effect of removing the executor from the list, then > uses the same emptied list to try and wait for them to complete shutting > down, which completes immediately. > > Once fixed by copying the list in SEP.shutdownAndWait, the SEPExecutorTest > suite fails with a timeout due to a startup race in SEPWorker. > > If a SEPExecutor is shutdown immediately after maybeSchedule creates a new > SEPWorker, > but before it is able to execute the first task then it exits immediately on > entering the work loop with a work and task permit reserved for it, which > invalidates the work/task permit accounting and prevents calling the shutdown > SimpleCondition.signalAll when the last SEPWorker exits. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16851) Update from Jackson 2.9 to 2.12
[
https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411472#comment-17411472
]
Ekaterina Dimitrova commented on CASSANDRA-16851:
-
{quote}So I think going via `BufferRecyclers` makes sense now and maybe move
"back" to `JsonStringEncoder.getInstance()` when Cassandra upgrades to Jackson
2.13 or later 2.x?
Does above make sense? (the whole thing being a mess, but that aside :) )
{quote}
+1, I had similar thoughts, let's see whether [~mck] and [~brandon.williams]
agree :)
> Update from Jackson 2.9 to 2.12
> ---
>
> Key: CASSANDRA-16851
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16851
> Project: Cassandra
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Tatu Saloranta
>Assignee: Tatu Saloranta
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> Given that Jackson 2.9 support has ended, it would be good to move at least
> to the next minor version (2.10, patch 2.10.5) or later – latest stable being
> 2.12.4.
> I can test to see if anything breaks, but looking at existing Jackson usage
> there shouldn't be many issues.
> Assuming upgrade is acceptable there's the question of which branches to
> apply it to; I will first test it against 4.0.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16718) Changing listen_address with prefer_local may lead to issues
[ https://issues.apache.org/jira/browse/CASSANDRA-16718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411468#comment-17411468 ] Brandon Williams edited comment on CASSANDRA-16718 at 9/7/21, 8:38 PM: --- Actually, CASSANDRA-10134 didn't break this, but it fixed the server's behavior such that the test was deterministic after it; before we will mark the node up, but then fail to connect to the old IP forever and eventually mark the node back down due to lack of communication, tricking the test into thinking it passed. :( I will keep digging, but I suspect the solution is likely the same: don't persist and use preferred_ip, only the gossip state that is present. was (Author: brandon.williams): Actually, CASSANDRA-10134 didn't break this, but it fixed the server's behavior such that the test was deterministic after it; before we will mark the node up, but then fail to connect to the old IP forever and eventually mark the node back down due to lack of communication, tricking the test into thinking it passed. :( I will keep digging. > Changing listen_address with prefer_local may lead to issues > > > Key: CASSANDRA-16718 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16718 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Jan Karlsson >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.11.x, 4.0.x > > > Many container based solution function by assigning new listen_addresses when > nodes are stopped. Changing the listen_address is usually as simple as > turning off the node and changing the yaml file. > However, if prefer_local is enabled, I observed that nodes were unable to > join the cluster and fail with 'Unable to gossip with any seeds'. > Trace shows that the changing node will try to communicate with the existing > node but the response is never received. I assume it is because the existing > node attempts to communicate with the local address during the shadow round. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16851) Update from Jackson 2.9 to 2.12
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411470#comment-17411470 ] Tatu Saloranta commented on CASSANDRA-16851: [~e.dimitrova] gotcha wrt 3.0; since it is Jackson 1.x, this would not apply (and adding Jackson 2.x would do no good; it wouldn't be used). I did not realize upgrade happened after 3.0; 3.11 and later use Jackson 2.x. As to `BufferRecyclers.getJsonStringEncoder()`: it has bit of an "interesting" history, and was not meant for use by code outside Jackson. During Jackson 2.9 there was an attempt for safe recycling of underlying buffers of encoder, which lead to complicated handling via `BufferRecyclers`. This was removed in 2.10, along with making encoder stateless, but without considering compatibility aspects (i.e. removing accessor method). I added old method back in 2.12.5 to address this. With Jackson 2.13 (when it gets released), the recommended way is to just call `JsonStringEncoder.getInstance()`; there is no buffer recycling (underlying buffer is calculated to be about optimal size). With 2.12.x this method is safe to use as well. But for 2.12 I added method `BufferRecyclers.getJsonEncoder()` (and related) back for compatibility reasons, but marked "deprecated" so that there would not be additional use. It is not meant to indicate imminent removal (methods won't be removed before 3.0). So I think going via `BufferRecyclers` makes sense now and maybe move "back" to `JsonStringEncoder.getInstance()` when Cassandra upgrades to Jackson 2.13 or later 2.x? Does above make sense? (the whole thing being a mess, but that aside :) ) > Update from Jackson 2.9 to 2.12 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > Time Spent: 3h 40m > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5) or later – latest stable being > 2.12.4. > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.0. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16718) Changing listen_address with prefer_local may lead to issues
[ https://issues.apache.org/jira/browse/CASSANDRA-16718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411468#comment-17411468 ] Brandon Williams commented on CASSANDRA-16718: -- Actually, CASSANDRA-10134 didn't break this, but it fixed the server's behavior such that the test was deterministic after it; before we will mark the node up, but then fail to connect to the old IP forever and eventually mark the node back down due to lack of communication, tricking the test into thinking it passed. :( I will keep digging. > Changing listen_address with prefer_local may lead to issues > > > Key: CASSANDRA-16718 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16718 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Jan Karlsson >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.11.x, 4.0.x > > > Many container based solution function by assigning new listen_addresses when > nodes are stopped. Changing the listen_address is usually as simple as > turning off the node and changing the yaml file. > However, if prefer_local is enabled, I observed that nodes were unable to > join the cluster and fail with 'Unable to gossip with any seeds'. > Trace shows that the changing node will try to communicate with the existing > node but the response is never received. I assume it is because the existing > node attempts to communicate with the local address during the shadow round. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16718) Changing listen_address with prefer_local may lead to issues
[
https://issues.apache.org/jira/browse/CASSANDRA-16718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17409614#comment-17409614
]
Brandon Williams edited comment on CASSANDRA-16718 at 9/7/21, 8:31 PM:
---
-This issue boils down to CASSANDRA-10134 loading the ring state, which
includes preferred_ip.- OTC then queries this directly if it exists and uses
it before any changes can be learned. Given this, I'm not sure it even makes
sense to store the preferred_ip, since if we try to use it eagerly we'll never
be able to learn of the change to it, as this issue exemplifies. I think the
best plan is just to remove this optimization and do the reconnection dance
every time, which still shouldn't be super-often. WDYT, [~samt]?
-In the meantime, operators may add {{-Dcassandra.load_ring_state=false}} if
that's an acceptable workaround.-
was (Author: brandon.williams):
-This issue boils down to CASSANDRA-10134 loading the ring state, which
includes preferred_ip.- OTC then queries this directly if it exists and uses
it before any changes can be learned. Given this, I'm not sure it even makes
sense to store the preferred_ip, since if we try to use it eagerly we'll never
be able to learn of the change to it, as this issue exemplifies. I think the
best plan is just to remove this optimization and do the reconnection dance
every time, which still shouldn't be super-often. WDYT, [~samt]?
In the meantime, operators may add {{-Dcassandra.load_ring_state=false}} if
that's an acceptable workaround.
> Changing listen_address with prefer_local may lead to issues
>
>
> Key: CASSANDRA-16718
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16718
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Jan Karlsson
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
>
> Many container based solution function by assigning new listen_addresses when
> nodes are stopped. Changing the listen_address is usually as simple as
> turning off the node and changing the yaml file.
> However, if prefer_local is enabled, I observed that nodes were unable to
> join the cluster and fail with 'Unable to gossip with any seeds'.
> Trace shows that the changing node will try to communicate with the existing
> node but the response is never received. I assume it is because the existing
> node attempts to communicate with the local address during the shadow round.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16718) Changing listen_address with prefer_local may lead to issues
[
https://issues.apache.org/jira/browse/CASSANDRA-16718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17409614#comment-17409614
]
Brandon Williams edited comment on CASSANDRA-16718 at 9/7/21, 8:31 PM:
---
-This issue boils down to CASSANDRA-10134 loading the ring state, which
includes preferred_ip.- OTC then queries this directly if it exists and uses
it before any changes can be learned. Given this, I'm not sure it even makes
sense to store the preferred_ip, since if we try to use it eagerly we'll never
be able to learn of the change to it, as this issue exemplifies. I think the
best plan is just to remove this optimization and do the reconnection dance
every time, which still shouldn't be super-often. WDYT, [~samt]?
In the meantime, operators may add {{-Dcassandra.load_ring_state=false}} if
that's an acceptable workaround.
was (Author: brandon.williams):
This issue boils down to CASSANDRA-10134 loading the ring state, which includes
preferred_ip. OTC then queries this directly if it exists and uses it before
any changes can be learned. Given this, I'm not sure it even makes sense to
store the preferred_ip, since if we try to use it eagerly we'll never be able
to learn of the change to it, as this issue exemplifies. I think the best plan
is just to remove this optimization and do the reconnection dance every time,
which still shouldn't be super-often. WDYT, [~samt]?
In the meantime, operators may add {{-Dcassandra.load_ring_state=false}} if
that's an acceptable workaround.
> Changing listen_address with prefer_local may lead to issues
>
>
> Key: CASSANDRA-16718
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16718
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Jan Karlsson
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.11.x, 4.0.x
>
>
> Many container based solution function by assigning new listen_addresses when
> nodes are stopped. Changing the listen_address is usually as simple as
> turning off the node and changing the yaml file.
> However, if prefer_local is enabled, I observed that nodes were unable to
> join the cluster and fail with 'Unable to gossip with any seeds'.
> Trace shows that the changing node will try to communicate with the existing
> node but the response is never received. I assume it is because the existing
> node attempts to communicate with the local address during the shadow round.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16718) Changing listen_address with prefer_local may lead to issues
[ https://issues.apache.org/jira/browse/CASSANDRA-16718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17408402#comment-17408402 ] Brandon Williams edited comment on CASSANDRA-16718 at 9/7/21, 8:30 PM: --- -This has been broken since CASSANDRA-10134, though I'm not sure how yet-. What is strange to me is that this issue persists even if both nodes are restarted, so something is being persisted incorrectly here. was (Author: brandon.williams): This has been broken since CASSANDRA-10134, though I'm not sure how yet. What is strange to me is that this issue persists even if both nodes are restarted, so something is being persisted incorrectly here. I'll have to look more tomorrow. > Changing listen_address with prefer_local may lead to issues > > > Key: CASSANDRA-16718 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16718 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Jan Karlsson >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.11.x, 4.0.x > > > Many container based solution function by assigning new listen_addresses when > nodes are stopped. Changing the listen_address is usually as simple as > turning off the node and changing the yaml file. > However, if prefer_local is enabled, I observed that nodes were unable to > join the cluster and fail with 'Unable to gossip with any seeds'. > Trace shows that the changing node will try to communicate with the existing > node but the response is never received. I assume it is because the existing > node attempts to communicate with the local address during the shadow round. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16851) Update from Jackson 2.9 to 2.12
[ https://issues.apache.org/jira/browse/CASSANDRA-16851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411462#comment-17411462 ] Ekaterina Dimitrova commented on CASSANDRA-16851: - On a second reading I think the upgrade in 3.0 probably didn't happen intentionally as we actually have there Jackson-core-asl and Jackson-mapper-asl which migrated in Jackson 2. So I opted out of touching those for now. CC [~tatu-at-datastax] if he wants to add something on this. Then I started the update for 3.11 and here it becomes interesting. It seems there we use _BufferRecyclers.getJsonStringEncoder()_ which change has happened in CASSANDRA-14427(Bump jackson version to >= 2.9.5). Initially the method used was _JsonStringEncoder.getInstance(),_ added in __ CASSANDRA-11048 (Make SELECT JSON and toJson() threadsafe) Not sure now which method is more correct to use at this point. Thoughts? > Update from Jackson 2.9 to 2.12 > --- > > Key: CASSANDRA-16851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16851 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Tatu Saloranta >Assignee: Tatu Saloranta >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > Time Spent: 3h 40m > Remaining Estimate: 0h > > Given that Jackson 2.9 support has ended, it would be good to move at least > to the next minor version (2.10, patch 2.10.5) or later – latest stable being > 2.12.4. > I can test to see if anything breaks, but looking at existing Jackson usage > there shouldn't be many issues. > Assuming upgrade is acceptable there's the question of which branches to > apply it to; I will first test it against 4.0. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16787) Copy from csv file with duration type fields fails to import
[
https://issues.apache.org/jira/browse/CASSANDRA-16787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16787:
---
Fix Version/s: (was: 4.0.1)
4.0.x
> Copy from csv file with duration type fields fails to import
>
>
> Key: CASSANDRA-16787
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16787
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Brijesh Dungarakoti
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0.x
>
> Attachments: error_cassandra_copy_from_1.JPG,
> error_cassandra_copy_from_2.JPG
>
>
> Getting error:
> {code:java}
> cqlsh> COPY users.user_credentials_by_email FROM '/home/ubuntu/users.csv'
> WITH HEADER = FALSE AND NULL='null';
> Using 3 child processes
> Starting copy of users.user_credentials_by_email with columns [email,
> la_duration].
> Failed to make batch statement: Received an argument of invalid type for
> column "la_duration". Expected: ,
> Got: ; (DurationType arguments must be a Duration.)_
> Failed to import 1 rows: TypeError - Received an argument of invalid type for
> column "la_duration". Expected: ,
> Got: ; (DurationType arguments must be a Duration.), given up
> without retries
> Failed to process 1 rows; failed rows written to
> import_users_user_credentials_by_email.err
> Processed: 1 rows; Rate: 2 rows/s; Avg. rate: 2 rows/s
> 0 rows imported from 1 files in 0.431 seconds (0 skipped).
> {code}
> *To Reproduce:*
> {code:java}
> CREATE KEYSPACE users WITH replication = {'class': 'NetworkTopologyStrategy',
> 'datacenter1': '1'} AND durable_writes = true;
> CREATE TABLE users.user_credentials_by_email (
> email text,
> la_duration duration,
> PRIMARY KEY(email)
> );
> {code}
> create users.csv file with:
> {code:java}
> l...@la.com,8m26s482ms
> {code}
> Run:
> {code:java}
> COPY users.user_credentials_by_email FROM '/home/automaton/users.csv' WITH
> HEADER = FALSE AND NULL='null';
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16471) org.apache.cassandra.io.util.DataOutputBuffer#scratchBuffer is around 50% of all memory allocations
[ https://issues.apache.org/jira/browse/CASSANDRA-16471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16471: --- Fix Version/s: (was: 4.0.1) (was: 4.1) 4.x 4.0.x > org.apache.cassandra.io.util.DataOutputBuffer#scratchBuffer is around 50% of > all memory allocations > --- > > Key: CASSANDRA-16471 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16471 > Project: Cassandra > Issue Type: Improvement > Components: Local/Caching >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0.x, 4.x > > Attachments: Screen Shot 2021-02-25 at 3.34.28 PM.png, Screen Shot > 2021-02-25 at 4.14.19 PM.png > > > While running workflows to compare 3.0 with trunk we found that allocations > and GC are significantly higher for a write mostly workload (22% read, 3% > delete, 75% write); below is what we saw for a 2h run > Allocations > 30: 1.64TB > 40: 2.99TB > GC Events > 30: 7.39k events > 40: 13.93k events > When looking at the allocation output we saw the follow for memory allocations > !https://issues.apache.org/jira/secure/attachment/13021238/Screen%20Shot%202021-02-25%20at%203.34.28%20PM.png! > Here we see that org.apache.cassandra.io.util.DataOutputBuffer#expandToFit is > around 52% of the memory allocations. When looking at this logic I see that > allocations are on-heap and constantly throw away the buffer (as a means to > allow GC to clean up). > With the patch, allocations/gc are the following > Allocations > 30: 1.64TB > 40 w/ patch: 1.77TB > 40: 2.99TB > GC Events > 30: 7.39k events > 40 w/ patch: 8k events > 40: 13.93k events > With the patch only 0.8% allocations > !https://issues.apache.org/jira/secure/attachment/13021239/Screen%20Shot%202021-02-25%20at%204.14.19%20PM.png! -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r49817 - in /release/cassandra: 4.0.0/ debian/pool/main/c/cassandra/cassandra_4.0.0.dsc debian/pool/main/c/cassandra/cassandra_4.0.0.tar.gz debian/pool/main/c/cassandra/cassandra_4.0.0_all
Author: samt Date: Tue Sep 7 19:39:10 2021 New Revision: 49817 Log: Remove 4.0.0 Removed: release/cassandra/4.0.0/ release/cassandra/debian/pool/main/c/cassandra/cassandra_4.0.0.dsc release/cassandra/debian/pool/main/c/cassandra/cassandra_4.0.0.tar.gz release/cassandra/debian/pool/main/c/cassandra/cassandra_4.0.0_all.deb - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-12988) make the consistency level for user-level auth reads and writes configurable
[
https://issues.apache.org/jira/browse/CASSANDRA-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-12988:
--
Test and Documentation Plan: New unit testing for auth properties. Change
in config.yaml but no major documentation changes required.
Status: Patch Available (was: In Progress)
> make the consistency level for user-level auth reads and writes configurable
>
>
> Key: CASSANDRA-12988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12988
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Jason Brown
>Assignee: Josh McKenzie
>Priority: Low
> Fix For: 4.x
>
>
> Most reads for the auth-related tables execute at {{LOCAL_ONE}}. We'd like to
> make it configurable, with the default still being {{LOCAL_ONE}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12988) make the consistency level for user-level auth reads and writes configurable
[
https://issues.apache.org/jira/browse/CASSANDRA-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411436#comment-17411436
]
Josh McKenzie commented on CASSANDRA-12988:
---
Have rebased and re-architected implementation here, tests running. Behaves on
DatabaseDescriptorRefTest locally.
||Item|Link||
|JDK8
tests|[Link|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/75/workflows/73c71040-88d4-4165-b7c1-010cbecf845c]|
|JDK11
tests|[Link|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/75/workflows/b96bbb92-0eb2-4b10-ae08-7f3956442a13]|
|PR|[Link|https://github.com/apache/cassandra/compare/trunk...josh-mckenzie:cassandra-12988?expand=1]|
> make the consistency level for user-level auth reads and writes configurable
>
>
> Key: CASSANDRA-12988
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12988
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Core
>Reporter: Jason Brown
>Assignee: Josh McKenzie
>Priority: Low
> Fix For: 4.x
>
>
> Most reads for the auth-related tables execute at {{LOCAL_ONE}}. We'd like to
> make it configurable, with the default still being {{LOCAL_ONE}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16886) Reduce native_transport_max_frame_size_in_mb
[ https://issues.apache.org/jira/browse/CASSANDRA-16886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411429#comment-17411429 ] Brandon Williams commented on CASSANDRA-16886: -- [!https://ci-cassandra.apache.org/job/Cassandra-devbranch/1102/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1102/pipeline]. Other links are updated and the same. > Reduce native_transport_max_frame_size_in_mb > > > Key: CASSANDRA-16886 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16886 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Client >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > There is really no point in having this set to 256MB when the commitlog > segment size defaults to 32MB, effectively capping the largest insertable > mutation to 16MB. > The native transport can provide a good first line of defense against large > mutations that would otherwise hit the heap if left to be rejected by the > commitlog. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-site updated (5522933 -> d610564)
This is an automated email from the ASF dual-hosted git repository.
mck pushed a change to branch asf-site
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git.
from 5522933 remove old index.html
add d610564 generated off d59bbab0240852d0681c2bbfbdeeb0a43f6b43b4
No new revisions were added by this update.
Summary of changes:
.../Cassandra-on-Kubernetes-A-Beginners-Guide.html | 4 +-
content/_/download.html| 6 +-
.../4.0.1/cassandra}/_images/Figure_1_backups.jpg | Bin
.../cassandra}/_images/Figure_1_data_model.jpg | Bin
.../cassandra}/_images/Figure_1_guarantees.jpg | Bin
.../cassandra}/_images/Figure_1_read_repair.jpg| Bin
.../cassandra}/_images/Figure_2_data_model.jpg | Bin
.../cassandra}/_images/Figure_2_read_repair.jpg| Bin
.../cassandra}/_images/Figure_3_read_repair.jpg| Bin
.../cassandra}/_images/Figure_4_read_repair.jpg| Bin
.../cassandra}/_images/Figure_5_read_repair.jpg| Bin
.../cassandra}/_images/Figure_6_read_repair.jpg| Bin
.../_images/data_modeling_chebotko_logical.png | Bin
.../_images/data_modeling_chebotko_physical.png| Bin
.../_images/data_modeling_hotel_bucketing.png | Bin
.../cassandra}/_images/data_modeling_hotel_erd.png | Bin
.../_images/data_modeling_hotel_logical.png| Bin
.../_images/data_modeling_hotel_physical.png | Bin
.../_images/data_modeling_hotel_queries.png| Bin
.../_images/data_modeling_hotel_relational.png | Bin
.../_images/data_modeling_reservation_logical.png | Bin
.../_images/data_modeling_reservation_physical.png | Bin
.../doc/4.0.1/cassandra}/_images/docs_commit.png | Bin
.../cassandra}/_images/docs_create_branch.png | Bin
.../4.0.1/cassandra}/_images/docs_create_file.png | Bin
.../doc/4.0.1/cassandra}/_images/docs_editor.png | Bin
.../doc/4.0.1/cassandra}/_images/docs_fork.png | Bin
.../doc/4.0.1/cassandra}/_images/docs_pr.png | Bin
.../doc/4.0.1/cassandra}/_images/docs_preview.png | Bin
.../4.0.1/cassandra}/_images/eclipse_debug0.png| Bin
.../4.0.1/cassandra}/_images/eclipse_debug1.png| Bin
.../4.0.1/cassandra}/_images/eclipse_debug2.png| Bin
.../4.0.1/cassandra}/_images/eclipse_debug3.png| Bin
.../4.0.1/cassandra}/_images/eclipse_debug4.png| Bin
.../4.0.1/cassandra}/_images/eclipse_debug5.png| Bin
.../4.0.1/cassandra}/_images/eclipse_debug6.png| Bin
.../cassandra}/_images/example-stress-graph.png| Bin
.../doc/4.0.1/cassandra}/_images/hints.svg | 0
.../doc/4.0.1/cassandra}/_images/ring.svg | 0
.../doc/4.0.1/cassandra}/_images/vnodes.svg| 0
.../cassandra/architecture/dynamo.html | 0
.../cassandra/architecture/guarantees.html | 0
.../cassandra/architecture/index.html | 0
.../cassandra/architecture/overview.html | 0
.../cassandra/architecture/snitch.html | 0
.../cassandra/architecture/storage_engine.html | 0
.../configuration/cass_cl_archive_file.html| 0
.../cassandra/configuration/cass_env_sh_file.html | 0
.../configuration/cass_jvm_options_file.html | 0
.../configuration/cass_logback_xml_file.html | 0
.../cassandra/configuration/cass_rackdc_file.html | 0
.../cassandra/configuration/cass_topo_file.html| 0
.../cassandra/configuration/cass_yaml_file.html| 0
.../cassandra/configuration/index.html | 0
.../doc/{stable => 4.0.1}/cassandra/cql/SASI.html | 0
.../cassandra/cql/appendices.html | 0
.../{stable => 4.0.1}/cassandra/cql/changes.html | 0
.../cassandra/cql/cql_singlefile.html | 0
.../doc/{stable => 4.0.1}/cassandra/cql/ddl.html | 0
.../cassandra/cql/definitions.html | 0
.../doc/{stable => 4.0.1}/cassandra/cql/dml.html | 0
.../{stable => 4.0.1}/cassandra/cql/functions.html | 0
.../doc/{stable => 4.0.1}/cassandra/cql/index.html | 0
.../{stable => 4.0.1}/cassandra/cql/indexes.html | 0
.../doc/{stable => 4.0.1}/cassandra/cql/json.html | 0
.../doc/{stable => 4.0.1}/cassandra/cql/mvs.html | 0
.../{stable => 4.0.1}/cassandra/cql/operators.html | 0
.../{stable => 4.0.1}/cassandra/cql/security.html | 0
.../{stable => 4.0.1}/cassandra/cql/triggers.html | 0
.../doc/{stable => 4.0.1}/cassandra/cql/types.html | 0
.../data_modeling/data_modeling_conceptual.html| 0
.../data_modeling/data_modeling_logical.html | 0
.../data_modeling/data_modeling_physical.html | 0
.../data_modeling/data_modeling_queries.html | 0
.../data_modeling/data_modeling_rdbms.html | 0
.../data_modeling/data_modeling_refining.html | 0
.../data_modeling/data_modeling_schema.html| 0
.../data_modeling/data_modeling_tools.html | 0
.../cassandra/data_modeling/index.html | 0
.../cassandra/data_modeling/intro.html
[jira] [Commented] (CASSANDRA-16886) Reduce native_transport_max_frame_size_in_mb
[
https://issues.apache.org/jira/browse/CASSANDRA-16886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411413#comment-17411413
]
Benjamin Lerer commented on CASSANDRA-16886:
{quote}I can switch to ByteUnit here if you prefer{quote}
Yes, it would prefer. Thanks :-)
> Reduce native_transport_max_frame_size_in_mb
>
>
> Key: CASSANDRA-16886
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16886
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
>
> There is really no point in having this set to 256MB when the commitlog
> segment size defaults to 32MB, effectively capping the largest insertable
> mutation to 16MB.
> The native transport can provide a good first line of defense against large
> mutations that would otherwise hit the heap if left to be rejected by the
> commitlog.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16761) New Cassandra Website and Documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-16761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380763#comment-17380763
]
Michael Semb Wever edited comment on CASSANDRA-16761 at 9/7/21, 6:27 PM:
-
the antora built version of the new website design is on staging:
https://cassandra.staged.apache.org/
following manual steps were required, after the antora generation…
{code}
# push to staging, after having built with antora
git switch asf-staging
# copy everything to content/ directory
cp -r site-content/build/html/* content/
# move around the in-tree docs
rm -fR content/doc/4.0 content/doc/4.0.0 content/doc/3.11 content/doc/3.11.11
content/doc/stable content/doc/latest
cp -r content/Cassandra/3.11 content/doc/3.11.11
mv content/Cassandra/3.11 content/doc/
cp -r content/Cassandra/4.0 content/doc/4.0.0
cp -r content/Cassandra/4.0 content/doc/4.0.1
cp -r content/Cassandra/4.0 content/doc/stable
cp -r content/Cassandra/4.0 content/doc/latest
mv content/Cassandra/4.0 content/doc/
# update the .htaccess file
nano content/.htaccess
# remove hardcoded domain name
for f in $(rg -l "https://cassandra.apache.org/; content/_) ; do sed -i ''
's/https:\/\/cassandra.apache.org\//\//g' $f ; done
git add content
git commit content
git push origin asf-staging
{code}
The {{.htaccess}} addition is
{code}
RedirectMatch 301 "^/$" "/_/index.html"
RewriteCond %{REQUEST_URI} !^/doc/.*
RewriteCond %{REQUEST_URI} ^(.*)/$
RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
# temp – while in-tree antora are building to /Cassandra/
RewriteCond %{REQUEST_URI} !^/doc/.*
RewriteCond %{REQUEST_URI} ^/Cassandra/(.*)$
RewriteRule ^/?Cassandra/(.*)$ /doc/$1 [R=301,L]
# development in-tree docs have been moved to cassandra-website
RewriteCond %{REQUEST_URI} ^/doc/latest/development/(.+).html [NC]
RewriteRule ^/?doc/latest/development/(.+).html$ /_/development/$1.html
[R=301,L]
# redirects to new antora in-tree docs
RewriteCond %{REQUEST_URI} !^/doc/latest/index.html [NC]
RewriteCond %{REQUEST_URI} !^/doc/latest/cassandra [NC]
RewriteRule ^/?doc/latest/(.+)$ /doc/latest/cassandra/$1 [R=301,L]
RewriteCond %{REQUEST_URI} !^/doc/stable/index.html [NC]
RewriteCond %{REQUEST_URI} !^/doc/stable/cassandra [NC]
RewriteRule ^/?doc/stable/(.+)$ /doc/stable/cassandra/$1 [R=301,L]
RewriteCond %{REQUEST_URI} !^/doc/4.0/index.html [NC]
RewriteCond %{REQUEST_URI} !^/doc/4.0/cassandra [NC]
RewriteRule ^/?doc/4.0/(.+)$ /doc/4.0/cassandra/$1 [R=301,L]
RewriteCond %{REQUEST_URI} !^/doc/3.11/index.html [NC]
RewriteCond %{REQUEST_URI} !^/doc/3.11/cassandra [NC]
RewriteRule ^/?doc/3.11/(.+)$ /doc/3.11/cassandra/$1 [R=301,L]
{code}
was (Author: michaelsembwever):
the antora built version of the new website design is on staging:
https://cassandra.staged.apache.org/
following manual steps were required, after the antora generation…
{code}
# push to staging, after having built with antora
git switch asf-staging
# copy everything to content/ directory
cp -r site-content/build/html/* content/
# move around the in-tree docs
rm -fR content/doc/4.0 content/doc/4.0.0 content/doc/3.11 content/doc/3.11.11
content/doc/stable content/doc/latest
cp -r content/Cassandra/3.11 content/doc/3.11.11
mv content/Cassandra/3.11 content/doc/
cp -r content/Cassandra/4.0 content/doc/4.0.0
cp -r content/Cassandra/4.0 content/doc/stable
cp -r content/Cassandra/4.0 content/doc/latest
mv content/Cassandra/4.0 content/doc/
# update the .htaccess file
nano content/.htaccess
# remove hardcoded domain name
for f in $(rg -l "https://cassandra.apache.org/; content/_) ; do sed -i ''
's/https:\/\/cassandra.apache.org\//\//g' $f ; done
git add content
git commit content
git push origin asf-staging
{code}
The {{.htaccess}} addition is
{code}
RedirectMatch 301 "^/$" "/_/index.html"
RewriteCond %{REQUEST_URI} !^/doc/.*
RewriteCond %{REQUEST_URI} ^(.*)/$
RewriteRule ^(.*)/$ /_/$1.html [R=301,L]
# temp – while in-tree antora are building to /Cassandra/
RewriteCond %{REQUEST_URI} !^/doc/.*
RewriteCond %{REQUEST_URI} ^/Cassandra/(.*)$
RewriteRule ^/?Cassandra/(.*)$ /doc/$1 [R=301,L]
# development in-tree docs have been moved to cassandra-website
RewriteCond %{REQUEST_URI} ^/doc/latest/development/(.+).html [NC]
RewriteRule ^/?doc/latest/development/(.+).html$ /_/development/$1.html
[R=301,L]
# redirects to new antora in-tree docs
RewriteCond %{REQUEST_URI} !^/doc/latest/index.html [NC]
RewriteCond %{REQUEST_URI} !^/doc/latest/cassandra [NC]
RewriteRule ^/?doc/latest/(.+)$ /doc/latest/cassandra/$1 [R=301,L]
RewriteCond %{REQUEST_URI} !^/doc/stable/index.html [NC]
RewriteCond %{REQUEST_URI} !^/doc/stable/cassandra [NC]
RewriteRule ^/?doc/stable/(.+)$ /doc/stable/cassandra/$1 [R=301,L]
RewriteCond %{REQUEST_URI} !^/doc/4.0/index.html [NC]
RewriteCond %{REQUEST_URI} !^/doc/4.0/cassandra [NC]
RewriteRule ^/?doc/4.0/(.+)$ /doc/4.0/cassandra/$1 [R=301,L]
RewriteCond %{REQUEST_URI}
[jira] [Commented] (CASSANDRA-16841) Unexpectedly ignored dtests
[
https://issues.apache.org/jira/browse/CASSANDRA-16841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411384#comment-17411384
]
Andres de la Peña commented on CASSANDRA-16841:
---
We already have [a
warning|https://github.com/apache/cassandra-dtest/blob/trunk/conftest.py#L610-L611]
about the tests ignored due to the lack of resources, it's [slightly
modified|https://github.com/apache/cassandra-dtest/blob/ccc663461727a363121e8937efe44db1d34fb843/conftest.py#L611-L614]
in the PR. However the message is not printed on stdout with the default
config. Maybe we can make it visible for example emitting it with
{{logger.warning}} instead of {{logger.info}}.
> Unexpectedly ignored dtests
> ---
>
> Key: CASSANDRA-16841
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16841
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ruslan Fomkin
>Assignee: Ruslan Fomkin
>Priority: Normal
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> An issue, which I was hit:
> When one class in a dtest file is marked as resource intensive, then all
> tests in all classes are treated as resource intensive. For example,
> [repair_tests/repair_test.py|https://github.com/apache/cassandra-dtest/blob/trunk/repair_tests/repair_test.py]
> contains three classes and the last class is marked as resource intensive:
> {code:java}
> @pytest.mark.resource_intensive
> class TestRepairDataSystemTable(Tester):
> {code}
> So if I try to run an unmarked class:
> {code:java}
> pytest --cassandra-dir=../cassandra repair_tests/repair_test.py::TestRepair
> --collect-only --skip-resource-intensive-tests
> {code}
> then all tests are ignored
> {code:java}
> collected 36 items / 36 deselected
> {code}
> This is because a test is treated to be marked if any class in the same file
> has the mark. This bug was introduced in the fix of CASS-16399. Before only
> upgrade tests had such behaviour, i.e., if a class is marked as upgrade test,
> then all tests are upgrade test in the file.
>
> This bug, for example, means that if the same file contains one class marked
> with vnodes and another class with no_vnodes, then no tests will be executed
> in the file.
> I also noticed another issue that If a test run is executed with the argument
> {{-only-resource-intensive-tests}} and there is no sufficient resources for
> resource intensive tests, then no tests were executed. Thus it was necessary
> to provide {{-force-resource-intensive-tests}} in addition.
> Suggestions for the solutions:
> # Require to mark each class and remove the special case of upgrade tests.
> This will simplify the implementation and might be more obvious for new
> comers.
> # Treat {{-only-resource-intensive-tests}} in the same way as
> {{-force-resource-intensive-tests}}, so it will be enough to just specify it
> even with no sufficient resources.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16886) Reduce native_transport_max_frame_size_in_mb
[ https://issues.apache.org/jira/browse/CASSANDRA-16886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411377#comment-17411377 ] Brandon Williams commented on CASSANDRA-16886: -- bq. The only nit I have is regarding the use of numeric values This bothered me when writing it, but there are many other places in DD where 1048576 specifically is used for this purpose, so I decided to keep the same style and let CASSANDRA-15234 sort it out later. I'm not sure if doing it differently really furthers the goal of clealiness, and I didn't want to refactor all of the instances in this patch, but I can switch to ByteUnit here if you prefer. > Reduce native_transport_max_frame_size_in_mb > > > Key: CASSANDRA-16886 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16886 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Client >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > There is really no point in having this set to 256MB when the commitlog > segment size defaults to 32MB, effectively capping the largest insertable > mutation to 16MB. > The native transport can provide a good first line of defense against large > mutations that would otherwise hit the heap if left to be rejected by the > commitlog. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch trunk updated: ninja-fix: date and apostrophe on Cassandra-on-Kubernetes-A-Beginners-Guide blog
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/trunk by this push: new d59bbab ninja-fix: date and apostrophe on Cassandra-on-Kubernetes-A-Beginners-Guide blog d59bbab is described below commit d59bbab0240852d0681c2bbfbdeeb0a43f6b43b4 Author: mck AuthorDate: Tue Sep 7 18:10:35 2021 +0200 ninja-fix: date and apostrophe on Cassandra-on-Kubernetes-A-Beginners-Guide blog --- .../Cassandra-on-Kubernetes-A-Beginners-Guide.adoc | 108 ++--- 1 file changed, 54 insertions(+), 54 deletions(-) diff --git a/site-content/source/modules/ROOT/pages/blog/Cassandra-on-Kubernetes-A-Beginners-Guide.adoc b/site-content/source/modules/ROOT/pages/blog/Cassandra-on-Kubernetes-A-Beginners-Guide.adoc index 9f2d070..186c008 100644 --- a/site-content/source/modules/ROOT/pages/blog/Cassandra-on-Kubernetes-A-Beginners-Guide.adoc +++ b/site-content/source/modules/ROOT/pages/blog/Cassandra-on-Kubernetes-A-Beginners-Guide.adoc @@ -1,54 +1,54 @@ -= Cassandra on Kubernetes: A Beginner's Guide -:page-layout: single-post -:page-role: blog-post -:page-post-date: August 27, 2020 -:page-post-author: The Apache Cassandra Community -:description: The Apache Cassandra Community -:keywords: - -Kubernetes is a hot technology, and while it seems like everyone is using it for automating deployment, scaling, and management of containerized applications, you’ll still face fundamental issues as you try to grow from a beginner to an intermediate Kubernetes Operator. One of these hurdles is the storage and control of data. - -=== Where and how to store Kubernetes data -Kubernetes is an amazingly flexible and robust way to host stateless computation, but the data layer isn’t a straightforward solution. Traditionally computation would happen within a cluster, with every container in that cluster requesting and updating data from a traditionally stored database. - -Running applications in Kubernetes with databases external to Kubernetes creates a mismatched architecture. This situation has limited developer productivity, duplicative stacks for monitoring applications and database infrastructure, and increased cloud computing costs. - -=== What is Cassandra? -Apache Cassandra is an open source NoSQL distributed database trusted by thousands of companies for scalability and high availability without compromising performance. Linear scalability and proven fault tolerance on commodity hardware or cloud infrastructure make it the perfect platform for mission-critical data. The latest version of Apache Cassandra - -Cassandra merges the ease-of-use of NoSQL with the reliability of a mature open source project. Most importantly, for real-world applications, it’s designed with distributed architectures in mind. - -"Distributed" means Cassandra can run on multiple machines while appearing to users as a unified whole. There is little point in running Cassandra as a single node, although it is constructive to help you get up to speed on how it works. But to get the maximum benefit out of Cassandra, you would run it on multiple machines. - -=== Apache Cassandra and Kubernetes -Kubernetes has emerged as the leading orchestration platform for deploying and managing containerized systems in the cloud. Since managing infrastructure has been standardizing around Kubernetes, many organizations are looking at the data plane as something that should be managed under the same umbrella. - -Kubernetes simplifies distributed systems lifecycle management. It’s natural to use Kubernetes to build your flexible, distributed database with Cassandra. - -=== The Challenge of Kubernetes: Complexity -Kubernetes enables you to auto-scale whole containers: providing resources and spinning up new instances, along with load balancing, but without careful management: rather than removing the complexity of managing loads and containers, Kubernetes can increase the complexity of a system, making it even harder to manage. - -Running Cassandra on Kubernetes can be difficult. Kubernetes has only a limited understanding or insight into database functionality. It is blind to key operational requirements of the database that’s in use and it requires significant effort to script and leverage existing Kubernetes functionality to run a production-grade Cassandra deployment. - -To reduce those complexities, the Apache Cassandra community built https://github.com/datastax/cass-operator[Cass Operator,window=_blank], which is installed via Helm (see below). Operators take the process of describing many of the lower-level Kubernetes components and instead provide a more straightforward, logical interface for describing an application. They provide a translation layer between what Kubernetes needs to maintain services and the actual implementation by the
[jira] [Comment Edited] (CASSANDRA-16841) Unexpectedly ignored dtests
[
https://issues.apache.org/jira/browse/CASSANDRA-16841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411355#comment-17411355
]
Ekaterina Dimitrova edited comment on CASSANDRA-16841 at 9/7/21, 4:48 PM:
--
I am inclined to not change the behavior as this will lead to a lot of noise in
CI environments. I would say we need to have a warning why tests were skipped
but then I think there is already an option that can be run in order to get the
reason for skipping tests in pytest. Quick check showed me it is not used at
least in Circle CI environment.
I would suggest finding a way probably to add a warning why the tests didn't
work in a separate ticket. For the record, I just did a quick check whether the
pytest option _-rxXS_ will produce the warning but it didn't. It works nicely
with the mark for cassandra version. For example:
{code:java}
pytest --cassandra-dir=../cassandra
repair_tests/repair_test.py::TestRepair::test_parent_repair_session_cleanup
-rxXS
test session starts
=
platform darwin -- Python 3.8.10, pytest-3.6.4, py-1.10.0, pluggy-0.7.1
rootdir: ../cassandra-dtest-d, inifile: pytest.ini
plugins: timeout-1.4.2, repeat-0.9.1, flaky-3.7.0
timeout: 900.0s
timeout method: signal
timeout func_only: False
collected 1 item
repair_tests/repair_test.py s
[100%]
==
short test summary info
===
SKIP [1] ../cassandra-dtest-d/conftest.py:461: 3.11.12 < 4.0
{code}
*Note:* I had to remove the _--collect-only_ flag to see the skip reason.
was (Author: e.dimitrova):
I am inclined to not change the behavior as this will lead to a lot of noise in
CI environments. I would say we need to have a warning why tests were skipped
but then I think there is already an option that can be run in order to get the
reason for skipping tests in pytest. Quick check showed me it is not used at
least in Circle CI environment.
I would suggest finding a way probably to add a warning why the tests didn't
work in a separate ticket. For the record, I just did a quick check whether the
pytest option _-rxXS_ will produce the warning but it didn't. It works nicely
with the mark for cassandra version. For example:
{code:java}
pytest --cassandra-dir=../cassandra
repair_tests/repair_test.py::TestRepair::test_parent_repair_session_cleanup
-rxXS
test session starts
=
platform darwin -- Python 3.8.10, pytest-3.6.4, py-1.10.0, pluggy-0.7.1
rootdir: ../cassandra-dtest-d, inifile: pytest.ini
plugins: timeout-1.4.2, repeat-0.9.1, flaky-3.7.0
timeout: 900.0s
timeout method: signal
timeout func_only: False
collected 1 item
repair_tests/repair_test.py s
[100%]
==
short test summary info
===
SKIP [1] ../cassandra-dtest-d/conftest.py:461: 3.11.12 < 4.0
{code}
Note: I had to remove the --collect-only flag to see the skip reason.
> Unexpectedly ignored dtests
> ---
>
> Key: CASSANDRA-16841
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16841
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ruslan Fomkin
>Assignee: Ruslan Fomkin
>Priority: Normal
> Time Spent: 1h 50m
>
[jira] [Comment Edited] (CASSANDRA-16841) Unexpectedly ignored dtests
[
https://issues.apache.org/jira/browse/CASSANDRA-16841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411355#comment-17411355
]
Ekaterina Dimitrova edited comment on CASSANDRA-16841 at 9/7/21, 4:48 PM:
--
I am inclined to not change the behavior as this will lead to a lot of noise in
CI environments. I would say we need to have a warning why tests were skipped
but then I think there is already an option that can be run in order to get the
reason for skipping tests in pytest. Quick check showed me it is not used at
least in Circle CI environment.
I would suggest finding a way probably to add a warning why the tests didn't
work in a separate ticket. For the record, I just did a quick check whether the
pytest option _-rxXS_ will produce the warning but it didn't. It works nicely
with the mark for cassandra version. For example:
{code:java}
pytest --cassandra-dir=../cassandra
repair_tests/repair_test.py::TestRepair::test_parent_repair_session_cleanup
-rxXS
test session starts
=
platform darwin -- Python 3.8.10, pytest-3.6.4, py-1.10.0, pluggy-0.7.1
rootdir: ../cassandra-dtest-d, inifile: pytest.ini
plugins: timeout-1.4.2, repeat-0.9.1, flaky-3.7.0
timeout: 900.0s
timeout method: signal
timeout func_only: False
collected 1 item
repair_tests/repair_test.py s
[100%]
==
short test summary info
===
SKIP [1] ../cassandra-dtest-d/conftest.py:461: 3.11.12 < 4.0
{code}
Note: I had to remove the --collect-only flag to see the skip reason.
was (Author: e.dimitrova):
I am inclined to not change the behavior as this will lead to a lot of noise in
CI environments. I would say we need to have a warning why tests were skipped
but then I think there is already an option that can be run in order to get the
reason for skipping tests in pytest. Quick check showed me it is not used at
least in Circle CI environment.
I would suggest finding a way probably to add a warning why the tests didn't
work in a separate ticket. For the record, I just did a quick check whether the
pytest option _-rxXS_ will produce the warning but it didn't. It works nicely
with the mark for cassandra version. For example:
{code:java}
pytest --cassandra-dir=../cassandra
repair_tests/repair_test.py::TestRepair::test_parent_repair_session_cleanup
-rxXS
test session starts
=
platform darwin -- Python 3.8.10, pytest-3.6.4, py-1.10.0, pluggy-0.7.1
rootdir: ../cassandra-dtest-d, inifile: pytest.ini
plugins: timeout-1.4.2, repeat-0.9.1, flaky-3.7.0
timeout: 900.0s
timeout method: signal
timeout func_only: False
collected 1 item
repair_tests/repair_test.py s
[100%]
==
short test summary info
===
SKIP [1] ../cassandra-dtest-d/conftest.py:461: 3.11.12 < 4.0
{code}
Note: I had to remove the --collect-only flag to see the skip reason.
> Unexpectedly ignored dtests
> ---
>
> Key: CASSANDRA-16841
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16841
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ruslan Fomkin
>Assignee: Ruslan Fomkin
>Priority: Normal
> Time Spent: 1h 50m
>
[jira] [Commented] (CASSANDRA-16841) Unexpectedly ignored dtests
[
https://issues.apache.org/jira/browse/CASSANDRA-16841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411355#comment-17411355
]
Ekaterina Dimitrova commented on CASSANDRA-16841:
-
I am inclined to not change the behavior as this will lead to a lot of noise in
CI environments. I would say we need to have a warning why tests were skipped
but then I think there is already an option that can be run in order to get the
reason for skipping tests in pytest. Quick check showed me it is not used at
least in Circle CI environment.
I would suggest finding a way probably to add a warning why the tests didn't
work in a separate ticket. For the record, I just did a quick check whether the
pytest option _-rxXS_ will produce the warning but it didn't. It works nicely
with the mark for cassandra version. For example:
{code:java}
pytest --cassandra-dir=../cassandra
repair_tests/repair_test.py::TestRepair::test_parent_repair_session_cleanup
-rxXS
test session starts
=
platform darwin -- Python 3.8.10, pytest-3.6.4, py-1.10.0, pluggy-0.7.1
rootdir: ../cassandra-dtest-d, inifile: pytest.ini
plugins: timeout-1.4.2, repeat-0.9.1, flaky-3.7.0
timeout: 900.0s
timeout method: signal
timeout func_only: False
collected 1 item
repair_tests/repair_test.py s
[100%]
==
short test summary info
===
SKIP [1] ../cassandra-dtest-d/conftest.py:461: 3.11.12 < 4.0
{code}
Note: I had to remove the --collect-only flag to see the skip reason.
> Unexpectedly ignored dtests
> ---
>
> Key: CASSANDRA-16841
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16841
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ruslan Fomkin
>Assignee: Ruslan Fomkin
>Priority: Normal
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> An issue, which I was hit:
> When one class in a dtest file is marked as resource intensive, then all
> tests in all classes are treated as resource intensive. For example,
> [repair_tests/repair_test.py|https://github.com/apache/cassandra-dtest/blob/trunk/repair_tests/repair_test.py]
> contains three classes and the last class is marked as resource intensive:
> {code:java}
> @pytest.mark.resource_intensive
> class TestRepairDataSystemTable(Tester):
> {code}
> So if I try to run an unmarked class:
> {code:java}
> pytest --cassandra-dir=../cassandra repair_tests/repair_test.py::TestRepair
> --collect-only --skip-resource-intensive-tests
> {code}
> then all tests are ignored
> {code:java}
> collected 36 items / 36 deselected
> {code}
> This is because a test is treated to be marked if any class in the same file
> has the mark. This bug was introduced in the fix of CASS-16399. Before only
> upgrade tests had such behaviour, i.e., if a class is marked as upgrade test,
> then all tests are upgrade test in the file.
>
> This bug, for example, means that if the same file contains one class marked
> with vnodes and another class with no_vnodes, then no tests will be executed
> in the file.
> I also noticed another issue that If a test run is executed with the argument
> {{-only-resource-intensive-tests}} and there is no sufficient resources for
> resource intensive tests, then no tests were executed. Thus it was necessary
> to provide {{-force-resource-intensive-tests}} in addition.
> Suggestions for the solutions:
> # Require to mark each class and remove the special case of upgrade tests.
> This will simplify the implementation and might be more obvious for new
> comers.
> # Treat {{-only-resource-intensive-tests}} in the same way as
> {{-force-resource-intensive-tests}}, so it will be enough to just specify it
> even with no sufficient resources.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail:
[jira] [Comment Edited] (CASSANDRA-16841) Unexpectedly ignored dtests
[
https://issues.apache.org/jira/browse/CASSANDRA-16841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411355#comment-17411355
]
Ekaterina Dimitrova edited comment on CASSANDRA-16841 at 9/7/21, 4:47 PM:
--
I am inclined to not change the behavior as this will lead to a lot of noise in
CI environments. I would say we need to have a warning why tests were skipped
but then I think there is already an option that can be run in order to get the
reason for skipping tests in pytest. Quick check showed me it is not used at
least in Circle CI environment.
I would suggest finding a way probably to add a warning why the tests didn't
work in a separate ticket. For the record, I just did a quick check whether the
pytest option _-rxXS_ will produce the warning but it didn't. It works nicely
with the mark for cassandra version. For example:
{code:java}
pytest --cassandra-dir=../cassandra
repair_tests/repair_test.py::TestRepair::test_parent_repair_session_cleanup
-rxXS
test session starts
=
platform darwin -- Python 3.8.10, pytest-3.6.4, py-1.10.0, pluggy-0.7.1
rootdir: ../cassandra-dtest-d, inifile: pytest.ini
plugins: timeout-1.4.2, repeat-0.9.1, flaky-3.7.0
timeout: 900.0s
timeout method: signal
timeout func_only: False
collected 1 item
repair_tests/repair_test.py s
[100%]
==
short test summary info
===
SKIP [1] ../cassandra-dtest-d/conftest.py:461: 3.11.12 < 4.0
{code}
Note: I had to remove the --collect-only flag to see the skip reason.
was (Author: e.dimitrova):
I am inclined to not change the behavior as this will lead to a lot of noise in
CI environments. I would say we need to have a warning why tests were skipped
but then I think there is already an option that can be run in order to get the
reason for skipping tests in pytest. Quick check showed me it is not used at
least in Circle CI environment.
I would suggest finding a way probably to add a warning why the tests didn't
work in a separate ticket. For the record, I just did a quick check whether the
pytest option _-rxXS_ will produce the warning but it didn't. It works nicely
with the mark for cassandra version. For example:
{code:java}
pytest --cassandra-dir=../cassandra
repair_tests/repair_test.py::TestRepair::test_parent_repair_session_cleanup
-rxXS
test session starts
=
platform darwin -- Python 3.8.10, pytest-3.6.4, py-1.10.0, pluggy-0.7.1
rootdir: ../cassandra-dtest-d, inifile: pytest.ini
plugins: timeout-1.4.2, repeat-0.9.1, flaky-3.7.0
timeout: 900.0s
timeout method: signal
timeout func_only: False
collected 1 item
repair_tests/repair_test.py s
[100%]
==
short test summary info
===
SKIP [1] ../cassandra-dtest-d/conftest.py:461: 3.11.12 < 4.0
{code}
Note: I had to remove the --collect-only flag to see the skip reason.
> Unexpectedly ignored dtests
> ---
>
> Key: CASSANDRA-16841
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16841
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ruslan Fomkin
>Assignee: Ruslan Fomkin
>Priority: Normal
> Time
[jira] [Updated] (CASSANDRA-16841) Unexpectedly ignored dtests
[
https://issues.apache.org/jira/browse/CASSANDRA-16841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16841:
Reviewers: Andres de la Peña, Ekaterina Dimitrova (was: Andres de la Peña)
Status: Review In Progress (was: Needs Committer)
> Unexpectedly ignored dtests
> ---
>
> Key: CASSANDRA-16841
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16841
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Ruslan Fomkin
>Assignee: Ruslan Fomkin
>Priority: Normal
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> An issue, which I was hit:
> When one class in a dtest file is marked as resource intensive, then all
> tests in all classes are treated as resource intensive. For example,
> [repair_tests/repair_test.py|https://github.com/apache/cassandra-dtest/blob/trunk/repair_tests/repair_test.py]
> contains three classes and the last class is marked as resource intensive:
> {code:java}
> @pytest.mark.resource_intensive
> class TestRepairDataSystemTable(Tester):
> {code}
> So if I try to run an unmarked class:
> {code:java}
> pytest --cassandra-dir=../cassandra repair_tests/repair_test.py::TestRepair
> --collect-only --skip-resource-intensive-tests
> {code}
> then all tests are ignored
> {code:java}
> collected 36 items / 36 deselected
> {code}
> This is because a test is treated to be marked if any class in the same file
> has the mark. This bug was introduced in the fix of CASS-16399. Before only
> upgrade tests had such behaviour, i.e., if a class is marked as upgrade test,
> then all tests are upgrade test in the file.
>
> This bug, for example, means that if the same file contains one class marked
> with vnodes and another class with no_vnodes, then no tests will be executed
> in the file.
> I also noticed another issue that If a test run is executed with the argument
> {{-only-resource-intensive-tests}} and there is no sufficient resources for
> resource intensive tests, then no tests were executed. Thus it was necessary
> to provide {{-force-resource-intensive-tests}} in addition.
> Suggestions for the solutions:
> # Require to mark each class and remove the special case of upgrade tests.
> This will simplify the implementation and might be more obvious for new
> comers.
> # Treat {{-only-resource-intensive-tests}} in the same way as
> {{-force-resource-intensive-tests}}, so it will be enough to just specify it
> even with no sufficient resources.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (e04a3a9 -> 4a8c5cc)
This is an automated email from the ASF dual-hosted git repository. samt pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from e04a3a9 Merge branch 'cassandra-4.0' into trunk new d90cd51 Fix CHANGES.txt entries after bumping version to 4.0.2 new 4a8c5cc Merge branch 'cassandra-4.0' into trunk The 2 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: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated: Fix CHANGES.txt entries after bumping version to 4.0.2
This is an automated email from the ASF dual-hosted git repository. samt pushed a commit to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-4.0 by this push: new d90cd51 Fix CHANGES.txt entries after bumping version to 4.0.2 d90cd51 is described below commit d90cd518ae08520bdecd15edbfaabc4d9d0e531b Author: Sam Tunnicliffe AuthorDate: Tue Sep 7 17:04:40 2021 +0100 Fix CHANGES.txt entries after bumping version to 4.0.2 --- CHANGES.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index 75873fd..9ed275e 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,12 +1,12 @@ 4.0.2 * Delay auth setup until after gossip has settled to avoid unavailables on startup (CASSANDRA-16783) * Fix clustering order logic in CREATE MATERIALIZED VIEW (CASSANDRA-16898) + * org.apache.cassandra.db.rows.ArrayCell#unsharedHeapSizeExcludingData includes data twice (CASSANDRA-16900) + * Exclude Jackson 1.x transitive dependency of hadoop* provided dependencies (CASSANDRA-16854) Merged from 3.0: * Make the addition of regular column to COMPACT tables throw an InvalidRequestException (CASSANDRA-14564) 4.0.1 - * org.apache.cassandra.db.rows.ArrayCell#unsharedHeapSizeExcludingData includes data twice (CASSANDRA-16900) - * Exclude Jackson 1.x transitive dependency of hadoop* provided dependencies (CASSANDRA-16854) * Tolerate missing DNS entry when completing a host replacement (CASSANDRA-16873) * Harden PrunableArrayQueue against Pruner implementations that might throw exceptions (CASSANDRA-16866) * Move RepairedDataInfo to the execution controller rather than the ReadCommand to avoid unintended sharing (CASSANDRA-16721) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. samt pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 4a8c5cc1e06f02f19400c5609ba4b5cbfc02f061 Merge: e04a3a9 d90cd51 Author: Sam Tunnicliffe AuthorDate: Tue Sep 7 17:08:12 2021 +0100 Merge branch 'cassandra-4.0' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated (4ed28cb -> 9a34ecd)
This is an automated email from the ASF dual-hosted git repository. samt pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 4ed28cb Merge branch 'cassandra-3.11' into cassandra-4.0 add 9a34ecd Increment version to 4.0.2 No new revisions were added by this update. Summary of changes: build.xml| 2 +- debian/changelog | 6 ++ 2 files changed, 7 insertions(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. samt pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit e04a3a94b973969921d720669ac8671ad286e25c Merge: ce2d756 9a34ecd Author: Sam Tunnicliffe AuthorDate: Tue Sep 7 16:51:55 2021 +0100 Merge branch 'cassandra-4.0' into trunk - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (ce2d756 -> e04a3a9)
This is an automated email from the ASF dual-hosted git repository. samt pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from ce2d756 Merge branch 'cassandra-4.0' into trunk add 9a34ecd Increment version to 4.0.2 new e04a3a9 Merge branch 'cassandra-4.0' into trunk 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: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch trunk updated: Update download.adoc with 4.0.1 release
This is an automated email from the ASF dual-hosted git repository. samt pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/trunk by this push: new a719cd4 Update download.adoc with 4.0.1 release a719cd4 is described below commit a719cd4e37cba7e9c6c51da9072227480b4d38fe Author: Sam Tunnicliffe AuthorDate: Tue Sep 7 15:32:22 2021 +0100 Update download.adoc with 4.0.1 release --- site-content/source/modules/ROOT/pages/download.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/site-content/source/modules/ROOT/pages/download.adoc b/site-content/source/modules/ROOT/pages/download.adoc index b478abd..6896cf0 100644 --- a/site-content/source/modules/ROOT/pages/download.adoc +++ b/site-content/source/modules/ROOT/pages/download.adoc @@ -18,12 +18,12 @@ [discrete] Download the latest Apache Cassandra 4.0 GA release: [discrete] -== Released on 2021-07-26 +== Released on 2021-09-07 [.btn.btn--alt] -https://www.apache.org/dyn/closer.lua/cassandra/4.0.0/apache-cassandra-4.0.0-bin.tar.gz[4.0.0,window=blank] +https://www.apache.org/dyn/closer.lua/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz[4.0.1,window=blank] -(https://downloads.apache.org/cassandra/4.0.0/apache-cassandra-4.0.0-bin.tar.gz.asc[pgp,window=blank], https://downloads.apache.org/cassandra/4.0.0/apache-cassandra-4.0.0-bin.tar.gz.sha256[sha256,window=blank] and https://downloads.apache.org/cassandra/4.0.0/apache-cassandra-4.0.0-bin.tar.gz.sha512[sha512,window=blank]) +(https://downloads.apache.org/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz.asc[pgp,window=blank], https://downloads.apache.org/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz.sha256[sha256,window=blank] and https://downloads.apache.org/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz.sha512[sha512,window=blank]) -- [openblock, inline50 inline-top] - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16175) Avoid removing batch when it's not created during view replication
[ https://issues.apache.org/jira/browse/CASSANDRA-16175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16175: Fix Version/s: (was: 4.x) 4.0.2 4.1 3.11.12 3.0.26 > Avoid removing batch when it's not created during view replication > -- > > Key: CASSANDRA-16175 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16175 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views >Reporter: Zhao Yang >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.0.26, 3.11.12, 4.1, 4.0.2 > > > When the base replica is also a view replica we don't write a local batchlog, > but they are unnecessarily removed when the view write is successful, what > creates (and persists) a tombstone into the system.batches table. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16175) Avoid removing batch when it's not created during view replication
[ https://issues.apache.org/jira/browse/CASSANDRA-16175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16175: Since Version: (was: 3.0.0) > Avoid removing batch when it's not created during view replication > -- > > Key: CASSANDRA-16175 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16175 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views >Reporter: Zhao Yang >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > When the base replica is also a view replica we don't write a local batchlog, > but they are unnecessarily removed when the view write is successful, what > creates (and persists) a tombstone into the system.batches table. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16175) Avoid removing batch when it's not created during view replication
[ https://issues.apache.org/jira/browse/CASSANDRA-16175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16175: Since Version: 3.0.0 Source Control Link: https://github.com/apache/cassandra/commit/57f53f53ae811f00cf9c1f84bd0414d99391f1ce Resolution: Fixed Status: Resolved (was: Ready to Commit) > Avoid removing batch when it's not created during view replication > -- > > Key: CASSANDRA-16175 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16175 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views >Reporter: Zhao Yang >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > When the base replica is also a view replica we don't write a local batchlog, > but they are unnecessarily removed when the view write is successful, what > creates (and persists) a tombstone into the system.batches table. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16175) Avoid removing batch when it's not created during view replication
[ https://issues.apache.org/jira/browse/CASSANDRA-16175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411290#comment-17411290 ] Ekaterina Dimitrova commented on CASSANDRA-16175: - Thank you [~jasonstack] and [~brandon.williams] This was committed here: To https://github.com/apache/cassandra.git 267d3ce04e..57f53f53ae cassandra-3.0 -> cassandra-3.0 29d78af616..e644a9954a cassandra-3.11 -> cassandra-3.11 9c90cf7da0..4ed28cbf9c cassandra-4.0 -> cassandra-4.0 138569b079..ce2d756c41 trunk -> trunk > Avoid removing batch when it's not created during view replication > -- > > Key: CASSANDRA-16175 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16175 > Project: Cassandra > Issue Type: Bug > Components: Feature/Materialized Views >Reporter: Zhao Yang >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > When the base replica is also a view replica we don't write a local batchlog, > but they are unnecessarily removed when the view write is successful, what > creates (and persists) a tombstone into the system.batches table. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated (9c90cf7 -> 4ed28cb)
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 9c90cf7 Merge branch 'cassandra-3.11' into cassandra-4.0 add 57f53f5 Avoid removing batch when it's not created during view replication patch by Zhao Yang, Ekaterina Dimitrova; reviewed by Zhao Yang, Ekaterina Dimitrova, Brandon Williams for CASSANDRA-16175 add e644a99 Merge branch 'cassandra-3.0' into cassandra-3.11 add 4ed28cb Merge branch 'cassandra-3.11' into cassandra-4.0 No new revisions were added by this update. Summary of changes: .../cassandra/service/BatchlogResponseHandler.java | 7 +- .../org/apache/cassandra/service/StorageProxy.java | 3 ++- .../cassandra/cql3/ViewComplexDeletionsTest.java | 25 ++ 3 files changed, 33 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated (267d3ce -> 57f53f5)
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 267d3ce make the addition of regular column to COMPACT tables throw an InvalidRequestException add 57f53f5 Avoid removing batch when it's not created during view replication patch by Zhao Yang, Ekaterina Dimitrova; reviewed by Zhao Yang, Ekaterina Dimitrova, Brandon Williams for CASSANDRA-16175 No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + .../cassandra/service/BatchlogResponseHandler.java| 7 ++- .../org/apache/cassandra/service/StorageProxy.java| 3 ++- test/unit/org/apache/cassandra/cql3/ViewTest.java | 19 +++ 4 files changed, 28 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit ce2d756c41afdfa74c44db1490f01e7d3ce9730d Merge: 138569b 4ed28cb Author: Ekaterina Dimitrova AuthorDate: Tue Sep 7 10:46:46 2021 -0400 Merge branch 'cassandra-4.0' into trunk .../cassandra/service/BatchlogResponseHandler.java | 7 +- .../org/apache/cassandra/service/StorageProxy.java | 3 ++- .../cassandra/cql3/ViewComplexDeletionsTest.java | 25 ++ 3 files changed, 33 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (138569b -> ce2d756)
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 138569b Open java driver connections in CQLTester in a lazy way add 57f53f5 Avoid removing batch when it's not created during view replication patch by Zhao Yang, Ekaterina Dimitrova; reviewed by Zhao Yang, Ekaterina Dimitrova, Brandon Williams for CASSANDRA-16175 add e644a99 Merge branch 'cassandra-3.0' into cassandra-3.11 add 4ed28cb Merge branch 'cassandra-3.11' into cassandra-4.0 new ce2d756 Merge branch 'cassandra-4.0' into trunk 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: .../cassandra/service/BatchlogResponseHandler.java | 7 +- .../org/apache/cassandra/service/StorageProxy.java | 3 ++- .../cassandra/cql3/ViewComplexDeletionsTest.java | 25 ++ 3 files changed, 33 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (29d78af -> e644a99)
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 29d78af Merge branch 'cassandra-3.0' into cassandra-3.11 add 57f53f5 Avoid removing batch when it's not created during view replication patch by Zhao Yang, Ekaterina Dimitrova; reviewed by Zhao Yang, Ekaterina Dimitrova, Brandon Williams for CASSANDRA-16175 add e644a99 Merge branch 'cassandra-3.0' into cassandra-3.11 No new revisions were added by this update. Summary of changes: .../cassandra/service/BatchlogResponseHandler.java| 7 ++- .../org/apache/cassandra/service/StorageProxy.java| 3 ++- test/unit/org/apache/cassandra/cql3/ViewTest.java | 19 +++ 3 files changed, 27 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] 01/01: Update download.adoc with 4.0.1 release
This is an automated email from the ASF dual-hosted git repository. samt pushed a commit to branch release-4.0.1 in repository https://gitbox.apache.org/repos/asf/cassandra-website.git commit 48de083d84b094176dca44edde564bc37d9b9f95 Author: Sam Tunnicliffe AuthorDate: Tue Sep 7 15:32:22 2021 +0100 Update download.adoc with 4.0.1 release --- site-content/source/modules/ROOT/pages/download.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/site-content/source/modules/ROOT/pages/download.adoc b/site-content/source/modules/ROOT/pages/download.adoc index b478abd..6896cf0 100644 --- a/site-content/source/modules/ROOT/pages/download.adoc +++ b/site-content/source/modules/ROOT/pages/download.adoc @@ -18,12 +18,12 @@ [discrete] Download the latest Apache Cassandra 4.0 GA release: [discrete] -== Released on 2021-07-26 +== Released on 2021-09-07 [.btn.btn--alt] -https://www.apache.org/dyn/closer.lua/cassandra/4.0.0/apache-cassandra-4.0.0-bin.tar.gz[4.0.0,window=blank] +https://www.apache.org/dyn/closer.lua/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz[4.0.1,window=blank] -(https://downloads.apache.org/cassandra/4.0.0/apache-cassandra-4.0.0-bin.tar.gz.asc[pgp,window=blank], https://downloads.apache.org/cassandra/4.0.0/apache-cassandra-4.0.0-bin.tar.gz.sha256[sha256,window=blank] and https://downloads.apache.org/cassandra/4.0.0/apache-cassandra-4.0.0-bin.tar.gz.sha512[sha512,window=blank]) +(https://downloads.apache.org/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz.asc[pgp,window=blank], https://downloads.apache.org/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz.sha256[sha256,window=blank] and https://downloads.apache.org/cassandra/4.0.1/apache-cassandra-4.0.1-bin.tar.gz.sha512[sha512,window=blank]) -- [openblock, inline50 inline-top] - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch release-4.0.1 created (now 48de083)
This is an automated email from the ASF dual-hosted git repository. samt pushed a change to branch release-4.0.1 in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. at 48de083 Update download.adoc with 4.0.1 release This branch includes the following new commits: new 48de083 Update download.adoc with 4.0.1 release 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. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16895) Support Java 17
[ https://issues.apache.org/jira/browse/CASSANDRA-16895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16895: - Description: This ticket is intended to group all issues found to support Java 17 in the future. (was: This ticket is intended to group all issues found to support Java 11 in the future.) > Support Java 17 > --- > > Key: CASSANDRA-16895 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16895 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > > This ticket is intended to group all issues found to support Java 17 in the > future. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15975) SEP.shutdownAndWait does not wait for termination and SEPExecutor.awaitTermination may hang
[ https://issues.apache.org/jira/browse/CASSANDRA-15975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411272#comment-17411272 ] Benjamin Lerer commented on CASSANDRA-15975: [~jmeredithco] This ticket look ready to commit. Anything blocking you ? > SEP.shutdownAndWait does not wait for termination and > SEPExecutor.awaitTermination may hang > --- > > Key: CASSANDRA-15975 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15975 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > > SharedExecutorPool.shutdownAndWait calls shutdownNow on the executors it > owns, which has the side effect of removing the executor from the list, then > uses the same emptied list to try and wait for them to complete shutting > down, which completes immediately. > > Once fixed by copying the list in SEP.shutdownAndWait, the SEPExecutorTest > suite fails with a timeout due to a startup race in SEPWorker. > > If a SEPExecutor is shutdown immediately after maybeSchedule creates a new > SEPWorker, > but before it is able to execute the first task then it exits immediately on > entering the work loop with a work and task permit reserved for it, which > invalidates the work/task permit accounting and prevents calling the shutdown > SimpleCondition.signalAll when the last SEPWorker exits. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14344) Support filtering using IN restrictions
[
https://issues.apache.org/jira/browse/CASSANDRA-14344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14344:
---
Status: Review In Progress (was: Needs Committer)
> Support filtering using IN restrictions
> ---
>
> Key: CASSANDRA-14344
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14344
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/CQL
>Reporter: Dikang Gu
>Assignee: Venkata Harikrishna Nukala
>Priority: Normal
> Fix For: 4.x
>
> Attachments: 14344-trunk-2.txt, 14344-trunk-3.patch,
> 14344-trunk-inexpression-approach-2.txt,
> 14344-trunk-inexpression-approach.txt, 14344-trunk.txt
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Support IN filter query like this:
>
> CREATE TABLE ks1.t1 (
> key int,
> col1 int,
> col2 int,
> value int,
> PRIMARY KEY (key, col1, col2)
> ) WITH CLUSTERING ORDER BY (col1 ASC, col2 ASC)
>
> cqlsh:ks1> select * from t1 where key = 1 and col2 in (1) allow filtering;
>
> key | col1 | col2 | value
> -+++---
> 1 | 1 | 1 | 1
> 1 | 2 | 1 | 3
>
> (2 rows)
> cqlsh:ks1> select * from t1 where key = 1 and col2 in (1, 2) allow filtering;
> *{color:#ff}InvalidRequest: Error from server: code=2200 [Invalid query]
> message="IN restrictions are not supported on indexed columns"{color}*
> cqlsh:ks1>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16349) SSTableLoader reports error when SSTable(s) do not have data for some nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411254#comment-17411254
]
Aleksandr Sorokoumov commented on CASSANDRA-16349:
--
Hey [~ascott],
Can you please try to reproduce the error with the *Streaming fix* patch I
linked above? If you still can reproduce it, it'd help if you can attach
relevant stack traces from the failing nodes.
> SSTableLoader reports error when SSTable(s) do not have data for some nodes
> ---
>
> Key: CASSANDRA-16349
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16349
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: Serban Teodorescu
>Assignee: Serban Teodorescu
>Priority: Normal
> Fix For: 4.0.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Running SSTableLoader in verbose mode will show error(s) if there are node(s)
> that do not own any data from the SSTable(s). This can happen in at least 2
> cases:
> # SSTableLoader is used to stream backups while keeping the same token ranges
> # SSTable(s) are created with CQLSSTableWriter to match token ranges (this
> can bring better performance by using ZeroCopy streaming)
> Partial output of the SSTableLoader:
> {quote}ERROR 02:47:47,842 [Stream #fa8e73b0-3da5-11eb-9c47-c5d27ae8fe47]
> Remote peer /127.0.0.4:7000 failed stream session.
> ERROR 02:47:47,842 [Stream #fa8e73b0-3da5-11eb-9c47-c5d27ae8fe47] Remote peer
> /127.0.0.3:7000 failed stream session.
> progress: [/127.0.0.4:7000]0:0/1 100% [/127.0.0.3:7000]0:0/1 100%
> [/127.0.0.2:7000]0:7/7 100% [/127.0.0.1:7000]0:7/7 100% total: 100%
> 0.000KiB/s (avg: 1.611KiB/s)
> progress: [/127.0.0.4:7000]0:0/1 100% [/127.0.0.3:7000]0:0/1 100%
> [/127.0.0.2:7000]0:7/7 100% [/127.0.0.1:7000]0:7/7 100% total: 100%
> 0.000KiB/s (avg: 1.611KiB/s)
> progress: [/127.0.0.4:7000]0:0/1 100% [/127.0.0.3:7000]0:0/1 100%
> [/127.0.0.2:7000]0:7/7 100% [/127.0.0.1:7000]0:7/7 100% total: 100%
> 0.000KiB/s (avg: 1.515KiB/s)
> progress: [/127.0.0.4:7000]0:0/1 100% [/127.0.0.3:7000]0:0/1 100%
> [/127.0.0.2:7000]0:7/7 100% [/127.0.0.1:7000]0:7/7 100% total: 100%
> 0.000KiB/s (avg: 1.427KiB/s)
> {quote}
>
> Stack trace:
> {quote}java.util.concurrent.ExecutionException:
> org.apache.cassandra.streaming.StreamException: Stream failed
> at
> com.google.common.util.concurrent.AbstractFuture.getDoneValue(AbstractFuture.java:552)
> at
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:533)
> at org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:99)
> at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:49)
> Caused by: org.apache.cassandra.streaming.StreamException: Stream failed
> at
> org.apache.cassandra.streaming.management.StreamEventJMXNotifier.onFailure(StreamEventJMXNotifier.java:88)
> at
> com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1056)
> at
> com.google.common.util.concurrent.DirectExecutor.execute(DirectExecutor.java:30)
> at
> com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:1138)
> at
> com.google.common.util.concurrent.AbstractFuture.complete(AbstractFuture.java:958)
> at
> com.google.common.util.concurrent.AbstractFuture.setException(AbstractFuture.java:748)
> at
> org.apache.cassandra.streaming.StreamResultFuture.maybeComplete(StreamResultFuture.java:220)
> at
> org.apache.cassandra.streaming.StreamResultFuture.handleSessionComplete(StreamResultFuture.java:196)
> at
> org.apache.cassandra.streaming.StreamSession.closeSession(StreamSession.java:505)
> at
> org.apache.cassandra.streaming.StreamSession.complete(StreamSession.java:819)
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:595)
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:189)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:844)
> {quote}
> To reproduce create a cluster with ccm with more nodes than the RF, put some
> data into it copy a SSTable and stream it.
>
> The error originates on the nodes, the following stack trace is shown in the
> logs:
> {quote}java.lang.IllegalStateException: Stream hasn't been read yet
> at
> com.google.common.base.Preconditions.checkState(Preconditions.java:507)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.getSize(CassandraIncomingFile.java:96)
> at
> org.apache.cassandra.streaming.StreamSession.receive(StreamSession.java:789)
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:587)
> at
>
[jira] [Updated] (CASSANDRA-16918) CQLTester open more java driver connections than required by the tests
[
https://issues.apache.org/jira/browse/CASSANDRA-16918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16918:
---
Fix Version/s: (was: 4.x)
4.1
Source Control Link:
https://github.com/apache/cassandra/commit/138569b079b3d17b1020a24463adabecd903b79f
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed in trunk at 138569b079b3d17b1020a24463adabecd903b79f
> CQLTester open more java driver connections than required by the tests
> --
>
> Key: CASSANDRA-16918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16918
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When {{requireNetwork}} or {{reinitializeNetwork}} is called within a
> {{CQLTester}} unit test the test will open 4 connections to the server (one
> for each protocol version) even if the test only require a single connection.
> There are no good reasons for that behavior and the connections can simply be
> opened on a lazy way.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r49812 - in /release/cassandra: 4.0.1/redhat/ redhat/40x/
Author: samt Date: Tue Sep 7 13:38:49 2021 New Revision: 49812 Log: Apache Cassandra 4.0.1 redhat artifacts Added: release/cassandra/redhat/40x/ - copied from r49811, release/cassandra/4.0.1/redhat/ Removed: release/cassandra/4.0.1/redhat/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r49811 - /release/cassandra/redhat/40x/
Author: samt Date: Tue Sep 7 13:38:48 2021 New Revision: 49811 Log: Apache Cassandra 4.0.1 redhat artifacts Removed: release/cassandra/redhat/40x/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r49810 - /release/cassandra/4.0.1/debian/pool/
Author: samt Date: Tue Sep 7 13:38:11 2021 New Revision: 49810 Log: Apache Cassandra 4.0.1 debian artifacts Removed: release/cassandra/4.0.1/debian/pool/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r49809 - /release/cassandra/4.0.1/debian/dists/
Author: samt Date: Tue Sep 7 13:38:10 2021 New Revision: 49809 Log: Apache Cassandra 4.0.1 debian artifacts Removed: release/cassandra/4.0.1/debian/dists/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r49808 - in /release/cassandra: 4.0.1/debian/dists/40x/ debian/dists/40x/
Author: samt Date: Tue Sep 7 13:38:09 2021 New Revision: 49808 Log: Apache Cassandra 4.0.1 debian artifacts Added: release/cassandra/debian/dists/40x/ - copied from r49807, release/cassandra/4.0.1/debian/dists/40x/ Removed: release/cassandra/4.0.1/debian/dists/40x/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r49807 - /release/cassandra/debian/dists/40x/
Author: samt Date: Tue Sep 7 13:38:06 2021 New Revision: 49807 Log: Apache Cassandra 4.0.1 debian artifacts Removed: release/cassandra/debian/dists/40x/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r49806 - in /release/cassandra: 4.0.1/debian/pool/main/c/cassandra/cassandra_4.0.1_all.deb debian/pool/main/c/cassandra/cassandra_4.0.1_all.deb
Author: samt Date: Tue Sep 7 13:38:05 2021 New Revision: 49806 Log: Apache Cassandra 4.0.1 debian artifact cassandra_4.0.1_all.deb Added: release/cassandra/debian/pool/main/c/cassandra/cassandra_4.0.1_all.deb - copied unchanged from r49805, release/cassandra/4.0.1/debian/pool/main/c/cassandra/cassandra_4.0.1_all.deb Removed: release/cassandra/4.0.1/debian/pool/main/c/cassandra/cassandra_4.0.1_all.deb - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r49805 - in /release/cassandra: 4.0.1/debian/pool/main/c/cassandra/cassandra_4.0.1.tar.gz debian/pool/main/c/cassandra/cassandra_4.0.1.tar.gz
Author: samt Date: Tue Sep 7 13:38:03 2021 New Revision: 49805 Log: Apache Cassandra 4.0.1 debian artifact cassandra_4.0.1.tar.gz Added: release/cassandra/debian/pool/main/c/cassandra/cassandra_4.0.1.tar.gz - copied unchanged from r49804, release/cassandra/4.0.1/debian/pool/main/c/cassandra/cassandra_4.0.1.tar.gz Removed: release/cassandra/4.0.1/debian/pool/main/c/cassandra/cassandra_4.0.1.tar.gz - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r49804 - in /release/cassandra: 4.0.1/debian/pool/main/c/cassandra/cassandra_4.0.1.dsc debian/pool/main/c/cassandra/cassandra_4.0.1.dsc
Author: samt Date: Tue Sep 7 13:38:01 2021 New Revision: 49804 Log: Apache Cassandra 4.0.1 debian artifact cassandra_4.0.1.dsc Added: release/cassandra/debian/pool/main/c/cassandra/cassandra_4.0.1.dsc - copied unchanged from r49803, release/cassandra/4.0.1/debian/pool/main/c/cassandra/cassandra_4.0.1.dsc Removed: release/cassandra/4.0.1/debian/pool/main/c/cassandra/cassandra_4.0.1.dsc - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r49803 - in /release/cassandra: 4.0.1/debian/pool/main/c/cassandra/cassandra-tools_4.0.1_all.deb debian/pool/main/c/cassandra/cassandra-tools_4.0.1_all.deb
Author: samt Date: Tue Sep 7 13:37:58 2021 New Revision: 49803 Log: Apache Cassandra 4.0.1 debian artifact cassandra-tools_4.0.1_all.deb Added: release/cassandra/debian/pool/main/c/cassandra/cassandra-tools_4.0.1_all.deb - copied unchanged from r49802, release/cassandra/4.0.1/debian/pool/main/c/cassandra/cassandra-tools_4.0.1_all.deb Removed: release/cassandra/4.0.1/debian/pool/main/c/cassandra/cassandra-tools_4.0.1_all.deb - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16918) CQLTester open more java driver connections than required by the tests
[
https://issues.apache.org/jira/browse/CASSANDRA-16918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411242#comment-17411242
]
Benjamin Lerer commented on CASSANDRA-16918:
Thanks for the review.
> CQLTester open more java driver connections than required by the tests
> --
>
> Key: CASSANDRA-16918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16918
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When {{requireNetwork}} or {{reinitializeNetwork}} is called within a
> {{CQLTester}} unit test the test will open 4 connections to the server (one
> for each protocol version) even if the test only require a single connection.
> There are no good reasons for that behavior and the connections can simply be
> opened on a lazy way.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Open java driver connections in CQLTester in a lazy way
This is an automated email from the ASF dual-hosted git repository.
blerer 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 138569b Open java driver connections in CQLTester in a lazy way
138569b is described below
commit 138569b079b3d17b1020a24463adabecd903b79f
Author: Benjamin Lerer
AuthorDate: Mon Sep 6 13:36:14 2021 +0200
Open java driver connections in CQLTester in a lazy way
patch by Benjamin Lerer; reviewed by Andrés de la Peña for CASSANDRA-16918
---
.../apache/cassandra/transport/DriverBurnTest.java | 2 +-
test/unit/org/apache/cassandra/cql3/CQLTester.java | 122 +++--
.../cassandra/cql3/PreparedStatementsTest.java | 10 +-
.../metrics/ClientRequestSizeMetricsTest.java | 4 +-
.../transport/ClientNotificiationsTest.java| 3 +-
.../transport/ClientResourceLimitsTest.java| 5 +-
.../cassandra/transport/RateLimitingTest.java | 5 +-
7 files changed, 80 insertions(+), 71 deletions(-)
diff --git a/test/burn/org/apache/cassandra/transport/DriverBurnTest.java
b/test/burn/org/apache/cassandra/transport/DriverBurnTest.java
index 37ebec1..8aaf87e 100644
--- a/test/burn/org/apache/cassandra/transport/DriverBurnTest.java
+++ b/test/burn/org/apache/cassandra/transport/DriverBurnTest.java
@@ -62,7 +62,7 @@ public class DriverBurnTest extends CQLTester
}
};
-requireNetwork((builder) ->
builder.withPipelineConfigurator(configurator));
+requireNetwork(builder ->
builder.withPipelineConfigurator(configurator), builder -> {});
}
@Test
diff --git a/test/unit/org/apache/cassandra/cql3/CQLTester.java
b/test/unit/org/apache/cassandra/cql3/CQLTester.java
index f3c279c..56be6f6 100644
--- a/test/unit/org/apache/cassandra/cql3/CQLTester.java
+++ b/test/unit/org/apache/cassandra/cql3/CQLTester.java
@@ -125,7 +125,9 @@ public abstract class CQLTester
protected static final InetAddress nativeAddr;
protected static final Set remoteAddrs = new
HashSet<>();
private static final Map clusters = new
HashMap<>();
-protected static final Map sessions = new
HashMap<>();
+private static final Map sessions = new
HashMap<>();
+
+private static Consumer clusterBuilderConfigurator;
public static final List PROTOCOL_VERSIONS = new
ArrayList<>(ProtocolVersion.SUPPORTED.size());
@@ -411,26 +413,27 @@ public abstract class CQLTester
return allArgs;
}
-protected static void requireNetworkWithoutDriver()
-{
-startServices();
-startServer(server -> {});
-}
-
-// lazy initialization for all tests that require Java Driver
+/**
+ * Initialize Native Transport for test that need it.
+ */
protected static void requireNetwork() throws ConfigurationException
{
-requireNetwork(server -> {});
+requireNetwork(server -> {}, cluster -> {});
}
-// lazy initialization for all tests that require Java Driver
-protected static void requireNetwork(Consumer decorator)
throws ConfigurationException
+/**
+ * Initialize Native Transport for the tests that need it.
+ */
+protected static void requireNetwork(Consumer
serverConfigurator,
+ Consumer
clusterConfigurator) throws ConfigurationException
{
if (server != null)
return;
+clusterBuilderConfigurator = clusterConfigurator;
+
startServices();
-initializeNetwork(decorator, null);
+startServer(serverConfigurator);
}
private static void startServices()
@@ -443,10 +446,11 @@ public abstract class CQLTester
protected static void reinitializeNetwork()
{
-reinitializeNetwork(null);
+reinitializeNetwork(server -> {}, cluster -> {});
}
-protected static void reinitializeNetwork(Consumer
clusterConfigurator)
+protected static void reinitializeNetwork(Consumer
serverConfigurator,
+ Consumer
clusterConfigurator)
{
if (server != null && server.isRunning())
{
@@ -462,54 +466,49 @@ public abstract class CQLTester
clusters.clear();
sessions.clear();
-initializeNetwork(server -> {}, clusterConfigurator);
+clusterBuilderConfigurator = clusterConfigurator;
+
+startServer(serverConfigurator);
}
-private static void initializeNetwork(Consumer decorator,
Consumer clusterConfigurator)
+private static void startServer(Consumer decorator)
{
-startServer(decorator);
-
-for (ProtocolVersion version : PROTOCOL_VERSIONS)
-{
-if (clusters.containsKey(version))
-continue;
+Server.Builder serverBuilder = new
Server.Builder().withHost(nativeAddr).withPort(nativePort);
+
svn commit: r49802 - /dev/cassandra/4.0.1/ /release/cassandra/4.0.1/
Author: samt Date: Tue Sep 7 13:32:50 2021 New Revision: 49802 Log: Apache Cassandra 4.0.1 release Added: release/cassandra/4.0.1/ - copied from r49801, dev/cassandra/4.0.1/ Removed: dev/cassandra/4.0.1/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] annotated tag cassandra-4.0.1 updated (6709111 -> 387aaf4)
This is an automated email from the ASF dual-hosted git repository. samt pushed a change to annotated tag cassandra-4.0.1 in repository https://gitbox.apache.org/repos/asf/cassandra.git. *** WARNING: tag cassandra-4.0.1 was modified! *** from 6709111 (commit) to 387aaf4 (tag) tagging 6709111ed007a54b3e42884853f89cabd38e4316 (commit) replaces cassandra-4.0-rc2 by Sam Tunnicliffe on Tue Sep 7 14:32:22 2021 +0100 - Log - Apache Cassandra 4.0.1 release --- No new revisions were added by this update. Summary of changes: - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-11323) When node runs out of commitlog space you get poor log information
[
https://issues.apache.org/jira/browse/CASSANDRA-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411236#comment-17411236
]
Brandon Williams commented on CASSANDRA-11323:
--
I am not sure how merge markers were both introduced and removed in this PR,
but the end result looks good. +1 if CI is happy.
> When node runs out of commitlog space you get poor log information
> --
>
> Key: CASSANDRA-11323
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11323
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: T Jake Luciani
>Assignee: Boris Onufriyev
>Priority: Low
> Labels: fallout
> Attachments: 11323-2.2.txt, 11323-3.0.txt, 11323-3.0.txt,
> 11323-3.11.txt, 11323-3.11.txt, 11323-trunk.txt, 11323-trunk.txt
>
>
> {code}
> ERROR [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:470 - Stopping gossiper
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:377 - Stopping gossip by operator request
> INFO [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899 Gossiper.java:1463
> - Announcing shutdown
> {code}
> That's all you get when a node runs out of commit log space.
> We should explicitly callout the fact the commitlog is out of disk. I see
> that in the commit log error handler but after it shuts down. So I think it's
> never getting written before shutdown.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-11323) When node runs out of commitlog space you get poor log information
[
https://issues.apache.org/jira/browse/CASSANDRA-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411216#comment-17411216
]
Benjamin Lerer commented on CASSANDRA-11323:
I had some look at the patch and I have the following comments:
* The approach to compute the commitlog dir freespace do not handle large file
system
* Logging a separate error message is confusing as the 2 error messages can end
up being separated in the log file. It is probably better in my opinion to
merge the 2 messages together when needed. That will remove the need for the
{{SpamLogger}} as the messages are always logged anyway.
The PR for the modified version on 3.0 can be found
[here|https://github.com/apache/cassandra/pull/1188] and the CI results are
[here|https://app.circleci.com/pipelines/github/blerer/cassandra/200/workflows/c62fb6ed-7bdf-42f6-9e97-aa4a5c4b738d].
[~brandon.williams] Would you mind reviewing my changes?
> When node runs out of commitlog space you get poor log information
> --
>
> Key: CASSANDRA-11323
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11323
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: T Jake Luciani
>Assignee: Boris Onufriyev
>Priority: Low
> Labels: fallout
> Attachments: 11323-2.2.txt, 11323-3.0.txt, 11323-3.0.txt,
> 11323-3.11.txt, 11323-3.11.txt, 11323-trunk.txt, 11323-trunk.txt
>
>
> {code}
> ERROR [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:470 - Stopping gossiper
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:377 - Stopping gossip by operator request
> INFO [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899 Gossiper.java:1463
> - Announcing shutdown
> {code}
> That's all you get when a node runs out of commit log space.
> We should explicitly callout the fact the commitlog is out of disk. I see
> that in the commit log error handler but after it shuts down. So I think it's
> never getting written before shutdown.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16918) CQLTester open more java driver connections than required by the tests
[
https://issues.apache.org/jira/browse/CASSANDRA-16918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16918:
--
Status: Ready to Commit (was: Review In Progress)
> CQLTester open more java driver connections than required by the tests
> --
>
> Key: CASSANDRA-16918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16918
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When {{requireNetwork}} or {{reinitializeNetwork}} is called within a
> {{CQLTester}} unit test the test will open 4 connections to the server (one
> for each protocol version) even if the test only require a single connection.
> There are no good reasons for that behavior and the connections can simply be
> opened on a lazy way.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16918) CQLTester open more java driver connections than required by the tests
[
https://issues.apache.org/jira/browse/CASSANDRA-16918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411201#comment-17411201
]
Andres de la Peña commented on CASSANDRA-16918:
---
Looks good to me, +1.
The method {{CQLTester#requireNetworkWithoutDriver()}} was added during
CASSANDRA-16758 to fix {{ClientResourceLimitsTest}}. This patch makes that
unnecessary, but
[here|https://app.circleci.com/pipelines/github/adelapena/cassandra/833/workflows/507364e1-6342-4536-b03e-3be8a5f15353/jobs/8051]
and
[here|https://app.circleci.com/pipelines/github/adelapena/cassandra/833/workflows/475d7872-f02e-4300-91f7-3e8c4177b960/jobs/8046]
are some multiplexed runs of that method just in case.
> CQLTester open more java driver connections than required by the tests
> --
>
> Key: CASSANDRA-16918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16918
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When {{requireNetwork}} or {{reinitializeNetwork}} is called within a
> {{CQLTester}} unit test the test will open 4 connections to the server (one
> for each protocol version) even if the test only require a single connection.
> There are no good reasons for that behavior and the connections can simply be
> opened on a lazy way.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16918) CQLTester open more java driver connections than required by the tests
[
https://issues.apache.org/jira/browse/CASSANDRA-16918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16918:
--
Status: Review In Progress (was: Patch Available)
> CQLTester open more java driver connections than required by the tests
> --
>
> Key: CASSANDRA-16918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16918
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When {{requireNetwork}} or {{reinitializeNetwork}} is called within a
> {{CQLTester}} unit test the test will open 4 connections to the server (one
> for each protocol version) even if the test only require a single connection.
> There are no good reasons for that behavior and the connections can simply be
> opened on a lazy way.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-11323) When node runs out of commitlog space you get poor log information
[
https://issues.apache.org/jira/browse/CASSANDRA-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-11323:
---
Reviewers: Ariel Weisberg, Benjamin Lerer, Benjamin Lerer (was: Ariel
Weisberg, Benjamin Lerer)
Ariel Weisberg, Benjamin Lerer, Benjamin Lerer (was: Ariel
Weisberg)
Status: Review In Progress (was: Patch Available)
> When node runs out of commitlog space you get poor log information
> --
>
> Key: CASSANDRA-11323
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11323
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: T Jake Luciani
>Assignee: Boris Onufriyev
>Priority: Low
> Labels: fallout
> Attachments: 11323-2.2.txt, 11323-3.0.txt, 11323-3.0.txt,
> 11323-3.11.txt, 11323-3.11.txt, 11323-trunk.txt, 11323-trunk.txt
>
>
> {code}
> ERROR [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:470 - Stopping gossiper
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:377 - Stopping gossip by operator request
> INFO [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899 Gossiper.java:1463
> - Announcing shutdown
> {code}
> That's all you get when a node runs out of commit log space.
> We should explicitly callout the fact the commitlog is out of disk. I see
> that in the commit log error handler but after it shuts down. So I think it's
> never getting written before shutdown.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-11323) When node runs out of commitlog space you get poor log information
[
https://issues.apache.org/jira/browse/CASSANDRA-11323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-11323:
---
Status: Patch Available (was: Ready to Commit)
> When node runs out of commitlog space you get poor log information
> --
>
> Key: CASSANDRA-11323
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11323
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Observability
>Reporter: T Jake Luciani
>Assignee: Boris Onufriyev
>Priority: Low
> Labels: fallout
> Attachments: 11323-2.2.txt, 11323-3.0.txt, 11323-3.0.txt,
> 11323-3.11.txt, 11323-3.11.txt, 11323-trunk.txt, 11323-trunk.txt
>
>
> {code}
> ERROR [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:470 - Stopping gossiper
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899
> StorageService.java:377 - Stopping gossip by operator request
> INFO [PERIODIC-COMMIT-LOG-SYNCER] 2016-03-08 20:27:33,899 Gossiper.java:1463
> - Announcing shutdown
> {code}
> That's all you get when a node runs out of commit log space.
> We should explicitly callout the fact the commitlog is out of disk. I see
> that in the commit log error handler but after it shuts down. So I think it's
> never getting written before shutdown.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16790) Add auto_snapshot_ttl configuration
[
https://issues.apache.org/jira/browse/CASSANDRA-16790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411102#comment-17411102
]
Stefan Miklosovic commented on CASSANDRA-16790:
---
PR looks good however it is little bit tricky to test this because dropped /
truncated snapshots are not part of the listsnapshots (see CASSANDRA-16843). My
idea around testing is to create a table with auto_snapshot_ttl set, drop that
table, list snapshots to see it is there on ttl, wait for some time and list it
again to see it is not there anymore. However this "listing of dropped /
truncated" seems to be problematic.
We were together going through the code and we tried to fix this but changes
required are quite complex and we do not know how to approach this completely
and correctly yet.
I would say, lets spend some more time with this ticket and let's try come up
with the solution to the above problem so we are not committing something
half-cooked. Maybe trying to fix CASSANDRA-16843 first would be preferable
approach here.
> Add auto_snapshot_ttl configuration
> ---
>
> Key: CASSANDRA-16790
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16790
> Project: Cassandra
> Issue Type: Sub-task
> Components: Local/Config
>Reporter: Paulo Motta
>Assignee: Abuli Palagashvili
>Priority: Normal
>
> This property should take a human readable parameter (ie. 6h, 3days). When
> specified and {{auto_snapshot: true}}, auto snapshots created should use the
> specified TTL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16853) CircleCI folder in dtest is confusing
[
https://issues.apache.org/jira/browse/CASSANDRA-16853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16853:
---
Fix Version/s: 4.1
4.0.1
3.11.12
3.0.26
Source Control Link:
https://github.com/apache/cassandra-dtest/commit/efb82f574cd99ea598713035bbc9a95e568d73ce
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed as
[efb82f574cd99ea598713035bbc9a95e568d73ce|https://github.com/apache/cassandra-dtest/commit/efb82f574cd99ea598713035bbc9a95e568d73ce].
> CircleCI folder in dtest is confusing
> -
>
> Key: CASSANDRA-16853
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16853
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Ruslan Fomkin
>Assignee: Ruslan Fomkin
>Priority: Normal
> Fix For: 3.0.26, 3.11.12, 4.0.1, 4.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I made a patch to dtest without affecting Cassandra. cassandra-dtest repo
> contains folder with CircleCI configuration file. So I tried to run a [build
> from
> CircleCI|https://app.circleci.com/pipelines/github/k-rus/cassandra-dtest/3/workflows/6ea8058d-37b0-40e8-89be-d9b4afdf279c/jobs/4]
> and it failed with an error related to configuration:
> {code:java}
> ERROR: flake8 3.9.2 has requirement pycodestyle<2.8.0,>=2.7.0, but you'll
> have pycodestyle 2.3.1 which is incompatible.
> {code}
> The CircleCI config contains
> {code:java}
> sudo pip install pycodestyle==2.3.1 flake8
> {code}
> , so it should lead to the error.
> From the discussion in community I learned that dtest are run as part of
> Cassandra build and not on cassandra-dtest directly. Is the config in dtest
> maintained? If not, it might be good to remove. Or may be add some comment
> about it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-dtest] branch trunk updated: Remove CircleCI folder from dtest
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git The following commit(s) were added to refs/heads/trunk by this push: new efb82f5 Remove CircleCI folder from dtest efb82f5 is described below commit efb82f574cd99ea598713035bbc9a95e568d73ce Author: Ruslan Fomkin AuthorDate: Tue Sep 7 09:42:49 2021 +0200 Remove CircleCI folder from dtest CircleCI configuration in this repo is never used and, thus, is not up-to-date, which is confusing. This commit removes it. Configuration from the main Cassandra repo is used for running dtest in CircleCI. patch by Ruslan Fomkin; reviewed by Brandon Williams, Michael Semb Wever for CASSANDRA-16853 --- .circleci/config.yml | 29 - .gitignore | 1 + 2 files changed, 1 insertion(+), 29 deletions(-) diff --git a/.circleci/config.yml b/.circleci/config.yml deleted file mode 100644 index 708a8f1..000 --- a/.circleci/config.yml +++ /dev/null @@ -1,29 +0,0 @@ -version: 2 -jobs: - build: - docker: - - image: circleci/python:2.7 - steps: - - checkout - - run: - name: Install System Dependencies - command: | - sudo apt-get update -qq - sudo pip install pycodestyle==2.3.1 flake8 - sudo pip check - - run: - name: lint - command: | -# we want pyflakes to check all files for unused imports only -# we use flake8 because it allows us to ignore other warnings -# exclude the thrift directories - they contain auto-generated code -flake8 --ignore=E501,F811,F812,F822,F823,F831,F841,N8,C9 --exclude=thrift_bindings,cassandra-thrift . -git remote add apache git://github.com/apache/cassandra-dtest.git -git fetch apache # fetch master for the next diff -# feed changed lines with no context around them to pycodestyle -# I know we don't enforce line length but if you introduce -# 200-char lines you are doing something terribly wrong. -# lint all files for everything but line length errors -git diff apache/master...HEAD -U0 | pycodestyle --ignore=E501 --diff -# lint all files except json_test.py for line length errors -git diff apache/master...HEAD -U0 | pycodestyle --diff --exclude='json_test.py' --exclude='meta_tests/assertion_test.py' --max-line-length=200 \ No newline at end of file diff --git a/.gitignore b/.gitignore index 5132139..2b6fb27 100644 --- a/.gitignore +++ b/.gitignore @@ -10,3 +10,4 @@ last_test_dir upgrade html/ doxygen/doxypy-0.4.2/ +.pytest_cache/ - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16853) CircleCI folder in dtest is confusing
[
https://issues.apache.org/jira/browse/CASSANDRA-16853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16853:
---
Reviewers: Brandon Williams, Michael Semb Wever (was: Michael Semb Wever)
> CircleCI folder in dtest is confusing
> -
>
> Key: CASSANDRA-16853
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16853
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Ruslan Fomkin
>Assignee: Ruslan Fomkin
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I made a patch to dtest without affecting Cassandra. cassandra-dtest repo
> contains folder with CircleCI configuration file. So I tried to run a [build
> from
> CircleCI|https://app.circleci.com/pipelines/github/k-rus/cassandra-dtest/3/workflows/6ea8058d-37b0-40e8-89be-d9b4afdf279c/jobs/4]
> and it failed with an error related to configuration:
> {code:java}
> ERROR: flake8 3.9.2 has requirement pycodestyle<2.8.0,>=2.7.0, but you'll
> have pycodestyle 2.3.1 which is incompatible.
> {code}
> The CircleCI config contains
> {code:java}
> sudo pip install pycodestyle==2.3.1 flake8
> {code}
> , so it should lead to the error.
> From the discussion in community I learned that dtest are run as part of
> Cassandra build and not on cassandra-dtest directly. Is the config in dtest
> maintained? If not, it might be good to remove. Or may be add some comment
> about it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16853) CircleCI folder in dtest is confusing
[
https://issues.apache.org/jira/browse/CASSANDRA-16853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16853:
---
Status: Ready to Commit (was: Review In Progress)
> CircleCI folder in dtest is confusing
> -
>
> Key: CASSANDRA-16853
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16853
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Ruslan Fomkin
>Assignee: Ruslan Fomkin
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I made a patch to dtest without affecting Cassandra. cassandra-dtest repo
> contains folder with CircleCI configuration file. So I tried to run a [build
> from
> CircleCI|https://app.circleci.com/pipelines/github/k-rus/cassandra-dtest/3/workflows/6ea8058d-37b0-40e8-89be-d9b4afdf279c/jobs/4]
> and it failed with an error related to configuration:
> {code:java}
> ERROR: flake8 3.9.2 has requirement pycodestyle<2.8.0,>=2.7.0, but you'll
> have pycodestyle 2.3.1 which is incompatible.
> {code}
> The CircleCI config contains
> {code:java}
> sudo pip install pycodestyle==2.3.1 flake8
> {code}
> , so it should lead to the error.
> From the discussion in community I learned that dtest are run as part of
> Cassandra build and not on cassandra-dtest directly. Is the config in dtest
> maintained? If not, it might be good to remove. Or may be add some comment
> about it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16853) CircleCI folder in dtest is confusing
[
https://issues.apache.org/jira/browse/CASSANDRA-16853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16853:
---
Reviewers: Michael Semb Wever
Status: Review In Progress (was: Patch Available)
> CircleCI folder in dtest is confusing
> -
>
> Key: CASSANDRA-16853
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16853
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Ruslan Fomkin
>Assignee: Ruslan Fomkin
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I made a patch to dtest without affecting Cassandra. cassandra-dtest repo
> contains folder with CircleCI configuration file. So I tried to run a [build
> from
> CircleCI|https://app.circleci.com/pipelines/github/k-rus/cassandra-dtest/3/workflows/6ea8058d-37b0-40e8-89be-d9b4afdf279c/jobs/4]
> and it failed with an error related to configuration:
> {code:java}
> ERROR: flake8 3.9.2 has requirement pycodestyle<2.8.0,>=2.7.0, but you'll
> have pycodestyle 2.3.1 which is incompatible.
> {code}
> The CircleCI config contains
> {code:java}
> sudo pip install pycodestyle==2.3.1 flake8
> {code}
> , so it should lead to the error.
> From the discussion in community I learned that dtest are run as part of
> Cassandra build and not on cassandra-dtest directly. Is the config in dtest
> maintained? If not, it might be good to remove. Or may be add some comment
> about it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16853) CircleCI folder in dtest is confusing
[
https://issues.apache.org/jira/browse/CASSANDRA-16853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411070#comment-17411070
]
Michael Semb Wever commented on CASSANDRA-16853:
+1
> CircleCI folder in dtest is confusing
> -
>
> Key: CASSANDRA-16853
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16853
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Ruslan Fomkin
>Assignee: Ruslan Fomkin
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I made a patch to dtest without affecting Cassandra. cassandra-dtest repo
> contains folder with CircleCI configuration file. So I tried to run a [build
> from
> CircleCI|https://app.circleci.com/pipelines/github/k-rus/cassandra-dtest/3/workflows/6ea8058d-37b0-40e8-89be-d9b4afdf279c/jobs/4]
> and it failed with an error related to configuration:
> {code:java}
> ERROR: flake8 3.9.2 has requirement pycodestyle<2.8.0,>=2.7.0, but you'll
> have pycodestyle 2.3.1 which is incompatible.
> {code}
> The CircleCI config contains
> {code:java}
> sudo pip install pycodestyle==2.3.1 flake8
> {code}
> , so it should lead to the error.
> From the discussion in community I learned that dtest are run as part of
> Cassandra build and not on cassandra-dtest directly. Is the config in dtest
> maintained? If not, it might be good to remove. Or may be add some comment
> about it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16916) Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-16916:
--
Assignee: Jogesh Anand
> Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
> ---
>
> Key: CASSANDRA-16916
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16916
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Jogesh Anand
>Priority: Normal
>
> It would make sense to add support for {{IF EXISTS}} and {{IF NOT EXISTS}} in
> the different {{ALTER}} statements.
> For example:
> * {{ALTER TABLE IF EXISTS myTable ...}}
> * {{ALTER TABLE myTable ADD IF NOT EXISTS ...}}
> * {{ALTER TABLE myTable DROP IF EXISTS ...}}
> * {{ALTER TYPE IF EXISTS myType ...}}
> * {{ALTER TYPE myType ADD IF NOT EXISTS ...}}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the {{Parser.g}}
> ANTLR file located in the src/antlr directory and the java classes
> corresponding to the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package. You can look at the
> CreateTableStatement class to see how it was done there.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16886) Reduce native_transport_max_frame_size_in_mb
[ https://issues.apache.org/jira/browse/CASSANDRA-16886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16886: --- Reviewers: Benjamin Lerer > Reduce native_transport_max_frame_size_in_mb > > > Key: CASSANDRA-16886 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16886 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Client >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > There is really no point in having this set to 256MB when the commitlog > segment size defaults to 32MB, effectively capping the largest insertable > mutation to 16MB. > The native transport can provide a good first line of defense against large > mutations that would otherwise hit the heap if left to be rejected by the > commitlog. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16886) Reduce native_transport_max_frame_size_in_mb
[ https://issues.apache.org/jira/browse/CASSANDRA-16886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16886: --- Status: Review In Progress (was: Patch Available) > Reduce native_transport_max_frame_size_in_mb > > > Key: CASSANDRA-16886 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16886 > Project: Cassandra > Issue Type: Improvement > Components: Messaging/Client >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > There is really no point in having this set to 256MB when the commitlog > segment size defaults to 32MB, effectively capping the largest insertable > mutation to 16MB. > The native transport can provide a good first line of defense against large > mutations that would otherwise hit the heap if left to be rejected by the > commitlog. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16886) Reduce native_transport_max_frame_size_in_mb
[
https://issues.apache.org/jira/browse/CASSANDRA-16886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411030#comment-17411030
]
Benjamin Lerer commented on CASSANDRA-16886:
The patch look good to me. The only nit I have is regarding the use of numeric
values for bytes to/from MB converversions.
Even if we rely on CASSANDRA-15234 to fix that later on we should probably use
{{org.apache.cassandra.io.util.FileUtils.ONE_MB}} instead of {{1048576}}. An
other optrion would be to use {{ByteUnit}} and add a {{fromBytes}} method to
it.
> Reduce native_transport_max_frame_size_in_mb
>
>
> Key: CASSANDRA-16886
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16886
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
>
> There is really no point in having this set to 256MB when the commitlog
> segment size defaults to 32MB, effectively capping the largest insertable
> mutation to 16MB.
> The native transport can provide a good first line of defense against large
> mutations that would otherwise hit the heap if left to be rejected by the
> commitlog.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16853) CircleCI folder in dtest is confusing
[
https://issues.apache.org/jira/browse/CASSANDRA-16853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411022#comment-17411022
]
Ruslan Fomkin commented on CASSANDRA-16853:
---
[PR with the patch|https://github.com/apache/cassandra-dtest/pull/158]
[Java 11 CircleCI
build|https://app.circleci.com/pipelines/github/k-rus/cassandra/9/workflows/9ab1e7ad-f0dd-41b8-b621-e6f30e93c9c6]
[Java 8 CircleCI
build|https://app.circleci.com/pipelines/github/k-rus/cassandra/9/workflows/506ba0ed-0f39-4582-a3eb-b445e6d5e8e9]
> CircleCI folder in dtest is confusing
> -
>
> Key: CASSANDRA-16853
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16853
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Ruslan Fomkin
>Assignee: Ruslan Fomkin
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I made a patch to dtest without affecting Cassandra. cassandra-dtest repo
> contains folder with CircleCI configuration file. So I tried to run a [build
> from
> CircleCI|https://app.circleci.com/pipelines/github/k-rus/cassandra-dtest/3/workflows/6ea8058d-37b0-40e8-89be-d9b4afdf279c/jobs/4]
> and it failed with an error related to configuration:
> {code:java}
> ERROR: flake8 3.9.2 has requirement pycodestyle<2.8.0,>=2.7.0, but you'll
> have pycodestyle 2.3.1 which is incompatible.
> {code}
> The CircleCI config contains
> {code:java}
> sudo pip install pycodestyle==2.3.1 flake8
> {code}
> , so it should lead to the error.
> From the discussion in community I learned that dtest are run as part of
> Cassandra build and not on cassandra-dtest directly. Is the config in dtest
> maintained? If not, it might be good to remove. Or may be add some comment
> about it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16853) CircleCI folder in dtest is confusing
[
https://issues.apache.org/jira/browse/CASSANDRA-16853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruslan Fomkin updated CASSANDRA-16853:
--
Test and Documentation Plan:
[PR with the patch|https://github.com/apache/cassandra-dtest/pull/158]
[Java 11 CircleCI
build|https://app.circleci.com/pipelines/github/k-rus/cassandra/9/workflows/9ab1e7ad-f0dd-41b8-b621-e6f30e93c9c6]
[Java 8 CircleCI
build|https://app.circleci.com/pipelines/github/k-rus/cassandra/9/workflows/506ba0ed-0f39-4582-a3eb-b445e6d5e8e9]
Status: Patch Available (was: In Progress)
> CircleCI folder in dtest is confusing
> -
>
> Key: CASSANDRA-16853
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16853
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Ruslan Fomkin
>Assignee: Ruslan Fomkin
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I made a patch to dtest without affecting Cassandra. cassandra-dtest repo
> contains folder with CircleCI configuration file. So I tried to run a [build
> from
> CircleCI|https://app.circleci.com/pipelines/github/k-rus/cassandra-dtest/3/workflows/6ea8058d-37b0-40e8-89be-d9b4afdf279c/jobs/4]
> and it failed with an error related to configuration:
> {code:java}
> ERROR: flake8 3.9.2 has requirement pycodestyle<2.8.0,>=2.7.0, but you'll
> have pycodestyle 2.3.1 which is incompatible.
> {code}
> The CircleCI config contains
> {code:java}
> sudo pip install pycodestyle==2.3.1 flake8
> {code}
> , so it should lead to the error.
> From the discussion in community I learned that dtest are run as part of
> Cassandra build and not on cassandra-dtest directly. Is the config in dtest
> maintained? If not, it might be good to remove. Or may be add some comment
> about it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16853) CircleCI folder in dtest is confusing
[
https://issues.apache.org/jira/browse/CASSANDRA-16853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruslan Fomkin reassigned CASSANDRA-16853:
-
Assignee: Ruslan Fomkin
> CircleCI folder in dtest is confusing
> -
>
> Key: CASSANDRA-16853
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16853
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Ruslan Fomkin
>Assignee: Ruslan Fomkin
>Priority: Normal
>
> I made a patch to dtest without affecting Cassandra. cassandra-dtest repo
> contains folder with CircleCI configuration file. So I tried to run a [build
> from
> CircleCI|https://app.circleci.com/pipelines/github/k-rus/cassandra-dtest/3/workflows/6ea8058d-37b0-40e8-89be-d9b4afdf279c/jobs/4]
> and it failed with an error related to configuration:
> {code:java}
> ERROR: flake8 3.9.2 has requirement pycodestyle<2.8.0,>=2.7.0, but you'll
> have pycodestyle 2.3.1 which is incompatible.
> {code}
> The CircleCI config contains
> {code:java}
> sudo pip install pycodestyle==2.3.1 flake8
> {code}
> , so it should lead to the error.
> From the discussion in community I learned that dtest are run as part of
> Cassandra build and not on cassandra-dtest directly. Is the config in dtest
> maintained? If not, it might be good to remove. Or may be add some comment
> about it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
