[jira] [Commented] (CASSANDRA-14451) Infinity ms Commit Log Sync
[
https://issues.apache.org/jira/browse/CASSANDRA-14451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16499266#comment-16499266
]
Jason Brown commented on CASSANDRA-14451:
-
[~aby786] I would highly doubt the logging thing would cause your memory
problems. You should probably open a separate ticket and describe all the
symptoms you are seeing, with as much detail as possible.
> Infinity ms Commit Log Sync
> ---
>
> Key: CASSANDRA-14451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14451
> Project: Cassandra
> Issue Type: Bug
> Environment: 3.11.2 - 2 DC
>Reporter: Harry Hough
>Assignee: Jason Brown
>Priority: Minor
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> Its giving commit log sync warnings where there were apparently zero syncs
> and therefore gives "Infinityms" as the average duration
> {code:java}
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2018-05-16 21:11:14,294
> NoSpamLogger.java:94 - Out of 0 commit log syncs over the past 0.00s with
> average duration of Infinityms, 1 have exceeded the configured commit
> interval by an average of 74.40ms
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2018-05-16 21:16:57,844
> NoSpamLogger.java:94 - Out of 0 commit log syncs over the past 0.00s with
> average duration of Infinityms, 1 have exceeded the configured commit
> interval by an average of 198.69ms
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2018-05-16 21:24:46,325
> NoSpamLogger.java:94 - Out of 0 commit log syncs over the past 0.00s with
> average duration of Infinityms, 1 have exceeded the configured commit
> interval by an average of 264.11ms
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2018-05-16 21:29:46,393
> NoSpamLogger.java:94 - Out of 32 commit log syncs over the past 268.84s with,
> average duration of 17.56ms, 1 have exceeded the configured commit interval
> by an average of 173.66ms{code}
--
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-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16499263#comment-16499263 ] Patrick Bannister commented on CASSANDRA-10190: --- I added several subtasks to this ticket for testing of the areas that were not covered according to my coverage report. (Refuting the coverage report by identifying an existing test for the supposedly uncovered features would be superior to writing a new test.) > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement >Reporter: Andrew Pennebaker >Priority: Major > Labels: cqlsh > Attachments: coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- 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-14493) Test describe statements for aggregates, functions, indexes, schemas, types, and user types
Patrick Bannister created CASSANDRA-14493: - Summary: Test describe statements for aggregates, functions, indexes, schemas, types, and user types Key: CASSANDRA-14493 URL: https://issues.apache.org/jira/browse/CASSANDRA-14493 Project: Cassandra Issue Type: Sub-task Reporter: Patrick Bannister Fix For: 4.x Coverage analysis of the cqlsh unittests (pylib/cqlshlib/test/test*.py) and the dtest cqlsh_tests (cqlsh_tests.py and cqlsh_copy_tests.py) showed no coverage of functions for describing aggregates, functions, indexes, schemas, types, or usertypes. Before we can release a ported cqlsh, we should either create a new test that exercises these kinds of describe statements, or refute the coverage report by identifying an existing test for these features. -- 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-14492) Test use of thousands separators and comma decimal separators
Patrick Bannister created CASSANDRA-14492:
-
Summary: Test use of thousands separators and comma decimal
separators
Key: CASSANDRA-14492
URL: https://issues.apache.org/jira/browse/CASSANDRA-14492
Project: Cassandra
Issue Type: Sub-task
Reporter: Patrick Bannister
Fix For: 4.x
Coverage analysis showed no coverage for functions related to displaying
numbers with thousands separators ("$100,000,000,000" instead of
"$1000") and displaying numbers with custom decimal separators
("3,1415927" instead of "3.1415927").
We should add a test that displays numbers like this, or identify an existing
test that does it.
--
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-14491) Determine how to test cqlsh in a Python 2.7 environment, including dtests
Patrick Bannister created CASSANDRA-14491: - Summary: Determine how to test cqlsh in a Python 2.7 environment, including dtests Key: CASSANDRA-14491 URL: https://issues.apache.org/jira/browse/CASSANDRA-14491 Project: Cassandra Issue Type: Sub-task Environment: We need to test with at least two versions of Python: * Python 2.7 * Python 3.x (need to determine what versions of Python 3 are available by default on Ubuntu and RHEL/CentOS) Additionally, it is recommended to test on at least three platforms: * Ubuntu or other Debian derivative * RHEL, CentOS, or other Red Hat derivative * Windows (unless a consensus has formed around not testing on Windows?) Reporter: Patrick Bannister Fix For: 4.x It appears that a consensus is forming around maintaining Python 2.7 compatibility for cqlsh. However, the dtests now run in a Python 3 environment. We need to identify an option for testing infrastructure for testing cqlsh on Python 2.7, including the dtests. Based on experience updating the cqlsh dtests, it is strongly recommended to test in more than one environment - for example, for Linux, we should test on a Debian derivative as well as a Red Hat derivative. -- 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-14490) Test displaying CJK languages
Patrick Bannister created CASSANDRA-14490: - Summary: Test displaying CJK languages Key: CASSANDRA-14490 URL: https://issues.apache.org/jira/browse/CASSANDRA-14490 Project: Cassandra Issue Type: Sub-task Reporter: Patrick Bannister Fix For: 4.0.x Coverage analysis of cqlsh tests showed no coverage of wcwidth functions related to displaying CJK languages. Before releasing a port, we should identify or create a test that exercises code paths for displaying CJK language data in cqlsh. -- 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-14489) Test cqlsh authentication
Patrick Bannister created CASSANDRA-14489: - Summary: Test cqlsh authentication Key: CASSANDRA-14489 URL: https://issues.apache.org/jira/browse/CASSANDRA-14489 Project: Cassandra Issue Type: Sub-task Reporter: Patrick Bannister Fix For: 4.x Coverage analysis of the cqlshlib unittests (pylib/cqlshlib/test/test*.py) and the dtest cqlsh_tests (cqlsh_tests.py and cqlsh_copy_tests.py) showed no coverage of authentication related code. Before we can release a port of cqlsh, we should identify an existing test for cqlsh authentication, or write a new one. -- 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-14451) Infinity ms Commit Log Sync
[
https://issues.apache.org/jira/browse/CASSANDRA-14451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16499232#comment-16499232
]
Abdul Patel commented on CASSANDRA-14451:
-
Can this cause Memory usage to go high ?
after 3.11.2 upgrade i am getting high memory usage alerts and nothing in
errorlog sometime , but sometime i see same PERIODIC-COMMIT-LOG-SYNCER message
> Infinity ms Commit Log Sync
> ---
>
> Key: CASSANDRA-14451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14451
> Project: Cassandra
> Issue Type: Bug
> Environment: 3.11.2 - 2 DC
>Reporter: Harry Hough
>Assignee: Jason Brown
>Priority: Minor
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> Its giving commit log sync warnings where there were apparently zero syncs
> and therefore gives "Infinityms" as the average duration
> {code:java}
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2018-05-16 21:11:14,294
> NoSpamLogger.java:94 - Out of 0 commit log syncs over the past 0.00s with
> average duration of Infinityms, 1 have exceeded the configured commit
> interval by an average of 74.40ms
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2018-05-16 21:16:57,844
> NoSpamLogger.java:94 - Out of 0 commit log syncs over the past 0.00s with
> average duration of Infinityms, 1 have exceeded the configured commit
> interval by an average of 198.69ms
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2018-05-16 21:24:46,325
> NoSpamLogger.java:94 - Out of 0 commit log syncs over the past 0.00s with
> average duration of Infinityms, 1 have exceeded the configured commit
> interval by an average of 264.11ms
> WARN [PERIODIC-COMMIT-LOG-SYNCER] 2018-05-16 21:29:46,393
> NoSpamLogger.java:94 - Out of 32 commit log syncs over the past 268.84s with,
> average duration of 17.56ms, 1 have exceeded the configured commit interval
> by an average of 173.66ms{code}
--
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-14466) Enable Direct I/O
[ https://issues.apache.org/jira/browse/CASSANDRA-14466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16499103#comment-16499103 ] Ariel Weisberg commented on CASSANDRA-14466: I have to rethink a bit since we now have an in-process cache. I'm not sure if we use it in only the compressed case or for both compressed and mmaped files. > Enable Direct I/O > -- > > Key: CASSANDRA-14466 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14466 > Project: Cassandra > Issue Type: New Feature > Components: Local Write-Read Paths >Reporter: Mulugeta Mammo >Priority: Major > Attachments: direct_io.patch > > > Hi, > JDK 10 introduced a new API for Direct IO that enables applications to bypass > the file system cache and potentially improve performance. Details of this > feature can be found at [https://bugs.openjdk.java.net/browse/JDK-8164900]. > This patch uses the JDK 10 API to enable Direct IO for the Cassandra read > path. By default, we have disabled this feature; but it can be enabled using > a new configuration parameter, enable_direct_io_for_read_path. We have > conducted a Cassandra read-only stress test and measured a throughput gain of > up to 60% on flash drives. > The patch requires JDK 10 Cassandra Support - > https://issues.apache.org/jira/browse/CASSANDRA-9608 > Please review the patch and let us know your feedback. > Thanks, > [^direct_io.patch] > -- 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-14466) Enable Direct I/O
[ https://issues.apache.org/jira/browse/CASSANDRA-14466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16499100#comment-16499100 ] Ariel Weisberg commented on CASSANDRA-14466: Can we try something slightly different? What happens if you run without O_DIRECT, but with read ahead set to 0 and the compressed chunk length set to 4kb, 8kb, and 16kb? I think to really pass judgement on adding this feature we would need to do a more apples to apples comparison. Can you also provide the exact cassandra-stress invocation you used? Was it using a uniform distribution or a cacheable distribution? > Enable Direct I/O > -- > > Key: CASSANDRA-14466 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14466 > Project: Cassandra > Issue Type: New Feature > Components: Local Write-Read Paths >Reporter: Mulugeta Mammo >Priority: Major > Attachments: direct_io.patch > > > Hi, > JDK 10 introduced a new API for Direct IO that enables applications to bypass > the file system cache and potentially improve performance. Details of this > feature can be found at [https://bugs.openjdk.java.net/browse/JDK-8164900]. > This patch uses the JDK 10 API to enable Direct IO for the Cassandra read > path. By default, we have disabled this feature; but it can be enabled using > a new configuration parameter, enable_direct_io_for_read_path. We have > conducted a Cassandra read-only stress test and measured a throughput gain of > up to 60% on flash drives. > The patch requires JDK 10 Cassandra Support - > https://issues.apache.org/jira/browse/CASSANDRA-9608 > Please review the patch and let us know your feedback. > Thanks, > [^direct_io.patch] > -- 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-14466) Enable Direct I/O
[ https://issues.apache.org/jira/browse/CASSANDRA-14466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16499096#comment-16499096 ] Jon Haddad commented on CASSANDRA-14466: Interesting idea. I've seen the issue you've described many times on read heavy systems (high CPU due to page cache churn) One thing I've noticed however, is that I've been able to get an order of magnitude improvement on these systems by using a 4KB chunk lengh + disable read ahead completely. The problem wasn't so much the page cache, but read amplification. What I typically see is read heavy workloads tend to rely on very small reads - a handful of rows. A 64kb chunk + a readahead of 256 = a LOT of cache churn. I'm wondering how direct i/o would compare to a correctly tuned system. I see datastax recommends readahead of 8, I'm not sure what setting you used in your benchmark. Since direct i/o avoids readahead it's probably better to do an apples to apples comparison with it disabled completely. Adding readahead on top of fetching data out of a single disk block for a small request wastes a lot of i/o and you might be unfairly crippling baseline Cassandra by using it. All of that said - with a read heavy workload randomly distributed over a dataset as large as you've described, it's very unlikely you'd get a cache hit so I can see how this might be a better approach overall. How it works for other workloads or non-SSD is a different matter that we'd need to benchmark as well. > Enable Direct I/O > -- > > Key: CASSANDRA-14466 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14466 > Project: Cassandra > Issue Type: New Feature > Components: Local Write-Read Paths >Reporter: Mulugeta Mammo >Priority: Major > Attachments: direct_io.patch > > > Hi, > JDK 10 introduced a new API for Direct IO that enables applications to bypass > the file system cache and potentially improve performance. Details of this > feature can be found at [https://bugs.openjdk.java.net/browse/JDK-8164900]. > This patch uses the JDK 10 API to enable Direct IO for the Cassandra read > path. By default, we have disabled this feature; but it can be enabled using > a new configuration parameter, enable_direct_io_for_read_path. We have > conducted a Cassandra read-only stress test and measured a throughput gain of > up to 60% on flash drives. > The patch requires JDK 10 Cassandra Support - > https://issues.apache.org/jira/browse/CASSANDRA-9608 > Please review the patch and let us know your feedback. > Thanks, > [^direct_io.patch] > -- 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] [Comment Edited] (CASSANDRA-14464) stop-server.bat -p ../pid.txt -f command not working on windows 2016
[
https://issues.apache.org/jira/browse/CASSANDRA-14464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16499077#comment-16499077
]
Joshua McKenzie edited comment on CASSANDRA-14464 at 6/2/18 1:57 PM:
-
When you run with -f, you're getting a simple:
{quote}taskkill /f /pid $pidToKill
{quote}
So seems like there's something odd happening on your system if it's restarting
cassandra after being force-killed by the OS. So first off, I'd recommend not
running with /f since that's basically forcing a hard stop of the DB w/out
letting it shutdown gracefully.
To give some context here on the surprising complexity of C* shutdown on
windows: this code was written in July of 2014, and [does the
following|https://github.com/apache/cassandra/blob/cassandra-3.11/bin/stop-server.ps1#L75-L95])
:
# A .bat file calls
# A powershell file which
# Contains a C# program it interprets on the fly
([PowerStopper.Stopper|https://github.com/apache/cassandra/blob/cassandra-3.11/bin/stop-server.ps1#L69-L71])
which
# Uses pinvoke to use [native
calls|https://github.com/apache/cassandra/blob/cassandra-3.11/bin/stop-server.ps1#L120-L140]
to attach to the console and send a ctrl+C to kill it and let the C*/JVM
signal handlers terminate the application
The TL;DR here: it's kind of a small miracle it worked in the first place
(Windows signal handling very very very much != *nix), and if your two OS
environments are respawning a process that terminated itself due to receiving a
SIGINT and shutting down, there's not much we can do from a runtime script
perspective to stop it.
That being said, I tested the functionality of this on server 2012 back when I
wrote it and it worked fine on a few different environments and used it for dev
purposes daily for a couple years after that on Win10 and Server 2012 without
ever having an issue with it.
The new pid that gets spawned is another java process running C*? If you run
process explorer, what parent process owns that new pid? Is it owned by the
original cassandra.bat that you were running things from? Is it running as a
service under svchost?
was (Author: joshuamckenzie):
When you run with -f, you're getting a simple:
{quote}taskkill /f /pid $pidToKill
{quote}
So seems like there's something odd happening on your system if it's restarting
cassandra after being force-killed by the OS. So first off, I'd recommend not
running with /f since that's basically forcing a hard stop of the DB w/out
letting it shutdown gracefully.
To give some context here on the surprising complexity of C* shutdown on
windows: this code was written in July of 2014, and [does the
following|https://github.com/apache/cassandra/blob/cassandra-3.11/bin/stop-server.ps1#L75-L95])
:
# A .bat file calls
# A powershell file which
# Contains a C# program it interprets on the fly
([PowerStopper.Stopper|https://github.com/apache/cassandra/blob/cassandra-3.11/bin/stop-server.ps1#L69-L71])
which
# Uses pinvoke to use [native
calls|https://github.com/apache/cassandra/blob/cassandra-3.11/bin/stop-server.ps1#L120-L140]
to attach to the console and send a ctrl+C to kill it and let the C*/JVM
signal handlers terminate the application
The TL;DR here: it's kind of a small miracle it worked in the first place
(Windows signal handling very very very much != *nix), and if your two OS
environments are respawning a process that terminated itself due to receiving a
SIGINT and shutting down, there's not much we can do from a runtime script
perspective to stop it.
That being said, I tested the functionality of this on server 2012 back when I
wrote it and it worked fine on a few different environments and used it for dev
purposes daily for a couple years after that on Win10 and Server 2012 for a
couple years after that without ever having an issue with it.
The new pid that gets spawned is another java process running C*? If you run
process explorer, what parent process owns that new pid? Is it owned by the
original cassandra.bat that you were running things from? Is it running as a
service under svchost?
> stop-server.bat -p ../pid.txt -f command not working on windows 2016
>
>
> Key: CASSANDRA-14464
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14464
> Project: Cassandra
> Issue Type: Bug
>Reporter: Shyam Phirke
>Priority: Critical
>
> Steps to reproduce:
> 1. Copy and extract cassandra binaries on windows 2016 machine
> 2. Start cassandra in non-legacy mode
> 3. Check pid of cassandra in task manager and compare it with in pid.txt
> 4. Now stop cassandra using command stop-server.bat -p ../pid.txt -f
> Expected:
> After executing \bin:\> stop-server.bat -p
> ../pid.txt -f
> cassandra process as in pid.txt should get killed.
>
>
[jira] [Comment Edited] (CASSANDRA-14464) stop-server.bat -p ../pid.txt -f command not working on windows 2016
[
https://issues.apache.org/jira/browse/CASSANDRA-14464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16499077#comment-16499077
]
Joshua McKenzie edited comment on CASSANDRA-14464 at 6/2/18 1:56 PM:
-
When you run with -f, you're getting a simple:
{quote}taskkill /f /pid $pidToKill
{quote}
So seems like there's something odd happening on your system if it's restarting
cassandra after being force-killed by the OS. So first off, I'd recommend not
running with /f since that's basically forcing a hard stop of the DB w/out
letting it shutdown gracefully.
To give some context here on the surprising complexity of C* shutdown on
windows: this code was written in July of 2014, and [does the
following|https://github.com/apache/cassandra/blob/cassandra-3.11/bin/stop-server.ps1#L75-L95])
:
# A .bat file calls
# A powershell file which
# Contains a C# program it interprets on the fly
([PowerStopper.Stopper|https://github.com/apache/cassandra/blob/cassandra-3.11/bin/stop-server.ps1#L69-L71])
which
# Uses pinvoke to use [native
calls|https://github.com/apache/cassandra/blob/cassandra-3.11/bin/stop-server.ps1#L120-L140]
to attach to the console and send a ctrl+C to kill it and let the C*/JVM
signal handlers terminate the application
The TL;DR here: it's kind of a small miracle it worked in the first place
(Windows signal handling very very very much != *nix), and if your two OS
environments are respawning a process that terminated itself due to receiving a
SIGINT and shutting down, there's not much we can do from a runtime script
perspective to stop it.
That being said, I tested the functionality of this on server 2012 back when I
wrote it and it worked fine on a few different environments and used it for dev
purposes daily for a couple years after that on Win10 and Server 2012 for a
couple years after that without ever having an issue with it.
The new pid that gets spawned is another java process running C*? If you run
process explorer, what parent process owns that new pid? Is it owned by the
original cassandra.bat that you were running things from? Is it running as a
service under svchost?
was (Author: joshuamckenzie):
When you run with -f, you're getting a simple:
{quote}taskkill /f /pid $pidToKill
{quote}
So seems like there's something odd happening on your system if it's restarting
cassandra after being force-killed by the OS. So first off, I'd recommend not
running with /f since that's basically forcing a hard stop of the DB w/out
letting it shutdown gracefully.
To give some context here on the surprising complexity of C* shutdown on
windows: this code was written in July of 2014, and [does the
following|[https://github.com/apache/cassandra/blob/cassandra-3.11/bin/stop-server.ps1#L75-L95]])
:
# A .bat file calls
# A powershell file which
# Contains a C# program it interprets on the fly
([PowerStopper.Stopper|https://github.com/apache/cassandra/blob/cassandra-3.11/bin/stop-server.ps1#L69-L71])
which
# Uses pinvoke to use [native
calls|https://github.com/apache/cassandra/blob/cassandra-3.11/bin/stop-server.ps1#L120-L140]
to attach to the console and send a ctrl+C to kill it and let the C*/JVM
signal handlers terminate the application
The TL;DR here: it's kind of a small miracle it worked in the first place
(Windows signal handling very very very much != *nix), and if your two OS
environments are respawning a process that terminated itself due to receiving a
SIGINT and shutting down, there's not much we can do from a runtime script
perspective to stop it.
That being said, I tested the functionality of this on server 2012 back when I
wrote it and it worked fine on a few different environments and used it for dev
purposes daily for a couple years after that on Win10 and Server 2012 for a
couple years after that without ever having an issue with it.
The new pid that gets spawned is another java process running C*? If you run
process explorer, what parent process owns that new pid? Is it owned by the
original cassandra.bat that you were running things from? Is it running as a
service under svchost?
> stop-server.bat -p ../pid.txt -f command not working on windows 2016
>
>
> Key: CASSANDRA-14464
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14464
> Project: Cassandra
> Issue Type: Bug
>Reporter: Shyam Phirke
>Priority: Critical
>
> Steps to reproduce:
> 1. Copy and extract cassandra binaries on windows 2016 machine
> 2. Start cassandra in non-legacy mode
> 3. Check pid of cassandra in task manager and compare it with in pid.txt
> 4. Now stop cassandra using command stop-server.bat -p ../pid.txt -f
> Expected:
> After executing \bin:\> stop-server.bat -p
> ../pid.txt -f
> cassandra process as in
[jira] [Comment Edited] (CASSANDRA-14464) stop-server.bat -p ../pid.txt -f command not working on windows 2016
[
https://issues.apache.org/jira/browse/CASSANDRA-14464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16499077#comment-16499077
]
Joshua McKenzie edited comment on CASSANDRA-14464 at 6/2/18 1:55 PM:
-
When you run with -f, you're getting a simple:
{quote}taskkill /f /pid $pidToKill
{quote}
So seems like there's something odd happening on your system if it's restarting
cassandra after being force-killed by the OS. So first off, I'd recommend not
running with /f since that's basically forcing a hard stop of the DB w/out
letting it shutdown gracefully.
To give some context here on the surprising complexity of C* shutdown on
windows: this code was written in July of 2014, and [does the
following|[https://github.com/apache/cassandra/blob/cassandra-3.11/bin/stop-server.ps1#L75-L95]])
:
# A .bat file calls
# A powershell file which
# Contains a C# program it interprets on the fly
([PowerStopper.Stopper|https://github.com/apache/cassandra/blob/cassandra-3.11/bin/stop-server.ps1#L69-L71])
which
# Uses pinvoke to use [native
calls|https://github.com/apache/cassandra/blob/cassandra-3.11/bin/stop-server.ps1#L120-L140]
to attach to the console and send a ctrl+C to kill it and let the C*/JVM
signal handlers terminate the application
The TL;DR here: it's kind of a small miracle it worked in the first place
(Windows signal handling very very very much != *nix), and if your two OS
environments are respawning a process that terminated itself due to receiving a
SIGINT and shutting down, there's not much we can do from a runtime script
perspective to stop it.
That being said, I tested the functionality of this on server 2012 back when I
wrote it and it worked fine on a few different environments and used it for dev
purposes daily for a couple years after that on Win10 and Server 2012 for a
couple years after that without ever having an issue with it.
The new pid that gets spawned is another java process running C*? If you run
process explorer, what parent process owns that new pid? Is it owned by the
original cassandra.bat that you were running things from? Is it running as a
service under svchost?
was (Author: joshuamckenzie):
When you run with -f, you're getting a simple:
{quote}taskkill /f /pid $pidToKill{quote}
So seems like there's something odd happening on your system if it's restarting
cassandra after being force-killed by the OS. So first off, I'd recommend not
running with /f since that's basically forcing a hard stop of the DB w/out
letting it shutdown gracefully.
To give some context here on the surprising complexity of C* shutdown on
windows: this code was written in July of 2014, and [does the
following|[https://github.com/apache/cassandra/blob/cassandra-3.11/bin/stop-server.ps1#L75-L95]|https://github.com/apache/cassandra/blob/cassandra-3.11/bin/stop-server.ps1#L75-L95]:])
:
# A .bat file calls
# A powershell file which
# Contains a C# program it interprets on the fly
([PowerStopper.Stopper|https://github.com/apache/cassandra/blob/cassandra-3.11/bin/stop-server.ps1#L69-L71])
which
# Uses pinvoke to use [native
calls|https://github.com/apache/cassandra/blob/cassandra-3.11/bin/stop-server.ps1#L120-L140]
to attach to the console and send a ctrl+C to kill it and let the C*/JVM
signal handlers terminate the application
The TL;DR here: it's kind of a small miracle it worked in the first place
(Windows signal handling very very very much != *nix), and if your two OS
environments are respawning a process that terminated itself due to receiving a
SIGINT and shutting down, there's not much we can do from a runtime script
perspective to stop it.
That being said, I tested the functionality of this on server 2012 back when I
wrote it and it worked fine on a few different environments and used it for dev
purposes daily for a couple years after that on Win10 and Server 2012 for a
couple years after that without ever having an issue with it.
The new pid that gets spawned is another java process running C*? If you run
process explorer, what parent process owns that new pid? Is it owned by the
original cassandra.bat that you were running things from? Is it running as a
service under svchost?
> stop-server.bat -p ../pid.txt -f command not working on windows 2016
>
>
> Key: CASSANDRA-14464
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14464
> Project: Cassandra
> Issue Type: Bug
>Reporter: Shyam Phirke
>Priority: Critical
>
> Steps to reproduce:
> 1. Copy and extract cassandra binaries on windows 2016 machine
> 2. Start cassandra in non-legacy mode
> 3. Check pid of cassandra in task manager and compare it with in pid.txt
> 4. Now stop cassandra using command stop-server.bat -p ../pid.txt -f
> Expected:
>
[jira] [Commented] (CASSANDRA-14464) stop-server.bat -p ../pid.txt -f command not working on windows 2016
[
https://issues.apache.org/jira/browse/CASSANDRA-14464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16499077#comment-16499077
]
Joshua McKenzie commented on CASSANDRA-14464:
-
When you run with -f, you're getting a simple:
{quote}taskkill /f /pid $pidToKill{quote}
So seems like there's something odd happening on your system if it's restarting
cassandra after being force-killed by the OS. So first off, I'd recommend not
running with /f since that's basically forcing a hard stop of the DB w/out
letting it shutdown gracefully.
To give some context here on the surprising complexity of C* shutdown on
windows: this code was written in July of 2014, and [does the
following|[https://github.com/apache/cassandra/blob/cassandra-3.11/bin/stop-server.ps1#L75-L95]|https://github.com/apache/cassandra/blob/cassandra-3.11/bin/stop-server.ps1#L75-L95]:])
:
# A .bat file calls
# A powershell file which
# Contains a C# program it interprets on the fly
([PowerStopper.Stopper|https://github.com/apache/cassandra/blob/cassandra-3.11/bin/stop-server.ps1#L69-L71])
which
# Uses pinvoke to use [native
calls|https://github.com/apache/cassandra/blob/cassandra-3.11/bin/stop-server.ps1#L120-L140]
to attach to the console and send a ctrl+C to kill it and let the C*/JVM
signal handlers terminate the application
The TL;DR here: it's kind of a small miracle it worked in the first place
(Windows signal handling very very very much != *nix), and if your two OS
environments are respawning a process that terminated itself due to receiving a
SIGINT and shutting down, there's not much we can do from a runtime script
perspective to stop it.
That being said, I tested the functionality of this on server 2012 back when I
wrote it and it worked fine on a few different environments and used it for dev
purposes daily for a couple years after that on Win10 and Server 2012 for a
couple years after that without ever having an issue with it.
The new pid that gets spawned is another java process running C*? If you run
process explorer, what parent process owns that new pid? Is it owned by the
original cassandra.bat that you were running things from? Is it running as a
service under svchost?
> stop-server.bat -p ../pid.txt -f command not working on windows 2016
>
>
> Key: CASSANDRA-14464
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14464
> Project: Cassandra
> Issue Type: Bug
>Reporter: Shyam Phirke
>Priority: Critical
>
> Steps to reproduce:
> 1. Copy and extract cassandra binaries on windows 2016 machine
> 2. Start cassandra in non-legacy mode
> 3. Check pid of cassandra in task manager and compare it with in pid.txt
> 4. Now stop cassandra using command stop-server.bat -p ../pid.txt -f
> Expected:
> After executing \bin:\> stop-server.bat -p
> ../pid.txt -f
> cassandra process as in pid.txt should get killed.
>
> Actual:
> After executing above stop command, the cassandra process as in pid.txt gets
> killed but a new process gets created with new pid. Also the pid.txt not
> updated with new pid.
> This new process should not get created.
>
> Please comment on this issue if more details required.
> I am using cassandra 3.11.2.
>
> This issue impacting me much since because of this new process getting
> created my application uninstallation getting impacted.
>
--
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-12347) Gossip 2.0 - broadcast tree for data dissemination
[ https://issues.apache.org/jira/browse/CASSANDRA-12347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Brown updated CASSANDRA-12347: Fix Version/s: (was: 4.0) > Gossip 2.0 - broadcast tree for data dissemination > -- > > Key: CASSANDRA-12347 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12347 > Project: Cassandra > Issue Type: Improvement >Reporter: Jason Brown >Assignee: Jason Brown >Priority: Major > > Description: A broadcast tree (spanning tree) allows an originating node to > efficiently send out updates to all of the peers in the cluster by > constructing a balanced, self-healing tree based upon the view it gets from > the peer sampling service (CASSANDRA-12346). > I propose we use an algorithm based on the [Thicket > paper|http://www.gsd.inesc-id.pt/%7Ejleitao/pdf/srds10-mario.pdf], which > describes a dynamic, self-healing broadcast tree. When a given node needs to > send out a message, it dynamically builds a tree for each node in the > cluster; thus giving us a unique tree for every node in the cluster (a tree > rooted at every cluster node). The trees, of course, would be reusable until > the cluster configurations changes or failures are detected (by the mechanism > described in the paper). Additionally, Thicket includes a mechanism for > load-balancing the trees such that nodes spread out the work amongst > themselves. -- 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-12346) Gossip 2.0 - introduce a Peer Sampling Service for partial cluster views
[ https://issues.apache.org/jira/browse/CASSANDRA-12346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Brown updated CASSANDRA-12346: Fix Version/s: (was: 4.0) > Gossip 2.0 - introduce a Peer Sampling Service for partial cluster views > > > Key: CASSANDRA-12346 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12346 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jason Brown >Assignee: Jason Brown >Priority: Major > Labels: gossip > > A [Peer Sampling > Service|http://infoscience.epfl.ch/record/83409/files/neg--1184036295all.pdf] > is a module that provides a partial view of a cluster to dependent modules. A > node's partial view, combined with all other nodes' partial views, combine to > create a fully-connected mesh over the cluster. This way, a given node does > not need to have direct connections to every other node in the cluster, and > can be much more efficient in terms of resource management as well as > information dissemination. Peer Sampling Services by their nature must be > self-healing and self-balancing to maintain the fully-connected mesh. > I propose we use an algorithm based on > [HyParView|http://asc.di.fct.unl.pt/~jleitao/pdf/dsn07-leitao.pdf], which is > a concrete algorithm for a Peer Sampling Service. HyParView has a clearly > defined protocol, and is reasonably simple to implement. -- 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-12345) Gossip 2.0
[ https://issues.apache.org/jira/browse/CASSANDRA-12345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Brown updated CASSANDRA-12345: Fix Version/s: (was: 4.0) > Gossip 2.0 > -- > > Key: CASSANDRA-12345 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12345 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jason Brown >Assignee: Jason Brown >Priority: Major > Labels: gossip > > This is a parent ticket covering changes to the dissemination aspects of the > current gossip subsystem. (Changes to the actual data being exchanged by the > current gossip (the cluster metadata) will be handled elsewhere, but the > current primary ticket covering that work is CASSANDRA-9667.) > This work requires several components, which largely need to completed in > this order: > - a peer sampling service to create partial cluster views (CASSANDRA-12346). > This forms the basis of the next two components > - a broadcast tree, which creates dynamic spanning trees given the partial > views provided by the peer sampling service (CASSANDRA-12347) > - an anti-entropy component, which is similar to the pair-wise exchange and > reconciliation of the exitsing gossip implementation (CASSANDRA-???) > These base components (primarily the broadcast and anti-entropy) can allow > for generic consumers to simply and effectively share a body of data across > an entire cluster. The most obvious consumer will be a cluster metadata > component, which can replace the existing gossip system, but also other > components like CASSANDRA-12106. -- 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] [Comment Edited] (CASSANDRA-14488) Avoid unneeded memory allocations / cpu for disabled log levels
[
https://issues.apache.org/jira/browse/CASSANDRA-14488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16499073#comment-16499073
]
Jason Brown edited comment on CASSANDRA-14488 at 6/2/18 1:44 PM:
-
Patch lgtm, although I cleaned up some white space (removed tabs, aligned
indentation). Ran the tests and everything checks out:
||trunk||
|[branch|https://github.com/jasobrown/cassandra/tree/14488-trunk]|
|[utests &
dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/14488-trunk]|
committed as sha \{[4d8fc5b050efaef3da818605c31e62b508425972}}. Thanks for the
patch, [~benoitw]!
was (Author: jasobrown):
Patch lgtm, although I cleaned up some white space (removed tabs, aligned
indentation). Ran the tests and everything checks out:
||trunk||
|[branch|https://github.com/jasobrown/cassandra/tree/14488-trunk]|
|[utests &
dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/14488-trunk]|
committed as sha \{[4d8fc5b050efaef3da818605c31e62b508425972}}. Thanks for the
patch, [~benoitw]!
This closes #231
> Avoid unneeded memory allocations / cpu for disabled log levels
> ---
>
> Key: CASSANDRA-14488
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14488
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Benoit Wiart
>Assignee: Benoit Wiart
>Priority: Minor
> Fix For: 4.0
>
>
> add debug and trace log guard when the parameters creation implies memory
> allocations and / or cpu.
> Especially for StreamingInboundHandler/NettyStreamingMessageSender where
> createLogTag is allocating 64*2+UUID#toString bytes.
--
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-14488) Avoid unneeded memory allocations / cpu for disabled log levels
[ https://issues.apache.org/jira/browse/CASSANDRA-14488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Brown resolved CASSANDRA-14488. - Resolution: Fixed Fix Version/s: (was: 4.0.x) 4.0 > Avoid unneeded memory allocations / cpu for disabled log levels > --- > > Key: CASSANDRA-14488 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14488 > Project: Cassandra > Issue Type: Improvement >Reporter: Benoit Wiart >Assignee: Benoit Wiart >Priority: Minor > Fix For: 4.0 > > > add debug and trace log guard when the parameters creation implies memory > allocations and / or cpu. > Especially for StreamingInboundHandler/NettyStreamingMessageSender where > createLogTag is allocating 64*2+UUID#toString bytes. -- 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] [Comment Edited] (CASSANDRA-14488) Avoid unneeded memory allocations / cpu for disabled log levels
[
https://issues.apache.org/jira/browse/CASSANDRA-14488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16499073#comment-16499073
]
Jason Brown edited comment on CASSANDRA-14488 at 6/2/18 1:43 PM:
-
Patch lgtm, although I cleaned up some white space (removed tabs, aligned
indentation). Ran the tests and everything checks out:
||trunk||
|[branch|https://github.com/jasobrown/cassandra/tree/14488-trunk]|
|[utests &
dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/14488-trunk]|
committed as sha \{[4d8fc5b050efaef3da818605c31e62b508425972}}. Thanks for the
patch, [~benoitw]!
This closes #231
was (Author: jasobrown):
Patch lgtm, although I cleaned up some white space (removed tabs, aligned
indentation). Ran the tests and everything checks out:
||trunk||
|[branch|https://github.com/jasobrown/cassandra/tree/14488-trunk]|
|[utests
dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/14488-trunk]|
||
committed as sha {[4d8fc5b050efaef3da818605c31e62b508425972}}. Thanks for the
patch, [~benoitw]!
> Avoid unneeded memory allocations / cpu for disabled log levels
> ---
>
> Key: CASSANDRA-14488
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14488
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Benoit Wiart
>Assignee: Benoit Wiart
>Priority: Minor
> Fix For: 4.0
>
>
> add debug and trace log guard when the parameters creation implies memory
> allocations and / or cpu.
> Especially for StreamingInboundHandler/NettyStreamingMessageSender where
> createLogTag is allocating 64*2+UUID#toString bytes.
--
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-14488) Avoid unneeded memory allocations / cpu for disabled log levels
[
https://issues.apache.org/jira/browse/CASSANDRA-14488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16499073#comment-16499073
]
Jason Brown commented on CASSANDRA-14488:
-
Patch lgtm, although I cleaned up some white space (removed tabs, aligned
indentation). Ran the tests and everything checks out:
||trunk||
|[branch|https://github.com/jasobrown/cassandra/tree/14488-trunk]|
|[utests
dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/14488-trunk]|
||
committed as sha {[4d8fc5b050efaef3da818605c31e62b508425972}}. Thanks for the
patch, [~benoitw]!
> Avoid unneeded memory allocations / cpu for disabled log levels
> ---
>
> Key: CASSANDRA-14488
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14488
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Benoit Wiart
>Assignee: Benoit Wiart
>Priority: Minor
> Fix For: 4.0.x
>
>
> add debug and trace log guard when the parameters creation implies memory
> allocations and / or cpu.
> Especially for StreamingInboundHandler/NettyStreamingMessageSender where
> createLogTag is allocating 64*2+UUID#toString bytes.
--
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
cassandra git commit: Avoid unneeded memory allocations / cpu for disabled log levels
Repository: cassandra
Updated Branches:
refs/heads/trunk 069e383f5 -> 4d8fc5b05
Avoid unneeded memory allocations / cpu for disabled log levels
patch by Benoit Wiart; reviewed by jasobrown for CASSANDRA-14488
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/4d8fc5b0
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/4d8fc5b0
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/4d8fc5b0
Branch: refs/heads/trunk
Commit: 4d8fc5b050efaef3da818605c31e62b508425972
Parents: 069e383
Author: benoit
Authored: Sat Jun 2 11:55:28 2018 +0200
Committer: Jason Brown
Committed: Sat Jun 2 05:58:32 2018 -0700
--
CHANGES.txt | 1 +
.../apache/cassandra/db/ColumnFamilyStore.java | 3 +-
.../apache/cassandra/db/ConsistencyLevel.java | 3 +-
src/java/org/apache/cassandra/db/Keyspace.java | 3 +-
src/java/org/apache/cassandra/db/Memtable.java | 12 +++---
.../cassandra/db/SizeEstimatesRecorder.java | 9 +++--
.../cassandra/db/TruncateVerbHandler.java | 2 +-
.../db/compaction/CompactionManager.java| 6 ++-
.../cassandra/db/compaction/CompactionTask.java | 39 +++-
.../apache/cassandra/gms/TokenSerializer.java | 3 +-
...mitedLocalNodeFirstLocalBalancingPolicy.java | 3 +-
.../io/sstable/IndexSummaryRedistribution.java | 16
.../io/sstable/format/SSTableReader.java| 6 ++-
.../io/sstable/metadata/MetadataSerializer.java | 8 ++--
.../net/async/InboundHandshakeHandler.java | 3 +-
.../apache/cassandra/repair/RepairSession.java | 3 +-
.../cassandra/streaming/StreamCoordinator.java | 3 +-
.../async/NettyStreamingMessageSender.java | 28 +-
.../async/StreamingInboundHandler.java | 7 +++-
.../apache/cassandra/utils/JMXServerUtils.java | 17 +
20 files changed, 106 insertions(+), 69 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4d8fc5b0/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index b94fc62..179e7bb 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.0
+ * Avoid unneeded memory allocations / cpu for disabled log levels
(CASSANDRA-14488)
* Implement virtual keyspace interface (CASSANDRA-7622)
* nodetool import cleanup and improvements (CASSANDRA-14417)
* Bump jackson version to >= 2.9.5 (CASSANDRA-14427)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4d8fc5b0/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
--
diff --git a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
index 122b783..4be65c6 100644
--- a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
+++ b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
@@ -2002,7 +2002,8 @@ public class ColumnFamilyStore implements
ColumnFamilyStoreMBean
ephemeralSnapshotMarker.getParentFile().mkdirs();
Files.createFile(ephemeralSnapshotMarker.toPath());
-logger.trace("Created ephemeral snapshot marker file on {}.",
ephemeralSnapshotMarker.getAbsolutePath());
+if (logger.isTraceEnabled())
+logger.trace("Created ephemeral snapshot marker file on {}.",
ephemeralSnapshotMarker.getAbsolutePath());
}
catch (IOException e)
{
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4d8fc5b0/src/java/org/apache/cassandra/db/ConsistencyLevel.java
--
diff --git a/src/java/org/apache/cassandra/db/ConsistencyLevel.java
b/src/java/org/apache/cassandra/db/ConsistencyLevel.java
index 840c174..8f3a51c 100644
--- a/src/java/org/apache/cassandra/db/ConsistencyLevel.java
+++ b/src/java/org/apache/cassandra/db/ConsistencyLevel.java
@@ -293,7 +293,8 @@ public enum ConsistencyLevel
int live = Iterables.size(liveEndpoints);
if (live < blockFor)
{
-logger.trace("Live nodes {} do not satisfy
ConsistencyLevel ({} required)", Iterables.toString(liveEndpoints), blockFor);
+if (logger.isTraceEnabled())
+logger.trace("Live nodes {} do not satisfy
ConsistencyLevel ({} required)", Iterables.toString(liveEndpoints), blockFor);
throw new UnavailableException(this, blockFor, live);
}
break;
http://git-wip-us.apache.org/repos/asf/cassandra/blob/4d8fc5b0/src/java/org/apache/cassandra/db/Keyspace.java
--
diff --git
[jira] [Assigned] (CASSANDRA-14488) Avoid unneeded memory allocations / cpu for disabled log levels
[ https://issues.apache.org/jira/browse/CASSANDRA-14488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Brown reassigned CASSANDRA-14488: --- Assignee: Benoit Wiart Reviewer: Jason Brown Fix Version/s: 4.0.x > Avoid unneeded memory allocations / cpu for disabled log levels > --- > > Key: CASSANDRA-14488 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14488 > Project: Cassandra > Issue Type: Improvement >Reporter: Benoit Wiart >Assignee: Benoit Wiart >Priority: Minor > Fix For: 4.0.x > > > add debug and trace log guard when the parameters creation implies memory > allocations and / or cpu. > Especially for StreamingInboundHandler/NettyStreamingMessageSender where > createLogTag is allocating 64*2+UUID#toString bytes. -- 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-14488) Avoid unneeded memory allocations / cpu for disabled log levels
[ https://issues.apache.org/jira/browse/CASSANDRA-14488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Wiart updated CASSANDRA-14488: - External issue URL: https://github.com/apache/cassandra/pull/231 > Avoid unneeded memory allocations / cpu for disabled log levels > --- > > Key: CASSANDRA-14488 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14488 > Project: Cassandra > Issue Type: Improvement >Reporter: Benoit Wiart >Priority: Minor > > add debug and trace log guard when the parameters creation implies memory > allocations and / or cpu. > Especially for StreamingInboundHandler/NettyStreamingMessageSender where > createLogTag is allocating 64*2+UUID#toString bytes. -- 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-14488) Avoid unneeded memory allocations / cpu for disabled log levels
[ https://issues.apache.org/jira/browse/CASSANDRA-14488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16499006#comment-16499006 ] ASF GitHub Bot commented on CASSANDRA-14488: GitHub user benbenw opened a pull request: https://github.com/apache/cassandra/pull/231 CASSANDRA-14488 Avoid unneeded memory allocations / cpu for disabled log levels add debug and trace log guard when the parameters creation implies memory allocations and / or cpu. Especially for StreamingInboundHandler/NettyStreamingMessageSender where createLogTag is allocating 64*2+UUID#toString bytes You can merge this pull request into a Git repository by running: $ git pull https://github.com/benbenw/cassandra CASSANDRA-14488 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cassandra/pull/231.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #231 commit 0d8de4a2c0b58a42a7fb00c917d5c50286ee41d9 Author: benoit Date: 2018-06-02T09:55:28Z add debug and trace log guard when the parameters creation implies memory allocations and / or cpu. Especially for StreamingInboundHandler/NettyStreamingMessageSender where createLogTag is allocating 64*2+UUID#toString bytes > Avoid unneeded memory allocations / cpu for disabled log levels > --- > > Key: CASSANDRA-14488 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14488 > Project: Cassandra > Issue Type: Improvement >Reporter: Benoit Wiart >Priority: Minor > > add debug and trace log guard when the parameters creation implies memory > allocations and / or cpu. > Especially for StreamingInboundHandler/NettyStreamingMessageSender where > createLogTag is allocating 64*2+UUID#toString bytes. -- 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-14488) Avoid unneeded memory allocations / cpu for disabled log levels
Benoit Wiart created CASSANDRA-14488: Summary: Avoid unneeded memory allocations / cpu for disabled log levels Key: CASSANDRA-14488 URL: https://issues.apache.org/jira/browse/CASSANDRA-14488 Project: Cassandra Issue Type: Improvement Reporter: Benoit Wiart add debug and trace log guard when the parameters creation implies memory allocations and / or cpu. Especially for StreamingInboundHandler/NettyStreamingMessageSender where createLogTag is allocating 64*2+UUID#toString bytes. -- 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
