[jira] [Updated] (CASSANDRA-14541) Order of warning and custom payloads is unspecified in the protocol specification
[ https://issues.apache.org/jira/browse/CASSANDRA-14541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mck updated CASSANDRA-14541: Reviewer: mck (was: Alex Petrov) Fix Version/s: 4.x 3.11.x > Order of warning and custom payloads is unspecified in the protocol > specification > - > > Key: CASSANDRA-14541 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14541 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Documentation and Website >Reporter: Avi Kivity >Assignee: Avi Kivity >Priority: Trivial > Fix For: 3.11.x, 4.x > > Attachments: > v1-0001-Document-order-of-tracing-warning-and-custom-payl.patch > > > Section 2.2 of the protocol specification documents the types of tracing, > warning, and custom payloads, but does not document their order in the body. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14688) Update protocol spec and class level doc with protocol checksumming details
[
https://issues.apache.org/jira/browse/CASSANDRA-14688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mck updated CASSANDRA-14688:
Reviewer: mck
LGTM, one small typo "franmed" spotted.
> Update protocol spec and class level doc with protocol checksumming details
> ---
>
> Key: CASSANDRA-14688
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14688
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Documentation and Website
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Major
> Fix For: 4.0
>
>
> CASSANDRA-13304 provides an option to add checksumming to the frame body of
> native protocol messages. The native protocol spec needs to be updated to
> reflect this ASAP. We should also verify that the javadoc comments describing
> the on-wire format in
> {{o.a.c.transport.frame.checksum.ChecksummingTransformer}} are up to date.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14688) Update protocol spec and class level doc with protocol checksumming details
[
https://issues.apache.org/jira/browse/CASSANDRA-14688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mck updated CASSANDRA-14688:
Status: Ready to Commit (was: Patch Available)
> Update protocol spec and class level doc with protocol checksumming details
> ---
>
> Key: CASSANDRA-14688
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14688
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Documentation and Website
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
>Priority: Major
> Fix For: 4.0
>
>
> CASSANDRA-13304 provides an option to add checksumming to the frame body of
> native protocol messages. The native protocol spec needs to be updated to
> reflect this ASAP. We should also verify that the javadoc comments describing
> the on-wire format in
> {{o.a.c.transport.frame.checksum.ChecksummingTransformer}} are up to date.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14851) Blog Post: "Introducing Transient Replication"
[ https://issues.apache.org/jira/browse/CASSANDRA-14851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] mck updated CASSANDRA-14851: Resolution: Fixed Status: Resolved (was: Patch Available) This got [published|https://svn.apache.org/viewvc?view=revision=1848086] on 2018/12/03 > Blog Post: "Introducing Transient Replication" > -- > > Key: CASSANDRA-14851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14851 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Documentation and Website >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg >Priority: Minor > Labels: blog > Attachments: introducing_transient_replication.patch > > > This is a blog post introducing transient replication. The patch (patch > compatible) attached applies to the website repo (outside the project's > primary Git repo). > SVN patch containing the post is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14954) Website documentation for stable and latest, with stable as default linked
[
https://issues.apache.org/jira/browse/CASSANDRA-14954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mck updated CASSANDRA-14954:
Description:
The website should link Documentation to the docs generated for our most recent
stable release.
By providing directory listing ({{htaccess Indexes}}) under /doc/, and having
two symlinks {{latest}} and {{stable}}, we can by default link to {{stable}}.
This patch
- adds to the website Makefile the task {{add-stable-doc}}
- changes the default documentation link to {{/doc/stable/}}
- removes the html redirecting from {{doc/ --> doc/latest/}}
- adds directory listing to {{/doc/}} for a simple view of versioned docs
available
was:
The website should link Documentation to the docs generated for our latest
stable release.
By providing directory listing ({{htaccess Indexes}}) under /doc/, and having
two symlinks {{latest}} and {{stable}}, we can by default link to {{stable}}.
This patch
- adds to the website Makefile the task {{add-stable-doc}}
- changes the default documentation link to {{/doc/stable/}}
- removes the html redirecting from {{doc/ --> doc/latest/}}
- adds directory listing to {{/doc/}} for a simple view of versioned docs
available
> Website documentation for stable and latest, with stable as default linked
> --
>
> Key: CASSANDRA-14954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14954
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: mck
>Priority: Trivial
> Attachments: make-add-stable-doc.patch
>
>
> The website should link Documentation to the docs generated for our most
> recent stable release.
> By providing directory listing ({{htaccess Indexes}}) under /doc/, and having
> two symlinks {{latest}} and {{stable}}, we can by default link to {{stable}}.
> This patch
> - adds to the website Makefile the task {{add-stable-doc}}
> - changes the default documentation link to {{/doc/stable/}}
> - removes the html redirecting from {{doc/ --> doc/latest/}}
> - adds directory listing to {{/doc/}} for a simple view of versioned docs
> available
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14954) Website documentation for stable and latest, with stable as default linked
[
https://issues.apache.org/jira/browse/CASSANDRA-14954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mck updated CASSANDRA-14954:
Assignee: mck
Reviewer: Jason Brown
Fix Version/s: 4.x
3.11.x
Status: Patch Available (was: Open)
> Website documentation for stable and latest, with stable as default linked
> --
>
> Key: CASSANDRA-14954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14954
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: mck
>Assignee: mck
>Priority: Trivial
> Fix For: 3.11.x, 4.x
>
> Attachments: make-add-stable-doc.patch
>
>
> The website should link Documentation to the docs generated for our most
> recent stable release.
> By providing directory listing (using {{`htaccess Indexes`}}) under /doc/,
> and having two symlinks {{latest}} and {{stable}}, we can by default link to
> {{stable}}.
> The following patch
> - adds to the website Makefile the task {{add-stable-doc}}
> - changes the default documentation link to {{/doc/stable/}}
> - removes the html redirecting from {{doc/ --> doc/latest/}}
> - adds directory listing to {{/doc/}} for a simple view of versioned docs
> available
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14954) Website documentation for stable and latest, with stable as default linked
[
https://issues.apache.org/jira/browse/CASSANDRA-14954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mck updated CASSANDRA-14954:
Description:
The website should link Documentation to the docs generated for our most recent
stable release.
By providing directory listing (using {{`htaccess Indexes`}}) under /doc/, and
having two symlinks {{latest}} and {{stable}}, we can by default link to
{{stable}}.
The following patch
- adds to the website Makefile the task {{add-stable-doc}}
- changes the default documentation link to {{/doc/stable/}}
- removes the html redirecting from {{doc/ --> doc/latest/}}
- adds directory listing to {{/doc/}} for a simple view of versioned docs
available
was:
The website should link Documentation to the docs generated for our most recent
stable release.
By providing directory listing (using {{`htaccess Indexes`}}) under /doc/, and
having two symlinks {{latest}} and {{stable}}, we can by default link to
{{stable}}.
This patch
- adds to the website Makefile the task {{add-stable-doc}}
- changes the default documentation link to {{/doc/stable/}}
- removes the html redirecting from {{doc/ --> doc/latest/}}
- adds directory listing to {{/doc/}} for a simple view of versioned docs
available
> Website documentation for stable and latest, with stable as default linked
> --
>
> Key: CASSANDRA-14954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14954
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: mck
>Priority: Trivial
> Attachments: make-add-stable-doc.patch
>
>
> The website should link Documentation to the docs generated for our most
> recent stable release.
> By providing directory listing (using {{`htaccess Indexes`}}) under /doc/,
> and having two symlinks {{latest}} and {{stable}}, we can by default link to
> {{stable}}.
> The following patch
> - adds to the website Makefile the task {{add-stable-doc}}
> - changes the default documentation link to {{/doc/stable/}}
> - removes the html redirecting from {{doc/ --> doc/latest/}}
> - adds directory listing to {{/doc/}} for a simple view of versioned docs
> available
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14954) Website documentation for stable and latest, with stable as default linked
[
https://issues.apache.org/jira/browse/CASSANDRA-14954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mck updated CASSANDRA-14954:
Description:
The website should link Documentation to the docs generated for our most recent
stable release.
By providing directory listing (using {{`htaccess Indexes`}}) under /doc/, and
having two symlinks {{latest}} and {{stable}}, we can by default link to
{{stable}}.
This patch
- adds to the website Makefile the task {{add-stable-doc}}
- changes the default documentation link to {{/doc/stable/}}
- removes the html redirecting from {{doc/ --> doc/latest/}}
- adds directory listing to {{/doc/}} for a simple view of versioned docs
available
was:
The website should link Documentation to the docs generated for our most recent
stable release.
By providing directory listing ({{htaccess Indexes}}) under /doc/, and having
two symlinks {{latest}} and {{stable}}, we can by default link to {{stable}}.
This patch
- adds to the website Makefile the task {{add-stable-doc}}
- changes the default documentation link to {{/doc/stable/}}
- removes the html redirecting from {{doc/ --> doc/latest/}}
- adds directory listing to {{/doc/}} for a simple view of versioned docs
available
> Website documentation for stable and latest, with stable as default linked
> --
>
> Key: CASSANDRA-14954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14954
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: mck
>Priority: Trivial
> Attachments: make-add-stable-doc.patch
>
>
> The website should link Documentation to the docs generated for our most
> recent stable release.
> By providing directory listing (using {{`htaccess Indexes`}}) under /doc/,
> and having two symlinks {{latest}} and {{stable}}, we can by default link to
> {{stable}}.
> This patch
> - adds to the website Makefile the task {{add-stable-doc}}
> - changes the default documentation link to {{/doc/stable/}}
> - removes the html redirecting from {{doc/ --> doc/latest/}}
> - adds directory listing to {{/doc/}} for a simple view of versioned docs
> available
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14954) Website documentation for stable and latest, with stable as default linked
[
https://issues.apache.org/jira/browse/CASSANDRA-14954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mck updated CASSANDRA-14954:
Attachment: make-add-stable-doc.patch
> Website documentation for stable and latest, with stable as default linked
> --
>
> Key: CASSANDRA-14954
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14954
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: mck
>Priority: Trivial
> Attachments: make-add-stable-doc.patch
>
>
> The website should link Documentation to the docs generated for our latest
> stable release.
> By providing directory listing ({{htaccess Indexes}}) under /doc/, and having
> two symlinks {{latest}} and {{stable}}, we can by default link to {{stable}}.
> This patch
> - adds to the website Makefile the task {{add-stable-doc}}
> - changes the default documentation link to {{/doc/stable/}}
> - removes the html redirecting from {{doc/ --> doc/latest/}}
> - adds directory listing to {{/doc/}} for a simple view of versioned docs
> available
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14954) Website documentation for stable and latest, with stable as default linked
mck created CASSANDRA-14954:
---
Summary: Website documentation for stable and latest, with stable
as default linked
Key: CASSANDRA-14954
URL: https://issues.apache.org/jira/browse/CASSANDRA-14954
Project: Cassandra
Issue Type: Task
Components: Documentation/Website
Reporter: mck
The website should link Documentation to the docs generated for our latest
stable release.
By providing directory listing ({{htaccess Indexes}}) under /doc/, and having
two symlinks {{latest}} and {{stable}}, we can by default link to {{stable}}.
This patch
- adds to the website Makefile the task {{add-stable-doc}}
- changes the default documentation link to {{/doc/stable/}}
- removes the html redirecting from {{doc/ --> doc/latest/}}
- adds directory listing to {{/doc/}} for a simple view of versioned docs
available
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14953) Failed to reclaim the memory and too many MemtableReclaimMemory pending task
[ https://issues.apache.org/jira/browse/CASSANDRA-14953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] HUANG DUICAN updated CASSANDRA-14953: - Description: We found that Cassandra has a lot of write accumulation in the production environment, and our business has experienced a lot of write failures. Through the system.log, it was found that MemtableReclaimMemory was pending at the beginning, and then a large number of MutationStage stacks appeared at a certain moment. Finally, the heap memory is full, the GC time reaches tens of seconds, the node status is DN through nodetool, but the Cassandra process is still running.We killed the node and restarted the node, and the above situation disappeared. Also the number of Active MemtableReclaimMemory threads seems to stay at 1. !image-2019-01-05-11-36-31-199.png! a large number of MutationStage stacks appeared at a certain moment. !image-2019-01-05-11-37-54-253.png! long GC time: !image-2019-01-05-11-38-21-711.png! Why is this happening? was: We found that Cassandra has a lot of write accumulation in the production environment, and our business has experienced a lot of write failures. Through the system.log, it was found that MemtableReclaimMemory was pending at the beginning, and then a large number of MutationStage stacks appeared at a certain moment. Finally, the heap memory is full, the GC time reaches tens of seconds, the node status is DN through nodetool, but the Cassandra process is still running.We killed the node and restarted the node, and the above situation disappeared. Also the number of Active MemtableReclaimMemory threads seems to stay at 1. !image-2019-01-05-11-23-23-752.png! a large number of MutationStage stacks appeared at a certain moment. !image-2019-01-05-11-26-56-546.png! long GC time: !image-2019-01-05-11-28-00-371.png! Why is this happening? > Failed to reclaim the memory and too many MemtableReclaimMemory pending task > > > Key: CASSANDRA-14953 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14953 > Project: Cassandra > Issue Type: Bug > Components: Local/Memtable > Environment: version : cassandra 2.1.15 > jdk: 8 > os:suse >Reporter: HUANG DUICAN >Priority: Major > Attachments: cassandra_20190105.zip > > > We found that Cassandra has a lot of write accumulation in the production > environment, and our business has experienced a lot of write failures. > Through the system.log, it was found that MemtableReclaimMemory was pending > at the beginning, and then a large number of MutationStage stacks appeared at > a certain moment. > Finally, the heap memory is full, the GC time reaches tens of seconds, the > node status is DN through nodetool, but the Cassandra process is still > running.We killed the node and restarted the node, and the above situation > disappeared. > > Also the number of Active MemtableReclaimMemory threads seems to stay at 1. > !image-2019-01-05-11-36-31-199.png! > a large number of MutationStage stacks appeared at a certain moment. > !image-2019-01-05-11-37-54-253.png! > > long GC time: > !image-2019-01-05-11-38-21-711.png! > > Why is this happening? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14953) Failed to reclaim the memory and too many MemtableReclaimMemory pending task
[
https://issues.apache.org/jira/browse/CASSANDRA-14953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
HUANG DUICAN updated CASSANDRA-14953:
-
Attachment: 2.PNG
1.PNG
Description:
We found that Cassandra has a lot of write accumulation in the production
environment, and our business has experienced a lot of write failures.
Through the system.log, it was found that MemtableReclaimMemory was pending at
the beginning, and then a large number of MutationStage stacks appeared at a
certain moment.
Finally, the heap memory is full, the GC time reaches tens of seconds, the
node status is DN through nodetool, but the Cassandra process is still
running.We killed the node and restarted the node, and the above situation
disappeared.
Also the number of Active MemtableReclaimMemory threads seems to stay at 1.
(you can see the 1.PNG)
a large number of MutationStage stacks appeared at a certain moment.
(you can see the 2.PNG)
long GC time:
- MemtableReclaimMemory 1 156 24565 0 0
- G1 Old Generation GC in 87121ms. G1 Old Gen: 51175946656 -> 50082999760;
- MutationStage 128 11931622 1983820772 0 0
- CounterMutationStage 0 0 0 0 0
- MemtableReclaimMemory 1 156 24565 0 0
- G1 Young Generation GC in {color:#FF}969ms{color}. G1 Eden Space:
1090519040 -> 0; G1 Old Gen: 50082999760 -> 51156741584;
- MutationStage 128 11953653 1983820772 0 0
- CounterMutationStage 0 0 0 0 0
- MemtableReclaimMemory 1 156 24565 0 0
- G1 Old Generation GC in {color:#FF}84785ms{color}. G1 Old Gen:
51173518800 -> 50180911432;
- MutationStage 128 11967484 1983820772 0 0
- CounterMutationStage 0 0 0 0 0
- MemtableReclaimMemory 1 156 24565 0 0
- G1 Young Generation GC in 611ms. G1 Eden Space: 989855744 -> 0; G1 Old Gen:
50180911432 -> 51153989960;
- MutationStage 128 11975849 1983820772 0 0
- CounterMutationStage 0 0 0 0 0
- MemtableReclaimMemory 1 156 24565 0 0
- G1 Old Generation GC in {color:#FF}85845ms{color}. G1 Old Gen:
51170767176 -> 50238295416;
- MutationStage 128 11978192 1983820772 0 0
- CounterMutationStage 0 0 0 0 0
- MemtableReclaimMemory 1 156 24565 0 0
- G1 Young Generation GC in 602ms. G1 Eden Space: 939524096 -> 0; G1 Old Gen:
50238295416 -> 51161042296;
- MutationStage 128 11994295 1983820772 0 0
- CounterMutationStage 0 0 0 0 0
- MemtableReclaimMemory 1 156 24565 0 0
- G1 Old Generation GC in {color:#FF}85307ms{color}. G1 Old Gen:
51177819512 -> 50288829624; Metaspace: 36544536 -> 36525696
- MutationStage 128 12001932 1983820772 0 0
- CounterMutationStage 0 0 0 0 0
66 - MutationStage 128 12004395 1983820772 0 0
66 - CounterMutationStage 0 0 0 0 0
- MemtableReclaimMemory 1 156 24565 0 0
66 - MemtableReclaimMemory 1 156 24565 0 0
- G1 Young Generation GC in 610ms. G1 Eden Space: 889192448 -> 0; G1 Old Gen:
50288829624 -> 51178022072;
- MutationStage 128 12023677 1983820772 0 0
Why is this happening?
was:
We found that Cassandra has a lot of write accumulation in the production
environment, and our business has experienced a lot of write failures.
Through the system.log, it was found that MemtableReclaimMemory was pending at
the beginning, and then a large number of MutationStage stacks appeared at a
certain moment.
Finally, the heap memory is full, the GC time reaches tens of seconds, the node
status is DN through nodetool, but the Cassandra process is still running.We
killed the node and restarted the node, and the above situation disappeared.
Also the number of Active MemtableReclaimMemory threads seems to stay at 1.
a large number of MutationStage stacks appeared at a certain moment.
long GC time:
Why is this happening?
> Failed to reclaim the memory and too many MemtableReclaimMemory pending task
>
>
> Key: CASSANDRA-14953
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14953
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Memtable
> Environment: version : cassandra 2.1.15
> jdk: 8
> os:suse
>Reporter: HUANG DUICAN
>Priority: Major
> Attachments: 1.PNG, 2.PNG, cassandra_20190105.zip
>
>
> We found that Cassandra has a lot of write accumulation in the production
> environment, and our business has experienced a lot of write failures.
> Through the system.log, it was found that MemtableReclaimMemory was pending
> at the beginning, and then a large number of MutationStage stacks appeared at
> a certain moment.
> Finally, the heap memory is full, the GC time reaches tens of seconds, the
> node status is DN through nodetool, but the Cassandra process is still
> running.We killed the node and restarted the node, and the above situation
> disappeared.
>
> Also the number of Active MemtableReclaimMemory threads seems to stay at 1.
> (you can
[jira] [Updated] (CASSANDRA-14953) Failed to reclaim the memory and too many MemtableReclaimMemory pending task
[ https://issues.apache.org/jira/browse/CASSANDRA-14953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] HUANG DUICAN updated CASSANDRA-14953: - Description: We found that Cassandra has a lot of write accumulation in the production environment, and our business has experienced a lot of write failures. Through the system.log, it was found that MemtableReclaimMemory was pending at the beginning, and then a large number of MutationStage stacks appeared at a certain moment. Finally, the heap memory is full, the GC time reaches tens of seconds, the node status is DN through nodetool, but the Cassandra process is still running.We killed the node and restarted the node, and the above situation disappeared. Also the number of Active MemtableReclaimMemory threads seems to stay at 1. a large number of MutationStage stacks appeared at a certain moment. long GC time: Why is this happening? was: We found that Cassandra has a lot of write accumulation in the production environment, and our business has experienced a lot of write failures. Through the system.log, it was found that MemtableReclaimMemory was pending at the beginning, and then a large number of MutationStage stacks appeared at a certain moment. Finally, the heap memory is full, the GC time reaches tens of seconds, the node status is DN through nodetool, but the Cassandra process is still running.We killed the node and restarted the node, and the above situation disappeared. Also the number of Active MemtableReclaimMemory threads seems to stay at 1. !image-2019-01-05-11-36-31-199.png! a large number of MutationStage stacks appeared at a certain moment. !image-2019-01-05-11-37-54-253.png! long GC time: !image-2019-01-05-11-38-21-711.png! Why is this happening? > Failed to reclaim the memory and too many MemtableReclaimMemory pending task > > > Key: CASSANDRA-14953 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14953 > Project: Cassandra > Issue Type: Bug > Components: Local/Memtable > Environment: version : cassandra 2.1.15 > jdk: 8 > os:suse >Reporter: HUANG DUICAN >Priority: Major > Attachments: cassandra_20190105.zip > > > We found that Cassandra has a lot of write accumulation in the production > environment, and our business has experienced a lot of write failures. > Through the system.log, it was found that MemtableReclaimMemory was pending > at the beginning, and then a large number of MutationStage stacks appeared at > a certain moment. > Finally, the heap memory is full, the GC time reaches tens of seconds, the > node status is DN through nodetool, but the Cassandra process is still > running.We killed the node and restarted the node, and the above situation > disappeared. > > Also the number of Active MemtableReclaimMemory threads seems to stay at 1. > > a large number of MutationStage stacks appeared at a certain moment. > long GC time: > > Why is this happening? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14953) Failed to reclaim the memory and too many MemtableReclaimMemory pending task
HUANG DUICAN created CASSANDRA-14953: Summary: Failed to reclaim the memory and too many MemtableReclaimMemory pending task Key: CASSANDRA-14953 URL: https://issues.apache.org/jira/browse/CASSANDRA-14953 Project: Cassandra Issue Type: Bug Components: Local/Memtable Environment: version : cassandra 2.1.15 jdk: 8 os:suse Reporter: HUANG DUICAN Attachments: cassandra_20190105.zip We found that Cassandra has a lot of write accumulation in the production environment, and our business has experienced a lot of write failures. Through the system.log, it was found that MemtableReclaimMemory was pending at the beginning, and then a large number of MutationStage stacks appeared at a certain moment. Finally, the heap memory is full, the GC time reaches tens of seconds, the node status is DN through nodetool, but the Cassandra process is still running.We killed the node and restarted the node, and the above situation disappeared. Also the number of Active MemtableReclaimMemory threads seems to stay at 1. !image-2019-01-05-11-23-23-752.png! a large number of MutationStage stacks appeared at a certain moment. !image-2019-01-05-11-26-56-546.png! long GC time: !image-2019-01-05-11-28-00-371.png! Why is this happening? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
svn commit: r1850447 - in /cassandra/site: publish/doc/3.11.3/ publish/doc/3.11.3/_images/ publish/doc/3.11.3/architecture/ publish/doc/3.11.3/configuration/ publish/doc/3.11.3/cql/ publish/doc/3.11.3
Author: mck Date: Fri Jan 4 23:10:28 2019 New Revision: 1850447 URL: http://svn.apache.org/viewvc?rev=1850447=rev Log: Publish versioned docs for Cassandra-3.11 (Cassandra-3.11.3) ref: https://wilderness.apache.org/channels/?f=cassandra-dev/2019-01-04#1546581372 [This commit notification would consist of 143 parts, which exceeds the limit of 50 ones, so it was shortened to the summary.] - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14952) NPE when using allocate_tokens_for_keyspace and add new DC
[
https://issues.apache.org/jira/browse/CASSANDRA-14952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaydeepkumar Chovatia updated CASSANDRA-14952:
--
Fix Version/s: 3.0.x
> NPE when using allocate_tokens_for_keyspace and add new DC
> --
>
> Key: CASSANDRA-14952
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14952
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Jaydeepkumar Chovatia
>Priority: Minor
> Fix For: 3.0.x
>
>
> Received following NPE while bootstrapping very first node in the new
> datacenter with {{allocate_tokens_for_keyspace}} yaml option
> {code:java}
> INFO 21:44:13 JOINING: getting bootstrap token
> Exception (java.lang.NullPointerException) encountered during startup: null
> java.lang.NullPointerException
> at
> org.apache.cassandra.dht.tokenallocator.TokenAllocation.getStrategy(TokenAllocation.java:208)
> at
> org.apache.cassandra.dht.tokenallocator.TokenAllocation.getStrategy(TokenAllocation.java:170)
> at
> org.apache.cassandra.dht.tokenallocator.TokenAllocation.allocateTokens(TokenAllocation.java:55)
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:206)
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:173)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:854)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:666)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:579)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:351)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:586)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:714)
> {code}
> Please find reproducible steps here:
> 1. Set {{allocate_tokens_for_keyspace}} property with
> {{Networktopologystrategy}} say Networktopologystrategy, 'dc1' : 1, 'dc2'
> : 1
> 2. Start first node in {{dc1}}
> 3. Now bootstrap second node in {{dc2,}} it will throw above exception.
> RCA:
>
> [doAddEndpoint|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/locator/TokenMetadata.java#L1325]
> is invoked from the
> [bootstrap|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/service/StorageService.java#L1254]
> and at this time [local node's rack
> information|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/locator/TokenMetadata.java#L1276]
> is available
> However with have {{allocate_tokens_for_keyspace}} option, daemon tries to
> access rack information even before calling
> [bootstrap|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/service/StorageService.java#L1241]
> function, at [this
> place|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/service/StorageService.java#L878]
> which results in NPE
> Fix:
> Since this is applicable to only very first node for new dc, we can check
> for {{null}} as:
> {code:java}
> diff --git
> a/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
> b/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
> index 8d8a6ffeca..e162757d95 100644
> --- a/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
> +++ b/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
> @@ -205,7 +205,11 @@ public class TokenAllocation
> final int replicas = rs.getReplicationFactor(dc);
>
> Topology topology = tokenMetadata.getTopology();
> -int racks = topology.getDatacenterRacks().get(dc).asMap().size();
> +int racks = 1;
> +if (topology.getDatacenterRacks().get(dc) != null)
> +{
> +racks = topology.getDatacenterRacks().get(dc).asMap().size();
> +}
>
> if (racks >= replicas)
> {
> {code}
> Let me know your comments.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14952) NPE when using allocate_tokens_for_keyspace and add new DC
Jaydeepkumar Chovatia created CASSANDRA-14952:
-
Summary: NPE when using allocate_tokens_for_keyspace and add new DC
Key: CASSANDRA-14952
URL: https://issues.apache.org/jira/browse/CASSANDRA-14952
Project: Cassandra
Issue Type: Bug
Components: Cluster/Gossip
Reporter: Jaydeepkumar Chovatia
Received following NPE while bootstrapping very first node in the new
datacenter with {{allocate_tokens_for_keyspace}} yaml option
{code:java}
INFO 21:44:13 JOINING: getting bootstrap token
Exception (java.lang.NullPointerException) encountered during startup: null
java.lang.NullPointerException
at
org.apache.cassandra.dht.tokenallocator.TokenAllocation.getStrategy(TokenAllocation.java:208)
at
org.apache.cassandra.dht.tokenallocator.TokenAllocation.getStrategy(TokenAllocation.java:170)
at
org.apache.cassandra.dht.tokenallocator.TokenAllocation.allocateTokens(TokenAllocation.java:55)
at
org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:206)
at
org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:173)
at
org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:854)
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:666)
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:579)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:351)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:586)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:714)
{code}
Please find reproducible steps here:
1. Set {{allocate_tokens_for_keyspace}} property with
{{Networktopologystrategy}} say Networktopologystrategy, 'dc1' : 1, 'dc2' :
1
2. Start first node in {{dc1}}
3. Now bootstrap second node in {{dc2,}} it will throw above exception.
RCA:
[doAddEndpoint|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/locator/TokenMetadata.java#L1325]
is invoked from the
[bootstrap|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/service/StorageService.java#L1254]
and at this time [local node's rack
information|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/locator/TokenMetadata.java#L1276]
is available
However with have {{allocate_tokens_for_keyspace}} option, daemon tries to
access rack information even before calling
[bootstrap|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/service/StorageService.java#L1241]
function, at [this
place|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/service/StorageService.java#L878]
which results in NPE
Fix:
Since this is applicable to only very first node for new dc, we can check for
{{null}} as:
{code:java}
diff --git
a/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
b/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
index 8d8a6ffeca..e162757d95 100644
--- a/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
+++ b/src/java/org/apache/cassandra/dht/tokenallocator/TokenAllocation.java
@@ -205,7 +205,11 @@ public class TokenAllocation
final int replicas = rs.getReplicationFactor(dc);
Topology topology = tokenMetadata.getTopology();
-int racks = topology.getDatacenterRacks().get(dc).asMap().size();
+int racks = 1;
+if (topology.getDatacenterRacks().get(dc) != null)
+{
+racks = topology.getDatacenterRacks().get(dc).asMap().size();
+}
if (racks >= replicas)
{
{code}
Let me know your comments.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Resolved] (CASSANDRA-14949) Fix documentation for default compressor used
[
https://issues.apache.org/jira/browse/CASSANDRA-14949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mck resolved CASSANDRA-14949.
-
Resolution: Fixed
Reviewer: Jon Haddad
Fix Version/s: (was: 4.0.x)
(was: 3.11.x)
4.0
3.11.4
Committed as
[9755e26075|https://github.com/apache/cassandra/commit/9755e26075a37703e76935437870dfa566f7d237]
> Fix documentation for default compressor used
> -
>
> Key: CASSANDRA-14949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14949
> Project: Cassandra
> Issue Type: Task
> Components: Documenation/Javadoc
>Reporter: mck
>Assignee: mck
>Priority: Trivial
> Fix For: 3.11.4, 4.0
>
>
> Fix documentation at
> [http://cassandra.apache.org/doc/4.0/operating/compression.html] to correct
> default compressor to {{LZ4Compressor}}. (And has been since Cassandra-2.0)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[2/3] cassandra git commit: Fix documentation for default compressor used
Fix documentation for default compressor used patch by Mick Semb Wever; reviewed by Jon Haddad for CASSANDRA-14949 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9755e260 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9755e260 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9755e260 Branch: refs/heads/trunk Commit: 9755e26075a37703e76935437870dfa566f7d237 Parents: 23cba99 Author: Mick Semb Wever Authored: Fri Jan 4 15:18:43 2019 +1100 Committer: Mick Semb Wever Committed: Sat Jan 5 08:39:27 2019 +1100 -- doc/source/operating/compression.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/9755e260/doc/source/operating/compression.rst -- diff --git a/doc/source/operating/compression.rst b/doc/source/operating/compression.rst index 5876214..01da34b 100644 --- a/doc/source/operating/compression.rst +++ b/doc/source/operating/compression.rst @@ -34,7 +34,7 @@ Compression is configured on a per-table basis as an optional argument to ``CREA default, three options are relevant: - ``class`` specifies the compression class - Cassandra provides three classes (``LZ4Compressor``, - ``SnappyCompressor``, and ``DeflateCompressor`` ). The default is ``SnappyCompressor``. + ``SnappyCompressor``, and ``DeflateCompressor`` ). The default is ``LZ4Compressor``. - ``chunk_length_in_kb`` specifies the number of kilobytes of data per compression chunk. The default is 64KB. - ``crc_check_chance`` determines how likely Cassandra is to verify the checksum on each compression chunk during reads. The default is 1.0. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[3/3] cassandra git commit: Merge branch 'cassandra-3.11' into trunk
Merge branch 'cassandra-3.11' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/973e72b0 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/973e72b0 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/973e72b0 Branch: refs/heads/trunk Commit: 973e72b0c9a661f09d3348ed083f21b03ad2a130 Parents: e027e45 9755e26 Author: Mick Semb Wever Authored: Sat Jan 5 08:40:34 2019 +1100 Committer: Mick Semb Wever Committed: Sat Jan 5 08:41:15 2019 +1100 -- doc/source/operating/compression.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[1/3] cassandra git commit: Fix documentation for default compressor used
Repository: cassandra Updated Branches: refs/heads/cassandra-3.11 23cba991c -> 9755e2607 refs/heads/trunk e027e4569 -> 973e72b0c Fix documentation for default compressor used patch by Mick Semb Wever; reviewed by Jon Haddad for CASSANDRA-14949 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9755e260 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9755e260 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9755e260 Branch: refs/heads/cassandra-3.11 Commit: 9755e26075a37703e76935437870dfa566f7d237 Parents: 23cba99 Author: Mick Semb Wever Authored: Fri Jan 4 15:18:43 2019 +1100 Committer: Mick Semb Wever Committed: Sat Jan 5 08:39:27 2019 +1100 -- doc/source/operating/compression.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/9755e260/doc/source/operating/compression.rst -- diff --git a/doc/source/operating/compression.rst b/doc/source/operating/compression.rst index 5876214..01da34b 100644 --- a/doc/source/operating/compression.rst +++ b/doc/source/operating/compression.rst @@ -34,7 +34,7 @@ Compression is configured on a per-table basis as an optional argument to ``CREA default, three options are relevant: - ``class`` specifies the compression class - Cassandra provides three classes (``LZ4Compressor``, - ``SnappyCompressor``, and ``DeflateCompressor`` ). The default is ``SnappyCompressor``. + ``SnappyCompressor``, and ``DeflateCompressor`` ). The default is ``LZ4Compressor``. - ``chunk_length_in_kb`` specifies the number of kilobytes of data per compression chunk. The default is 64KB. - ``crc_check_chance`` determines how likely Cassandra is to verify the checksum on each compression chunk during reads. The default is 1.0. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14950) Update link to mx4j in cassandra-env.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-14950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jearvon Dharrie updated CASSANDRA-14950: Attachment: 0001-Update-mx4j-url.patch Status: Patch Available (was: Open) > Update link to mx4j in cassandra-env.sh > --- > > Key: CASSANDRA-14950 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14950 > Project: Cassandra > Issue Type: Task >Reporter: Jearvon Dharrie >Priority: Trivial > Attachments: 0001-Update-mx4j-url.patch > > > Seems this > [http://wiki.apache.org/cassandra/Operations#Monitoring_with_MX4J] > has moved to http://cassandra.apache.org/doc/latest/operating/metrics.html#jmx > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14951) Reenable CQLSH tests
Dinesh Joshi created CASSANDRA-14951: Summary: Reenable CQLSH tests Key: CASSANDRA-14951 URL: https://issues.apache.org/jira/browse/CASSANDRA-14951 Project: Cassandra Issue Type: Bug Components: Tool/cqlsh Reporter: Dinesh Joshi Assignee: Dinesh Joshi Some CQLSH tests have not been running. They need to be reenabled and fixed before 4.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14950) Update link to mx4j in cassandra-env.sh
Jearvon Dharrie created CASSANDRA-14950: --- Summary: Update link to mx4j in cassandra-env.sh Key: CASSANDRA-14950 URL: https://issues.apache.org/jira/browse/CASSANDRA-14950 Project: Cassandra Issue Type: Task Reporter: Jearvon Dharrie Seems this [http://wiki.apache.org/cassandra/Operations#Monitoring_with_MX4J] has moved to http://cassandra.apache.org/doc/latest/operating/metrics.html#jmx -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14476) ShortType and ByteType are incorrectly considered variable-length types
[ https://issues.apache.org/jira/browse/CASSANDRA-14476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734485#comment-16734485 ] Jearvon Dharrie commented on CASSANDRA-14476: - If this is still needed I would like to work on it. Can it be assigned to me please? Thanks! > ShortType and ByteType are incorrectly considered variable-length types > --- > > Key: CASSANDRA-14476 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14476 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Vladimir Krivopalov >Priority: Minor > Labels: lhf > > The AbstractType class has a method valueLengthIfFixed() that returns -1 for > data types with a variable length and a positive value for types with a fixed > length. This is primarily used for efficient serialization and > deserialization. > > It turns out that there is an inconsistency in types ShortType and ByteType > as those are in fact fixed-length types (2 bytes and 1 byte, respectively) > but they don't have the valueLengthIfFixed() method overloaded and it returns > -1 as if they were of variable length. > > It would be good to fix that at some appropriate point, for example, when > introducing a new version of SSTables format, to keep the meaning of the > function consistent across data types. Saving some bytes in serialized format > is a minor but pleasant bonus. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14949) Fix documentation for default compressor used
[
https://issues.apache.org/jira/browse/CASSANDRA-14949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734364#comment-16734364
]
Jon Haddad commented on CASSANDRA-14949:
LGTM, +1
> Fix documentation for default compressor used
> -
>
> Key: CASSANDRA-14949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14949
> Project: Cassandra
> Issue Type: Task
> Components: Documenation/Javadoc
>Reporter: mck
>Assignee: mck
>Priority: Trivial
> Fix For: 3.11.x, 4.0.x
>
>
> Fix documentation at
> [http://cassandra.apache.org/doc/4.0/operating/compression.html] to correct
> default compressor to {{LZ4Compressor}}. (And has been since Cassandra-2.0)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13692) CompactionAwareWriter_getWriteDirectory throws incompatible exceptions
[
https://issues.apache.org/jira/browse/CASSANDRA-13692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734130#comment-16734130
]
Dimitar Dimitrov commented on CASSANDRA-13692:
--
I have reworked the changes as discussed, and am currently testing.
Initial unit test results are relatively good - 3.0 and 3.11 seem OK (no
failures), and trunk seems to have a bunch of unrelated failures (e.g.
{{SingleSSTableLCSTaskTest}} failing with an OOME,
{{org.apache.cassandra.dht.tokenallocator}} tests failing with a NPE in
{{DatabaseDescriptor.diagnosticEventsEnabled}}). 2.2 has some failures in
{{ScrubTest}} and {{SSTableRewriterTest}} that I'd like to take a closer look
at.
I still don't have initial results for dtests, due to these being harder to
land on a CI VM, and longer to run. I'll update when I have something to report
though.
Here are the draft changes, in case anyone is interested:
|
[2.2|https://github.com/apache/cassandra/compare/cassandra-2.2...dimitarndimitrov:c13692-2.2]
|
|
[3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...dimitarndimitrov:c13692-3.0]
|
|
[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...dimitarndimitrov:c13692-3.11]
|
|
[trunk|https://github.com/apache/cassandra/compare/trunk...dimitarndimitrov:c13692]
|
> CompactionAwareWriter_getWriteDirectory throws incompatible exceptions
> --
>
> Key: CASSANDRA-13692
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13692
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction
>Reporter: Hao Zhong
>Assignee: Dimitar Dimitrov
>Priority: Major
> Labels: lhf
> Attachments: c13692-2.2-dtest-results.PNG,
> c13692-2.2-testall-results.PNG, c13692-3.0-dtest-results-updated.PNG,
> c13692-3.0-dtest-results.PNG, c13692-3.0-testall-results.PNG,
> c13692-3.11-dtest-results-updated.PNG, c13692-3.11-dtest-results.PNG,
> c13692-3.11-testall-results.PNG, c13692-dtest-results-updated.PNG,
> c13692-dtest-results.PNG, c13692-testall-results-updated.PNG,
> c13692-testall-results.PNG
>
>
> The CompactionAwareWriter_getWriteDirectory throws RuntimeException:
> {code}
> public Directories.DataDirectory getWriteDirectory(Iterable
> sstables, long estimatedWriteSize)
> {
> File directory = null;
> for (SSTableReader sstable : sstables)
> {
> if (directory == null)
> directory = sstable.descriptor.directory;
> if (!directory.equals(sstable.descriptor.directory))
> {
> logger.trace("All sstables not from the same disk - putting
> results in {}", directory);
> break;
> }
> }
> Directories.DataDirectory d =
> getDirectories().getDataDirectoryForFile(directory);
> if (d != null)
> {
> long availableSpace = d.getAvailableSpace();
> if (availableSpace < estimatedWriteSize)
> throw new RuntimeException(String.format("Not enough space to
> write %s to %s (%s available)",
>
> FBUtilities.prettyPrintMemory(estimatedWriteSize),
> d.location,
>
> FBUtilities.prettyPrintMemory(availableSpace)));
> logger.trace("putting compaction results in {}", directory);
> return d;
> }
> d = getDirectories().getWriteableLocation(estimatedWriteSize);
> if (d == null)
> throw new RuntimeException(String.format("Not enough disk space
> to store %s",
>
> FBUtilities.prettyPrintMemory(estimatedWriteSize)));
> return d;
> }
> {code}
> However, the thrown exception does not trigger the failure policy.
> CASSANDRA-11448 fixed a similar problem. The buggy code is:
> {code}
> protected Directories.DataDirectory getWriteDirectory(long writeSize)
> {
> Directories.DataDirectory directory =
> getDirectories().getWriteableLocation(writeSize);
> if (directory == null)
> throw new RuntimeException("Insufficient disk space to write " +
> writeSize + " bytes");
> return directory;
> }
> {code}
> The fixed code is:
> {code}
> protected Directories.DataDirectory getWriteDirectory(long writeSize)
> {
> Directories.DataDirectory directory =
> getDirectories().getWriteableLocation(writeSize);
> if (directory == null)
> throw new FSWriteError(new IOException("Insufficient disk space
> to write " + writeSize + " bytes"), "");
> return directory;
> }
> {code}
> The fixed code throws FSWE and triggers the
