[jira] [Updated] (CASSANDRA-15262) server_encryption_options is not backwards compatible with 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-15262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict updated CASSANDRA-15262:
-
Reviewers: Benedict
> server_encryption_options is not backwards compatible with 3.11
> ---
>
> Key: CASSANDRA-15262
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15262
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Joseph Lynch
>Assignee: Joseph Lynch
>Priority: Normal
>
> The current `server_encryption_options` configuration options are as follows:
> {noformat}
> server_encryption_options:
> # set to true for allowing secure incoming connections
> enabled: false
> # If enabled and optional are both set to true, encrypted and unencrypted
> connections are handled on the storage_port
> optional: false
> # if enabled, will open up an encrypted listening socket on
> ssl_storage_port. Should be used
> # during upgrade to 4.0; otherwise, set to false.
> enable_legacy_ssl_storage_port: false
> # on outbound connections, determine which type of peers to securely
> connect to. 'enabled' must be set to true.
> internode_encryption: none
> keystore: conf/.keystore
> keystore_password: cassandra
> truststore: conf/.truststore
> truststore_password: cassandra
> # More advanced defaults below:
> # protocol: TLS
> # store_type: JKS
> # cipher_suites:
> [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA]
> # require_client_auth: false
> # require_endpoint_verification: false
> {noformat}
> A couple of issues here:
> 1. optional defaults to false, which will break existing TLS configurations
> for (from what I can tell) no particularly good reason
> 2. The provided protocol and cipher suites are not good ideas (in particular
> encouraging anyone to use CBC ciphers is a bad plan
> I propose that before the 4.0 cut we fixup server_encryption_options and even
> client_encryption_options :
> # Change the default {{optional}} setting to true. As the new Netty code
> intelligently decides to open a TLS connection or not this is the more
> sensible default (saves operators a step while transitioning to TLS as well)
> # Update the defaults to what netty actually defaults to
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14185) Nodetool tablehistograms to print statics for all the tables
[
https://issues.apache.org/jira/browse/CASSANDRA-14185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901560#comment-16901560
]
Chris Lohfink commented on CASSANDRA-14185:
---
[~dvohra] please open a new issue to include that
> Nodetool tablehistograms to print statics for all the tables
>
>
> Key: CASSANDRA-14185
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14185
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Jaydeepkumar Chovatia
>Assignee: Jaydeepkumar Chovatia
>Priority: Low
> Fix For: 4.0
>
>
> Currently {{nodetool tablehistograms}} requires {{keyspacename.tablename}} as
> argument always. If we want to print histograms for all the tables then we
> will have to run this command for all the tables one after another.
> It would be nice to have this command dump histogram for all the table at
> once if no argument is provided, similar to {{nodetool tablestats}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15214) OOMs caught and not rethrown
[ https://issues.apache.org/jira/browse/CASSANDRA-15214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901558#comment-16901558 ] Yifan Cai commented on CASSANDRA-15214: --- [~jolynch], you are welcome. Please use them. The test cases attached are more on the `Unsafe.allocateMemory` path. As far as I can see, they are different from the ones included in the jvmquake's test cases that only check the heap OOM. > OOMs caught and not rethrown > > > Key: CASSANDRA-15214 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15214 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client, Messaging/Internode >Reporter: Benedict >Priority: Normal > Fix For: 4.0 > > Attachments: oom-experiments.zip > > > Netty (at least, and perhaps elsewhere in Executors) catches all exceptions, > so presently there is no way to ensure that an OOM reaches the JVM handler to > trigger a crash/heapdump. > It may be that the simplest most consistent way to do this would be to have a > single thread spawned at startup that waits for any exceptions we must > propagate to the Runtime. > We could probably submit a patch upstream to Netty, but for a guaranteed > future proof approach, it may be worth paying the cost of a single thread. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15262) server_encryption_options is not backwards compatible with 3.11
[
https://issues.apache.org/jira/browse/CASSANDRA-15262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Lynch updated CASSANDRA-15262:
-
Severity: Low
Complexity: Low Hanging Fruit
Discovered By: Performance Regression Test
Bug Category: Parent values: Correctness(12982)Level 1 values: Semantic
Failure(12988)
Status: Open (was: Triage Needed)
> server_encryption_options is not backwards compatible with 3.11
> ---
>
> Key: CASSANDRA-15262
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15262
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Joseph Lynch
>Assignee: Joseph Lynch
>Priority: Normal
>
> The current `server_encryption_options` configuration options are as follows:
> {noformat}
> server_encryption_options:
> # set to true for allowing secure incoming connections
> enabled: false
> # If enabled and optional are both set to true, encrypted and unencrypted
> connections are handled on the storage_port
> optional: false
> # if enabled, will open up an encrypted listening socket on
> ssl_storage_port. Should be used
> # during upgrade to 4.0; otherwise, set to false.
> enable_legacy_ssl_storage_port: false
> # on outbound connections, determine which type of peers to securely
> connect to. 'enabled' must be set to true.
> internode_encryption: none
> keystore: conf/.keystore
> keystore_password: cassandra
> truststore: conf/.truststore
> truststore_password: cassandra
> # More advanced defaults below:
> # protocol: TLS
> # store_type: JKS
> # cipher_suites:
> [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA]
> # require_client_auth: false
> # require_endpoint_verification: false
> {noformat}
> A couple of issues here:
> 1. optional defaults to false, which will break existing TLS configurations
> for (from what I can tell) no particularly good reason
> 2. The provided protocol and cipher suites are not good ideas (in particular
> encouraging anyone to use CBC ciphers is a bad plan
> I propose that before the 4.0 cut we fixup server_encryption_options and even
> client_encryption_options :
> # Change the default {{optional}} setting to true. As the new Netty code
> intelligently decides to open a TLS connection or not this is the more
> sensible default (saves operators a step while transitioning to TLS as well)
> # Update the defaults to what netty actually defaults to
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15214) OOMs caught and not rethrown
[ https://issues.apache.org/jira/browse/CASSANDRA-15214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901555#comment-16901555 ] Joseph Lynch commented on CASSANDRA-15214: -- [~yifanc] If you are ok with it I can add your test cases to [jvmquake|https://github.com/Netflix-Skunkworks/jvmquake/tree/master/tests] to ensure it handles all edge cases. For what it's worth jvmquake is a strict superset of jvmkill and I wouldn't advocate for using jvmkill (I'm biased though). In my production experience jvmquake actually works at detecting GC spirals of death that C* runs into while jvmkill simply doesn't work as C* doesn't actually go OOM, it just death spirals. See the "hard oom" [test cases|https://github.com/Netflix-Skunkworks/jvmquake/blob/master/tests/test_hard_ooms.py] for example where jvmkill won't work while jvmquake will work. > OOMs caught and not rethrown > > > Key: CASSANDRA-15214 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15214 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client, Messaging/Internode >Reporter: Benedict >Priority: Normal > Fix For: 4.0 > > Attachments: oom-experiments.zip > > > Netty (at least, and perhaps elsewhere in Executors) catches all exceptions, > so presently there is no way to ensure that an OOM reaches the JVM handler to > trigger a crash/heapdump. > It may be that the simplest most consistent way to do this would be to have a > single thread spawned at startup that waits for any exceptions we must > propagate to the Runtime. > We could probably submit a patch upstream to Netty, but for a guaranteed > future proof approach, it may be worth paying the cost of a single thread. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14185) Nodetool tablehistograms to print statics for all the tables
[
https://issues.apache.org/jira/browse/CASSANDRA-14185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901551#comment-16901551
]
DeepakVohra commented on CASSANDRA-14185:
-
Please also update the _help_ to include the provision to list histograms for
all tables. Latest 4.0 build indicates requirement for a table.
{code:java}
nodetool help tablehistograms
NAME
nodetool tablehistograms - Print statistic histograms for a given table
{code}
> Nodetool tablehistograms to print statics for all the tables
>
>
> Key: CASSANDRA-14185
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14185
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Jaydeepkumar Chovatia
>Assignee: Jaydeepkumar Chovatia
>Priority: Low
> Fix For: 4.0
>
>
> Currently {{nodetool tablehistograms}} requires {{keyspacename.tablename}} as
> argument always. If we want to print histograms for all the tables then we
> will have to run this command for all the tables one after another.
> It would be nice to have this command dump histogram for all the table at
> once if no argument is provided, similar to {{nodetool tablestats}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13728) Provide max hint window as part of nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-13728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901538#comment-16901538
]
DeepakVohra commented on CASSANDRA-13728:
-
With latest 4.0 build the output is still the same as before.
{code:java}
nodetool statushandoff
Hinted handoff is running
{code}
> Provide max hint window as part of nodetool
> ---
>
> Key: CASSANDRA-13728
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13728
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Milan Milosevic
>Assignee: Varun Gupta
>Priority: Low
> Labels: lhf
> Fix For: 4.0
>
> Attachments: Add-nodetool-cmd-to-print-hinted-handoff-window.patch
>
>
> Currently it is not possible to get max_hint_window over nodetool. The
> information is available through StorageProxyMBean, though. Since max hint
> window information is needed in order to asses what kind of failure recovery
> should be performed for a node that goes down (bootstrap or just restart), it
> would be handy if max hint window is easily accessible using nodetool.
> Currently nodetool statushandoff output is:
> {code}
> [centos@cassandra-node]$ nodetool statushandoff
> Hinted handoff is running
> {code}
> The output could be improved to look like this:
> {code}
> [centos@cassandra-node]$ nodetool statushandoff
> Hinted handoff is running with max hint window (ms): 1080
> {code}
> Implementation is quite trivial (fetch the info from the StorageProxyMBean
> from the StatusHandoff class). I can provide the patch for this, if it is
> agreed that this it right approach.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13774) add bytes repaired/unrepaired in nodetool tablestats
[
https://issues.apache.org/jira/browse/CASSANDRA-13774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901531#comment-16901531
]
DeepakVohra commented on CASSANDRA-13774:
-
Only the percent is listed, and not the actual bytes with latest 4.0 build.
{code:java}
nodetool tablestats --sort local_read_count --top 3
...
Percent repaired: 0.0
...
{code}
> add bytes repaired/unrepaired in nodetool tablestats
>
>
> Key: CASSANDRA-13774
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13774
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Blake Eggleston
>Assignee: Blake Eggleston
>Priority: Normal
>
> It would be helpful to have the actual bytes that are repaired/unrepaired, in
> addition to the percentage
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15262) server_encryption_options is not backwards compatible with 3.11
Joseph Lynch created CASSANDRA-15262:
Summary: server_encryption_options is not backwards compatible
with 3.11
Key: CASSANDRA-15262
URL: https://issues.apache.org/jira/browse/CASSANDRA-15262
Project: Cassandra
Issue Type: Bug
Components: Local/Config
Reporter: Joseph Lynch
Assignee: Joseph Lynch
The current `server_encryption_options` configuration options are as follows:
{noformat}
server_encryption_options:
# set to true for allowing secure incoming connections
enabled: false
# If enabled and optional are both set to true, encrypted and unencrypted
connections are handled on the storage_port
optional: false
# if enabled, will open up an encrypted listening socket on
ssl_storage_port. Should be used
# during upgrade to 4.0; otherwise, set to false.
enable_legacy_ssl_storage_port: false
# on outbound connections, determine which type of peers to securely
connect to. 'enabled' must be set to true.
internode_encryption: none
keystore: conf/.keystore
keystore_password: cassandra
truststore: conf/.truststore
truststore_password: cassandra
# More advanced defaults below:
# protocol: TLS
# store_type: JKS
# cipher_suites:
[TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA]
# require_client_auth: false
# require_endpoint_verification: false
{noformat}
A couple of issues here:
1. optional defaults to false, which will break existing TLS configurations for
(from what I can tell) no particularly good reason
2. The provided protocol and cipher suites are not good ideas (in particular
encouraging anyone to use CBC ciphers is a bad plan
I propose that before the 4.0 cut we fixup server_encryption_options and even
client_encryption_options :
# Change the default {{optional}} setting to true. As the new Netty code
intelligently decides to open a TLS connection or not this is the more sensible
default (saves operators a step while transitioning to TLS as well)
# Update the defaults to what netty actually defaults to
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15214) OOMs caught and not rethrown
[
https://issues.apache.org/jira/browse/CASSANDRA-15214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901497#comment-16901497
]
Yifan Cai commented on CASSANDRA-15214:
---
Several experiments of the OOM scenario are made to check if the HotSpot
handlers work as expected, namely kill the process.
The result shows that the handlers, OnOutOfMemoryError and
ExitOnOutOfMemoryError, are only effective for heap OOM.
*Experiments*
The experiments are designed to emulate what happens in C* while being minimal.
They have the Thread.setDefaultUncaughtExceptionHandler installed and just
re-throw the OOM error hoping the handlers can take care.
OpenJDK 8 was used.
You can find all the 5 experiments in the attached [^oom-experiments.zip].
{code:java}
├── OomExperimentExceedsDirectBuffer.java
├── OomExperimentExceedsDirectBufferRapidAlloc.java
├── OomExperimentExceedsHeap.java
├── OomExperimentSimple.java
└── OomExperimentSimpleJustExit.java{code}
Among those experiments, there is only one (OomExperimentExceedsHeap) can
successfully trigger the handlers.
The rest do throw the OutOfMemoryError, but the handlers are not triggered.
*Some Research*
The cause could be due to the difference of the code path in JVM implementation
to allocate memory on heap and for direct buffer. (OpenJDK8 is the reference)
Heap memory allocation happens at
[collectedHeap.inline.hpp#CollectedHeap::common_mem_allocate_noinit|https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/aa318070b27849f1fe00d14684b2a40f7b29bf79/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp#L149].
When it failed, it calls
[report_java_out_of_memory|https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/aa318070b27849f1fe00d14684b2a40f7b29bf79/hotspot/src/share/vm/utilities/debug.cpp#L287],
which is responsible to create a heap dump on OOM and run the handlers.
Meanwhile, allocating direct buffer take a different path. In
java.nio.DirectByteBuffer, OOM can happen at 2 places.
1. Bits.reserveMemory, finds out there is not enough direct memory and throws
OOM. In this case, I do not think the OOM is caught and handled in JVM to
trigger report_java_out_of_memory.
2. unsafe.allocateMemory, which calls malloc directly, but [failed to allocate
and throws
OOM|https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/aa318070b27849f1fe00d14684b2a40f7b29bf79/hotspot/src/share/vm/prims/unsafe.cpp#L606].
Again, such OOM was throw in order to let the application to handle.
Another proof is that
[report_java_out_of_memory|https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/aa318070b27849f1fe00d14684b2a40f7b29bf79/hotspot/src/share/vm/utilities/debug.cpp#L287],
the only place to trigger the handler, was not invoked during
unsafe.allocateMemory. Here are [all the references of the method
invocation|https://github.com/AdoptOpenJDK/openjdk-jdk8u/search?q=report_java_out_of_memory_q=report_java_out_of_memory].
Because of that, jvmkill or jvmquake mentioned in the ticket might not work.
The tool replies on the notification of the
[JvmtiExport::post_resource_exhausted|https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/aa318070b27849f1fe00d14684b2a40f7b29bf79/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp#L153],
which does not present in the 2 places that direct buffer OOM can happen. Here
is the implementation of
[jvmkill|https://github.com/airlift/jvmkill/blob/master/jvmkill.c#L24] (less
than 100 lines).
> OOMs caught and not rethrown
>
>
> Key: CASSANDRA-15214
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15214
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Messaging/Internode
>Reporter: Benedict
>Priority: Normal
> Fix For: 4.0
>
> Attachments: oom-experiments.zip
>
>
> Netty (at least, and perhaps elsewhere in Executors) catches all exceptions,
> so presently there is no way to ensure that an OOM reaches the JVM handler to
> trigger a crash/heapdump.
> It may be that the simplest most consistent way to do this would be to have a
> single thread spawned at startup that waits for any exceptions we must
> propagate to the Runtime.
> We could probably submit a patch upstream to Netty, but for a guaranteed
> future proof approach, it may be worth paying the cost of a single thread.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15214) OOMs caught and not rethrown
[ https://issues.apache.org/jira/browse/CASSANDRA-15214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRA-15214: -- Attachment: oom-experiments.zip > OOMs caught and not rethrown > > > Key: CASSANDRA-15214 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15214 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client, Messaging/Internode >Reporter: Benedict >Priority: Normal > Fix For: 4.0 > > Attachments: oom-experiments.zip > > > Netty (at least, and perhaps elsewhere in Executors) catches all exceptions, > so presently there is no way to ensure that an OOM reaches the JVM handler to > trigger a crash/heapdump. > It may be that the simplest most consistent way to do this would be to have a > single thread spawned at startup that waits for any exceptions we must > propagate to the Runtime. > We could probably submit a patch upstream to Netty, but for a guaranteed > future proof approach, it may be worth paying the cost of a single thread. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15175) Evaluate 200 node, compression=on, encryption=all
[ https://issues.apache.org/jira/browse/CASSANDRA-15175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Lynch updated CASSANDRA-15175: - Attachment: cassandra_comparative_performance_all_flamegraphs.html > Evaluate 200 node, compression=on, encryption=all > - > > Key: CASSANDRA-15175 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15175 > Project: Cassandra > Issue Type: Sub-task > Components: Test/benchmark >Reporter: Joseph Lynch >Assignee: Joseph Lynch >Priority: Normal > Attachments: 30x_14400cRPS-14400cWPS.svg, > 30x_LQ_21600cRPS-14400cWPS.svg, ShortbufferExceptions.png, > cassandra_comparative_performance_all_flamegraphs.html, > image-2019-08-06-14-20-25-140.png, odd_netty_jdk_tls_cpu_usage.png, > trunk_14400cRPS-14400cWPS.svg, trunk_187000cRPS-14400cWPS.svg, > trunk_187kcRPS_14kcWPS.png, trunk_22000cRPS-14400cWPS-jdk.svg, > trunk_22000cRPS-14400cWPS-openssl.svg, trunk_220kcRPS_14kcWPS.png, > trunk_252kcRPS-14kcWPS.png, trunk_93500cRPS-14400cWPS.svg, > trunk_LQ_14400cRPS-14400cWPS.svg, trunk_LQ_21600cRPS-14400cWPS.svg, > trunk_Q_21600cRPS-7200cWPS.svg, trunk_allocation_Q_21k_cRPS.svg, > trunk_vs_30x_125kcRPS_14kcWPS.png, trunk_vs_30x_14kRPS_14kcWPS_load.png, > trunk_vs_30x_14kcRPS_14kcWPS.png, > trunk_vs_30x_14kcRPS_14kcWPS_schedstat_delays.png, > trunk_vs_30x_156kcRPS_14kcWPS.png, trunk_vs_30x_24kcRPS_14kcWPS.png, > trunk_vs_30x_24kcRPS_14kcWPS_load.png, trunk_vs_30x_31kcRPS_14kcWPS.png, > trunk_vs_30x_62kcRPS_14kcWPS.png, trunk_vs_30x_93kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_14kcRPS_14kcWPS.png, trunk_vs_30x_LQ_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_64kcRPS_14kcWPS.png, trunk_vs_30x_LQ_jdk_summary.png, > trunk_vs_30x_LQ_openssl_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_tcnative_summary.png, trunk_vs_30x_Q_21kcRPS_7200cWPS.png, > trunk_vs_30x_Q_36kcRPS_7200cWPS.png, trunk_vs_30x_Q_tcnative_summary.png, > trunk_vs_30x_summary.png, trunk_vs_30x_wEQ_rLQ_7kcRPS_22kcWPS.png, > trunk_vs_30x_wEQ_rLQ_7kcRPS_58kcWPS.png, > trunk_vs_30x_wEQ_rLQ_7kcRPS_7kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_108kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_162kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_72kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_7kcWPS.png, write_scaling_local_one_summary.png, > write_scaling_lq_eq_summary.png > > > Tracks evaluating a 192 node cluster with compression and encryption on. > First test is a [read scaling test > |https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=1336583053] > > |Test Setup| | > |Baseline|3.0.19 > @d7d00036| > |Candiate|trunk > @abb0e177| > | | | > |Workload| | > |Write size|4kb random| > |Read size|4kb random| > |Per Node Data|110GiB| > |Generator|ndbench| > |Key Distribution|Uniform| > |SSTable Compr|Off| > |Internode TLS|On (jdk)| > |Internode Compr|On| > |Compaction|LCS (320 MiB)| > |Repair|Off| > | | | > |Hardware| | > |Instance Type|i3.xlarge| > |Deployment|96 us-east-1, 96 eu-west-1| > |Region node count|96| > | | | > |OS Settings| | > |IO scheduler|kyber| > |Net qdisc|tc-fq| > |readahead|32kb| > |Java Version|OpenJDK 1.8.0_202 (Zulu)| > | | | > Second test is a [write scaling > test|https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=428858608]: -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15175) Evaluate 200 node, compression=on, encryption=all
[ https://issues.apache.org/jira/browse/CASSANDRA-15175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901482#comment-16901482 ] Joseph Lynch commented on CASSANDRA-15175: -- The analysis so far: [^cassandra_comparative_performance_all_flamegraphs.html] > Evaluate 200 node, compression=on, encryption=all > - > > Key: CASSANDRA-15175 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15175 > Project: Cassandra > Issue Type: Sub-task > Components: Test/benchmark >Reporter: Joseph Lynch >Assignee: Joseph Lynch >Priority: Normal > Attachments: 30x_14400cRPS-14400cWPS.svg, > 30x_LQ_21600cRPS-14400cWPS.svg, ShortbufferExceptions.png, > image-2019-08-06-14-20-25-140.png, odd_netty_jdk_tls_cpu_usage.png, > trunk_14400cRPS-14400cWPS.svg, trunk_187000cRPS-14400cWPS.svg, > trunk_187kcRPS_14kcWPS.png, trunk_22000cRPS-14400cWPS-jdk.svg, > trunk_22000cRPS-14400cWPS-openssl.svg, trunk_220kcRPS_14kcWPS.png, > trunk_252kcRPS-14kcWPS.png, trunk_93500cRPS-14400cWPS.svg, > trunk_LQ_14400cRPS-14400cWPS.svg, trunk_LQ_21600cRPS-14400cWPS.svg, > trunk_Q_21600cRPS-7200cWPS.svg, trunk_allocation_Q_21k_cRPS.svg, > trunk_vs_30x_125kcRPS_14kcWPS.png, trunk_vs_30x_14kRPS_14kcWPS_load.png, > trunk_vs_30x_14kcRPS_14kcWPS.png, > trunk_vs_30x_14kcRPS_14kcWPS_schedstat_delays.png, > trunk_vs_30x_156kcRPS_14kcWPS.png, trunk_vs_30x_24kcRPS_14kcWPS.png, > trunk_vs_30x_24kcRPS_14kcWPS_load.png, trunk_vs_30x_31kcRPS_14kcWPS.png, > trunk_vs_30x_62kcRPS_14kcWPS.png, trunk_vs_30x_93kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_14kcRPS_14kcWPS.png, trunk_vs_30x_LQ_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_64kcRPS_14kcWPS.png, trunk_vs_30x_LQ_jdk_summary.png, > trunk_vs_30x_LQ_openssl_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_tcnative_summary.png, trunk_vs_30x_Q_21kcRPS_7200cWPS.png, > trunk_vs_30x_Q_36kcRPS_7200cWPS.png, trunk_vs_30x_Q_tcnative_summary.png, > trunk_vs_30x_summary.png, trunk_vs_30x_wEQ_rLQ_7kcRPS_22kcWPS.png, > trunk_vs_30x_wEQ_rLQ_7kcRPS_58kcWPS.png, > trunk_vs_30x_wEQ_rLQ_7kcRPS_7kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_108kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_162kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_72kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_7kcWPS.png, write_scaling_local_one_summary.png, > write_scaling_lq_eq_summary.png > > > Tracks evaluating a 192 node cluster with compression and encryption on. > First test is a [read scaling test > |https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=1336583053] > > |Test Setup| | > |Baseline|3.0.19 > @d7d00036| > |Candiate|trunk > @abb0e177| > | | | > |Workload| | > |Write size|4kb random| > |Read size|4kb random| > |Per Node Data|110GiB| > |Generator|ndbench| > |Key Distribution|Uniform| > |SSTable Compr|Off| > |Internode TLS|On (jdk)| > |Internode Compr|On| > |Compaction|LCS (320 MiB)| > |Repair|Off| > | | | > |Hardware| | > |Instance Type|i3.xlarge| > |Deployment|96 us-east-1, 96 eu-west-1| > |Region node count|96| > | | | > |OS Settings| | > |IO scheduler|kyber| > |Net qdisc|tc-fq| > |readahead|32kb| > |Java Version|OpenJDK 1.8.0_202 (Zulu)| > | | | > Second test is a [write scaling > test|https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=428858608]: -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15175) Evaluate 200 node, compression=on, encryption=all
[ https://issues.apache.org/jira/browse/CASSANDRA-15175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Lynch updated CASSANDRA-15175: - Attachment: write_scaling_local_one_summary.png > Evaluate 200 node, compression=on, encryption=all > - > > Key: CASSANDRA-15175 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15175 > Project: Cassandra > Issue Type: Sub-task > Components: Test/benchmark >Reporter: Joseph Lynch >Assignee: Joseph Lynch >Priority: Normal > Attachments: 30x_14400cRPS-14400cWPS.svg, > 30x_LQ_21600cRPS-14400cWPS.svg, ShortbufferExceptions.png, > image-2019-08-06-14-20-25-140.png, odd_netty_jdk_tls_cpu_usage.png, > trunk_14400cRPS-14400cWPS.svg, trunk_187000cRPS-14400cWPS.svg, > trunk_187kcRPS_14kcWPS.png, trunk_22000cRPS-14400cWPS-jdk.svg, > trunk_22000cRPS-14400cWPS-openssl.svg, trunk_220kcRPS_14kcWPS.png, > trunk_252kcRPS-14kcWPS.png, trunk_93500cRPS-14400cWPS.svg, > trunk_LQ_14400cRPS-14400cWPS.svg, trunk_LQ_21600cRPS-14400cWPS.svg, > trunk_Q_21600cRPS-7200cWPS.svg, trunk_allocation_Q_21k_cRPS.svg, > trunk_vs_30x_125kcRPS_14kcWPS.png, trunk_vs_30x_14kRPS_14kcWPS_load.png, > trunk_vs_30x_14kcRPS_14kcWPS.png, > trunk_vs_30x_14kcRPS_14kcWPS_schedstat_delays.png, > trunk_vs_30x_156kcRPS_14kcWPS.png, trunk_vs_30x_24kcRPS_14kcWPS.png, > trunk_vs_30x_24kcRPS_14kcWPS_load.png, trunk_vs_30x_31kcRPS_14kcWPS.png, > trunk_vs_30x_62kcRPS_14kcWPS.png, trunk_vs_30x_93kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_14kcRPS_14kcWPS.png, trunk_vs_30x_LQ_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_64kcRPS_14kcWPS.png, trunk_vs_30x_LQ_jdk_summary.png, > trunk_vs_30x_LQ_openssl_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_tcnative_summary.png, trunk_vs_30x_Q_21kcRPS_7200cWPS.png, > trunk_vs_30x_Q_36kcRPS_7200cWPS.png, trunk_vs_30x_Q_tcnative_summary.png, > trunk_vs_30x_summary.png, trunk_vs_30x_wEQ_rLQ_7kcRPS_22kcWPS.png, > trunk_vs_30x_wEQ_rLQ_7kcRPS_58kcWPS.png, > trunk_vs_30x_wEQ_rLQ_7kcRPS_7kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_108kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_162kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_72kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_7kcWPS.png, write_scaling_local_one_summary.png, > write_scaling_lq_eq_summary.png > > > Tracks evaluating a 192 node cluster with compression and encryption on. > First test is a [read scaling test > |https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=1336583053] > > |Test Setup| | > |Baseline|3.0.19 > @d7d00036| > |Candiate|trunk > @abb0e177| > | | | > |Workload| | > |Write size|4kb random| > |Read size|4kb random| > |Per Node Data|110GiB| > |Generator|ndbench| > |Key Distribution|Uniform| > |SSTable Compr|Off| > |Internode TLS|On (jdk)| > |Internode Compr|On| > |Compaction|LCS (320 MiB)| > |Repair|Off| > | | | > |Hardware| | > |Instance Type|i3.xlarge| > |Deployment|96 us-east-1, 96 eu-west-1| > |Region node count|96| > | | | > |OS Settings| | > |IO scheduler|kyber| > |Net qdisc|tc-fq| > |readahead|32kb| > |Java Version|OpenJDK 1.8.0_202 (Zulu)| > | | | > Second test is a [write scaling > test|https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=428858608]: -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15175) Evaluate 200 node, compression=on, encryption=all
[ https://issues.apache.org/jira/browse/CASSANDRA-15175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Lynch updated CASSANDRA-15175: - Attachment: write_scaling_lq_eq_summary.png > Evaluate 200 node, compression=on, encryption=all > - > > Key: CASSANDRA-15175 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15175 > Project: Cassandra > Issue Type: Sub-task > Components: Test/benchmark >Reporter: Joseph Lynch >Assignee: Joseph Lynch >Priority: Normal > Attachments: 30x_14400cRPS-14400cWPS.svg, > 30x_LQ_21600cRPS-14400cWPS.svg, ShortbufferExceptions.png, > image-2019-08-06-14-20-25-140.png, odd_netty_jdk_tls_cpu_usage.png, > trunk_14400cRPS-14400cWPS.svg, trunk_187000cRPS-14400cWPS.svg, > trunk_187kcRPS_14kcWPS.png, trunk_22000cRPS-14400cWPS-jdk.svg, > trunk_22000cRPS-14400cWPS-openssl.svg, trunk_220kcRPS_14kcWPS.png, > trunk_252kcRPS-14kcWPS.png, trunk_93500cRPS-14400cWPS.svg, > trunk_LQ_14400cRPS-14400cWPS.svg, trunk_LQ_21600cRPS-14400cWPS.svg, > trunk_Q_21600cRPS-7200cWPS.svg, trunk_allocation_Q_21k_cRPS.svg, > trunk_vs_30x_125kcRPS_14kcWPS.png, trunk_vs_30x_14kRPS_14kcWPS_load.png, > trunk_vs_30x_14kcRPS_14kcWPS.png, > trunk_vs_30x_14kcRPS_14kcWPS_schedstat_delays.png, > trunk_vs_30x_156kcRPS_14kcWPS.png, trunk_vs_30x_24kcRPS_14kcWPS.png, > trunk_vs_30x_24kcRPS_14kcWPS_load.png, trunk_vs_30x_31kcRPS_14kcWPS.png, > trunk_vs_30x_62kcRPS_14kcWPS.png, trunk_vs_30x_93kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_14kcRPS_14kcWPS.png, trunk_vs_30x_LQ_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_64kcRPS_14kcWPS.png, trunk_vs_30x_LQ_jdk_summary.png, > trunk_vs_30x_LQ_openssl_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_tcnative_summary.png, trunk_vs_30x_Q_21kcRPS_7200cWPS.png, > trunk_vs_30x_Q_36kcRPS_7200cWPS.png, trunk_vs_30x_Q_tcnative_summary.png, > trunk_vs_30x_summary.png, trunk_vs_30x_wEQ_rLQ_7kcRPS_22kcWPS.png, > trunk_vs_30x_wEQ_rLQ_7kcRPS_58kcWPS.png, > trunk_vs_30x_wEQ_rLQ_7kcRPS_7kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_108kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_162kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_72kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_7kcWPS.png, write_scaling_local_one_summary.png, > write_scaling_lq_eq_summary.png > > > Tracks evaluating a 192 node cluster with compression and encryption on. > First test is a [read scaling test > |https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=1336583053] > > |Test Setup| | > |Baseline|3.0.19 > @d7d00036| > |Candiate|trunk > @abb0e177| > | | | > |Workload| | > |Write size|4kb random| > |Read size|4kb random| > |Per Node Data|110GiB| > |Generator|ndbench| > |Key Distribution|Uniform| > |SSTable Compr|Off| > |Internode TLS|On (jdk)| > |Internode Compr|On| > |Compaction|LCS (320 MiB)| > |Repair|Off| > | | | > |Hardware| | > |Instance Type|i3.xlarge| > |Deployment|96 us-east-1, 96 eu-west-1| > |Region node count|96| > | | | > |OS Settings| | > |IO scheduler|kyber| > |Net qdisc|tc-fq| > |readahead|32kb| > |Java Version|OpenJDK 1.8.0_202 (Zulu)| > | | | > Second test is a [write scaling > test|https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=428858608]: -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15175) Evaluate 200 node, compression=on, encryption=all
[ https://issues.apache.org/jira/browse/CASSANDRA-15175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901476#comment-16901476 ] Joseph Lynch commented on CASSANDRA-15175: -- Write scaling test LOCAL_ONE looks good: !write_scaling_local_one_summary.png! Write scaling test at LQ reads + EQ writes looks ok, but not great: !write_scaling_lq_eq_summary.png! > Evaluate 200 node, compression=on, encryption=all > - > > Key: CASSANDRA-15175 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15175 > Project: Cassandra > Issue Type: Sub-task > Components: Test/benchmark >Reporter: Joseph Lynch >Assignee: Joseph Lynch >Priority: Normal > Attachments: 30x_14400cRPS-14400cWPS.svg, > 30x_LQ_21600cRPS-14400cWPS.svg, ShortbufferExceptions.png, > image-2019-08-06-14-20-25-140.png, odd_netty_jdk_tls_cpu_usage.png, > trunk_14400cRPS-14400cWPS.svg, trunk_187000cRPS-14400cWPS.svg, > trunk_187kcRPS_14kcWPS.png, trunk_22000cRPS-14400cWPS-jdk.svg, > trunk_22000cRPS-14400cWPS-openssl.svg, trunk_220kcRPS_14kcWPS.png, > trunk_252kcRPS-14kcWPS.png, trunk_93500cRPS-14400cWPS.svg, > trunk_LQ_14400cRPS-14400cWPS.svg, trunk_LQ_21600cRPS-14400cWPS.svg, > trunk_Q_21600cRPS-7200cWPS.svg, trunk_allocation_Q_21k_cRPS.svg, > trunk_vs_30x_125kcRPS_14kcWPS.png, trunk_vs_30x_14kRPS_14kcWPS_load.png, > trunk_vs_30x_14kcRPS_14kcWPS.png, > trunk_vs_30x_14kcRPS_14kcWPS_schedstat_delays.png, > trunk_vs_30x_156kcRPS_14kcWPS.png, trunk_vs_30x_24kcRPS_14kcWPS.png, > trunk_vs_30x_24kcRPS_14kcWPS_load.png, trunk_vs_30x_31kcRPS_14kcWPS.png, > trunk_vs_30x_62kcRPS_14kcWPS.png, trunk_vs_30x_93kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_14kcRPS_14kcWPS.png, trunk_vs_30x_LQ_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_64kcRPS_14kcWPS.png, trunk_vs_30x_LQ_jdk_summary.png, > trunk_vs_30x_LQ_openssl_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_tcnative_summary.png, trunk_vs_30x_Q_21kcRPS_7200cWPS.png, > trunk_vs_30x_Q_36kcRPS_7200cWPS.png, trunk_vs_30x_Q_tcnative_summary.png, > trunk_vs_30x_summary.png, trunk_vs_30x_wEQ_rLQ_7kcRPS_22kcWPS.png, > trunk_vs_30x_wEQ_rLQ_7kcRPS_58kcWPS.png, > trunk_vs_30x_wEQ_rLQ_7kcRPS_7kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_108kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_162kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_72kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_7kcWPS.png, write_scaling_local_one_summary.png, > write_scaling_lq_eq_summary.png > > > Tracks evaluating a 192 node cluster with compression and encryption on. > First test is a [read scaling test > |https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=1336583053] > > |Test Setup| | > |Baseline|3.0.19 > @d7d00036| > |Candiate|trunk > @abb0e177| > | | | > |Workload| | > |Write size|4kb random| > |Read size|4kb random| > |Per Node Data|110GiB| > |Generator|ndbench| > |Key Distribution|Uniform| > |SSTable Compr|Off| > |Internode TLS|On (jdk)| > |Internode Compr|On| > |Compaction|LCS (320 MiB)| > |Repair|Off| > | | | > |Hardware| | > |Instance Type|i3.xlarge| > |Deployment|96 us-east-1, 96 eu-west-1| > |Region node count|96| > | | | > |OS Settings| | > |IO scheduler|kyber| > |Net qdisc|tc-fq| > |readahead|32kb| > |Java Version|OpenJDK 1.8.0_202 (Zulu)| > | | | > Second test is a [write scaling > test|https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=428858608]: -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15175) Evaluate 200 node, compression=on, encryption=all
[ https://issues.apache.org/jira/browse/CASSANDRA-15175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Lynch updated CASSANDRA-15175: - Attachment: image-2019-08-06-14-20-25-140.png > Evaluate 200 node, compression=on, encryption=all > - > > Key: CASSANDRA-15175 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15175 > Project: Cassandra > Issue Type: Sub-task > Components: Test/benchmark >Reporter: Joseph Lynch >Assignee: Joseph Lynch >Priority: Normal > Attachments: 30x_14400cRPS-14400cWPS.svg, > 30x_LQ_21600cRPS-14400cWPS.svg, ShortbufferExceptions.png, > image-2019-08-06-14-20-25-140.png, odd_netty_jdk_tls_cpu_usage.png, > trunk_14400cRPS-14400cWPS.svg, trunk_187000cRPS-14400cWPS.svg, > trunk_187kcRPS_14kcWPS.png, trunk_22000cRPS-14400cWPS-jdk.svg, > trunk_22000cRPS-14400cWPS-openssl.svg, trunk_220kcRPS_14kcWPS.png, > trunk_252kcRPS-14kcWPS.png, trunk_93500cRPS-14400cWPS.svg, > trunk_LQ_14400cRPS-14400cWPS.svg, trunk_LQ_21600cRPS-14400cWPS.svg, > trunk_Q_21600cRPS-7200cWPS.svg, trunk_allocation_Q_21k_cRPS.svg, > trunk_vs_30x_125kcRPS_14kcWPS.png, trunk_vs_30x_14kRPS_14kcWPS_load.png, > trunk_vs_30x_14kcRPS_14kcWPS.png, > trunk_vs_30x_14kcRPS_14kcWPS_schedstat_delays.png, > trunk_vs_30x_156kcRPS_14kcWPS.png, trunk_vs_30x_24kcRPS_14kcWPS.png, > trunk_vs_30x_24kcRPS_14kcWPS_load.png, trunk_vs_30x_31kcRPS_14kcWPS.png, > trunk_vs_30x_62kcRPS_14kcWPS.png, trunk_vs_30x_93kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_14kcRPS_14kcWPS.png, trunk_vs_30x_LQ_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_64kcRPS_14kcWPS.png, trunk_vs_30x_LQ_jdk_summary.png, > trunk_vs_30x_LQ_openssl_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_tcnative_summary.png, trunk_vs_30x_Q_21kcRPS_7200cWPS.png, > trunk_vs_30x_Q_36kcRPS_7200cWPS.png, trunk_vs_30x_Q_tcnative_summary.png, > trunk_vs_30x_summary.png, trunk_vs_30x_wEQ_rLQ_7kcRPS_22kcWPS.png, > trunk_vs_30x_wEQ_rLQ_7kcRPS_58kcWPS.png, > trunk_vs_30x_wEQ_rLQ_7kcRPS_7kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_108kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_162kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_72kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_7kcWPS.png > > > Tracks evaluating a 192 node cluster with compression and encryption on. > First test is a [read scaling test > |https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=1336583053] > > |Test Setup| | > |Baseline|3.0.19 > @d7d00036| > |Candiate|trunk > @abb0e177| > | | | > |Workload| | > |Write size|4kb random| > |Read size|4kb random| > |Per Node Data|110GiB| > |Generator|ndbench| > |Key Distribution|Uniform| > |SSTable Compr|Off| > |Internode TLS|On (jdk)| > |Internode Compr|On| > |Compaction|LCS (320 MiB)| > |Repair|Off| > | | | > |Hardware| | > |Instance Type|i3.xlarge| > |Deployment|96 us-east-1, 96 eu-west-1| > |Region node count|96| > | | | > |OS Settings| | > |IO scheduler|kyber| > |Net qdisc|tc-fq| > |readahead|32kb| > |Java Version|OpenJDK 1.8.0_202 (Zulu)| > | | | > Second test is a [write scaling > test|https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=428858608]: -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15175) Evaluate 200 node, compression=on, encryption=all
[ https://issues.apache.org/jira/browse/CASSANDRA-15175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Lynch updated CASSANDRA-15175: - Attachment: (was: trunk_vs_30x_wEQ_rLQ_7kcRPS_58kcWPS.png) > Evaluate 200 node, compression=on, encryption=all > - > > Key: CASSANDRA-15175 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15175 > Project: Cassandra > Issue Type: Sub-task > Components: Test/benchmark >Reporter: Joseph Lynch >Assignee: Joseph Lynch >Priority: Normal > Attachments: 30x_14400cRPS-14400cWPS.svg, > 30x_LQ_21600cRPS-14400cWPS.svg, ShortbufferExceptions.png, > odd_netty_jdk_tls_cpu_usage.png, trunk_14400cRPS-14400cWPS.svg, > trunk_187000cRPS-14400cWPS.svg, trunk_187kcRPS_14kcWPS.png, > trunk_22000cRPS-14400cWPS-jdk.svg, trunk_22000cRPS-14400cWPS-openssl.svg, > trunk_220kcRPS_14kcWPS.png, trunk_252kcRPS-14kcWPS.png, > trunk_93500cRPS-14400cWPS.svg, trunk_LQ_14400cRPS-14400cWPS.svg, > trunk_LQ_21600cRPS-14400cWPS.svg, trunk_Q_21600cRPS-7200cWPS.svg, > trunk_allocation_Q_21k_cRPS.svg, trunk_vs_30x_125kcRPS_14kcWPS.png, > trunk_vs_30x_14kRPS_14kcWPS_load.png, trunk_vs_30x_14kcRPS_14kcWPS.png, > trunk_vs_30x_14kcRPS_14kcWPS_schedstat_delays.png, > trunk_vs_30x_156kcRPS_14kcWPS.png, trunk_vs_30x_24kcRPS_14kcWPS.png, > trunk_vs_30x_24kcRPS_14kcWPS_load.png, trunk_vs_30x_31kcRPS_14kcWPS.png, > trunk_vs_30x_62kcRPS_14kcWPS.png, trunk_vs_30x_93kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_14kcRPS_14kcWPS.png, trunk_vs_30x_LQ_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_64kcRPS_14kcWPS.png, trunk_vs_30x_LQ_jdk_summary.png, > trunk_vs_30x_LQ_openssl_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_tcnative_summary.png, trunk_vs_30x_Q_21kcRPS_7200cWPS.png, > trunk_vs_30x_Q_36kcRPS_7200cWPS.png, trunk_vs_30x_Q_tcnative_summary.png, > trunk_vs_30x_summary.png, trunk_vs_30x_wEQ_rLQ_7kcRPS_22kcWPS.png, > trunk_vs_30x_wEQ_rLQ_7kcRPS_58kcWPS.png, > trunk_vs_30x_wEQ_rLQ_7kcRPS_7kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_108kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_162kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_72kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_7kcWPS.png > > > Tracks evaluating a 192 node cluster with compression and encryption on. > First test is a [read scaling test > |https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=1336583053] > > |Test Setup| | > |Baseline|3.0.19 > @d7d00036| > |Candiate|trunk > @abb0e177| > | | | > |Workload| | > |Write size|4kb random| > |Read size|4kb random| > |Per Node Data|110GiB| > |Generator|ndbench| > |Key Distribution|Uniform| > |SSTable Compr|Off| > |Internode TLS|On (jdk)| > |Internode Compr|On| > |Compaction|LCS (320 MiB)| > |Repair|Off| > | | | > |Hardware| | > |Instance Type|i3.xlarge| > |Deployment|96 us-east-1, 96 eu-west-1| > |Region node count|96| > | | | > |OS Settings| | > |IO scheduler|kyber| > |Net qdisc|tc-fq| > |readahead|32kb| > |Java Version|OpenJDK 1.8.0_202 (Zulu)| > | | | > Second test is a [write scaling > test|https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=428858608]: -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15175) Evaluate 200 node, compression=on, encryption=all
[ https://issues.apache.org/jira/browse/CASSANDRA-15175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Lynch updated CASSANDRA-15175: - Attachment: trunk_vs_30x_wEQ_rLQ_7kcRPS_58kcWPS.png > Evaluate 200 node, compression=on, encryption=all > - > > Key: CASSANDRA-15175 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15175 > Project: Cassandra > Issue Type: Sub-task > Components: Test/benchmark >Reporter: Joseph Lynch >Assignee: Joseph Lynch >Priority: Normal > Attachments: 30x_14400cRPS-14400cWPS.svg, > 30x_LQ_21600cRPS-14400cWPS.svg, ShortbufferExceptions.png, > odd_netty_jdk_tls_cpu_usage.png, trunk_14400cRPS-14400cWPS.svg, > trunk_187000cRPS-14400cWPS.svg, trunk_187kcRPS_14kcWPS.png, > trunk_22000cRPS-14400cWPS-jdk.svg, trunk_22000cRPS-14400cWPS-openssl.svg, > trunk_220kcRPS_14kcWPS.png, trunk_252kcRPS-14kcWPS.png, > trunk_93500cRPS-14400cWPS.svg, trunk_LQ_14400cRPS-14400cWPS.svg, > trunk_LQ_21600cRPS-14400cWPS.svg, trunk_Q_21600cRPS-7200cWPS.svg, > trunk_allocation_Q_21k_cRPS.svg, trunk_vs_30x_125kcRPS_14kcWPS.png, > trunk_vs_30x_14kRPS_14kcWPS_load.png, trunk_vs_30x_14kcRPS_14kcWPS.png, > trunk_vs_30x_14kcRPS_14kcWPS_schedstat_delays.png, > trunk_vs_30x_156kcRPS_14kcWPS.png, trunk_vs_30x_24kcRPS_14kcWPS.png, > trunk_vs_30x_24kcRPS_14kcWPS_load.png, trunk_vs_30x_31kcRPS_14kcWPS.png, > trunk_vs_30x_62kcRPS_14kcWPS.png, trunk_vs_30x_93kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_14kcRPS_14kcWPS.png, trunk_vs_30x_LQ_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_64kcRPS_14kcWPS.png, trunk_vs_30x_LQ_jdk_summary.png, > trunk_vs_30x_LQ_openssl_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_tcnative_summary.png, trunk_vs_30x_Q_21kcRPS_7200cWPS.png, > trunk_vs_30x_Q_36kcRPS_7200cWPS.png, trunk_vs_30x_Q_tcnative_summary.png, > trunk_vs_30x_summary.png, trunk_vs_30x_wEQ_rLQ_7kcRPS_22kcWPS.png, > trunk_vs_30x_wEQ_rLQ_7kcRPS_58kcWPS.png, > trunk_vs_30x_wEQ_rLQ_7kcRPS_7kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_108kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_162kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_72kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_7kcWPS.png > > > Tracks evaluating a 192 node cluster with compression and encryption on. > First test is a [read scaling test > |https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=1336583053] > > |Test Setup| | > |Baseline|3.0.19 > @d7d00036| > |Candiate|trunk > @abb0e177| > | | | > |Workload| | > |Write size|4kb random| > |Read size|4kb random| > |Per Node Data|110GiB| > |Generator|ndbench| > |Key Distribution|Uniform| > |SSTable Compr|Off| > |Internode TLS|On (jdk)| > |Internode Compr|On| > |Compaction|LCS (320 MiB)| > |Repair|Off| > | | | > |Hardware| | > |Instance Type|i3.xlarge| > |Deployment|96 us-east-1, 96 eu-west-1| > |Region node count|96| > | | | > |OS Settings| | > |IO scheduler|kyber| > |Net qdisc|tc-fq| > |readahead|32kb| > |Java Version|OpenJDK 1.8.0_202 (Zulu)| > | | | > Second test is a [write scaling > test|https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=428858608]: -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15175) Evaluate 200 node, compression=on, encryption=all
[ https://issues.apache.org/jira/browse/CASSANDRA-15175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Lynch updated CASSANDRA-15175: - Attachment: trunk_vs_30x_wEQ_rLQ_7kcRPS_58kcWPS.png > Evaluate 200 node, compression=on, encryption=all > - > > Key: CASSANDRA-15175 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15175 > Project: Cassandra > Issue Type: Sub-task > Components: Test/benchmark >Reporter: Joseph Lynch >Assignee: Joseph Lynch >Priority: Normal > Attachments: 30x_14400cRPS-14400cWPS.svg, > 30x_LQ_21600cRPS-14400cWPS.svg, ShortbufferExceptions.png, > odd_netty_jdk_tls_cpu_usage.png, trunk_14400cRPS-14400cWPS.svg, > trunk_187000cRPS-14400cWPS.svg, trunk_187kcRPS_14kcWPS.png, > trunk_22000cRPS-14400cWPS-jdk.svg, trunk_22000cRPS-14400cWPS-openssl.svg, > trunk_220kcRPS_14kcWPS.png, trunk_252kcRPS-14kcWPS.png, > trunk_93500cRPS-14400cWPS.svg, trunk_LQ_14400cRPS-14400cWPS.svg, > trunk_LQ_21600cRPS-14400cWPS.svg, trunk_Q_21600cRPS-7200cWPS.svg, > trunk_allocation_Q_21k_cRPS.svg, trunk_vs_30x_125kcRPS_14kcWPS.png, > trunk_vs_30x_14kRPS_14kcWPS_load.png, trunk_vs_30x_14kcRPS_14kcWPS.png, > trunk_vs_30x_14kcRPS_14kcWPS_schedstat_delays.png, > trunk_vs_30x_156kcRPS_14kcWPS.png, trunk_vs_30x_24kcRPS_14kcWPS.png, > trunk_vs_30x_24kcRPS_14kcWPS_load.png, trunk_vs_30x_31kcRPS_14kcWPS.png, > trunk_vs_30x_62kcRPS_14kcWPS.png, trunk_vs_30x_93kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_14kcRPS_14kcWPS.png, trunk_vs_30x_LQ_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_64kcRPS_14kcWPS.png, trunk_vs_30x_LQ_jdk_summary.png, > trunk_vs_30x_LQ_openssl_21kcRPS_14kcWPS.png, > trunk_vs_30x_LQ_tcnative_summary.png, trunk_vs_30x_Q_21kcRPS_7200cWPS.png, > trunk_vs_30x_Q_36kcRPS_7200cWPS.png, trunk_vs_30x_Q_tcnative_summary.png, > trunk_vs_30x_summary.png, trunk_vs_30x_wEQ_rLQ_7kcRPS_22kcWPS.png, > trunk_vs_30x_wEQ_rLQ_7kcRPS_58kcWPS.png, > trunk_vs_30x_wEQ_rLQ_7kcRPS_7kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_108kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_162kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_72kcWPS.png, > trunk_vs_30x_write_LO_7kcRPS_7kcWPS.png > > > Tracks evaluating a 192 node cluster with compression and encryption on. > First test is a [read scaling test > |https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=1336583053] > > |Test Setup| | > |Baseline|3.0.19 > @d7d00036| > |Candiate|trunk > @abb0e177| > | | | > |Workload| | > |Write size|4kb random| > |Read size|4kb random| > |Per Node Data|110GiB| > |Generator|ndbench| > |Key Distribution|Uniform| > |SSTable Compr|Off| > |Internode TLS|On (jdk)| > |Internode Compr|On| > |Compaction|LCS (320 MiB)| > |Repair|Off| > | | | > |Hardware| | > |Instance Type|i3.xlarge| > |Deployment|96 us-east-1, 96 eu-west-1| > |Region node count|96| > | | | > |OS Settings| | > |IO scheduler|kyber| > |Net qdisc|tc-fq| > |readahead|32kb| > |Java Version|OpenJDK 1.8.0_202 (Zulu)| > | | | > Second test is a [write scaling > test|https://docs.google.com/spreadsheets/d/1Vq_wC2q-rcG7UWim-t2leZZ4GgcuAjSREMFbG0QGy20/edit#gid=428858608]: -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13391) nodetool clearsnapshot should require --all to clear all snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-13391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901389#comment-16901389
]
DeepakVohra commented on CASSANDRA-13391:
-
The help for clearsnapshot needs to be updated to indicate requirement for
--all to remove all snapshots.
{code:java}
[ec2-user@ip-10-0-2-238 ~]$ nodetool help clearsnapshot
NAME nodetool clearsnapshot - Remove the snapshot with the given name
from the given keyspaces. If no snapshotName is specified we will remove
all snapshots{code}
> nodetool clearsnapshot should require --all to clear all snapshots
> --
>
> Key: CASSANDRA-13391
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13391
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Jon Haddad
>Priority: Normal
> Fix For: 4.0
>
>
> Deleting all snapshots by default is insanely dangerous. It would be like if
> rm's default was -rf /.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15259) Selecting Index by Lowest Mean Column Count Selects Random Index
[
https://issues.apache.org/jira/browse/CASSANDRA-15259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Eggleston updated CASSANDRA-15259:
Source Control Link:
https://github.com/apache/cassandra/commit/da8d41f497efedf57e335ec2664680da583a3aba
Status: Resolved (was: Ready to Commit)
Resolution: Fixed
+1, committed to 3.0 as
[da8d41f497efedf57e335ec2664680da583a3aba|https://github.com/apache/cassandra/commit/da8d41f497efedf57e335ec2664680da583a3aba]
and merged up to trunk. Thanks!
> Selecting Index by Lowest Mean Column Count Selects Random Index
>
>
> Key: CASSANDRA-15259
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15259
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Urgent
> Fix For: 3.0.19, 4.0, 3.11.x
>
>
> {{CassandraIndex}} uses
> [{{ColumnFamilyStore#getMeanColumns}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L273],
> average columns per partition, which always returns the same answer for
> index CFs because they contain no regular columns and clustering columns
> aren't included in the count in Cassandra 3.0+.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15259) Selecting Index by Lowest Mean Column Count Selects Random Index
[
https://issues.apache.org/jira/browse/CASSANDRA-15259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Eggleston updated CASSANDRA-15259:
Status: Ready to Commit (was: Changes Suggested)
> Selecting Index by Lowest Mean Column Count Selects Random Index
>
>
> Key: CASSANDRA-15259
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15259
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Urgent
> Fix For: 3.0.19, 4.0, 3.11.x
>
>
> {{CassandraIndex}} uses
> [{{ColumnFamilyStore#getMeanColumns}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L273],
> average columns per partition, which always returns the same answer for
> index CFs because they contain no regular columns and clustering columns
> aren't included in the count in Cassandra 3.0+.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated: Use mean row count instead of mean column count for index selectivity calculation
This is an automated email from the ASF dual-hosted git repository.
bdeggleston pushed a commit to branch cassandra-3.0
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/cassandra-3.0 by this push:
new da8d41f Use mean row count instead of mean column count for index
selectivity calculation
da8d41f is described below
commit da8d41f497efedf57e335ec2664680da583a3aba
Author: Jordan West
AuthorDate: Mon Aug 5 09:44:14 2019 -0700
Use mean row count instead of mean column count for index selectivity
calculation
patch by Jordan West; reviewed by Blake Eggleston for CASSANDRA-15259
---
CHANGES.txt| 1 +
.../cassandra/index/internal/CassandraIndex.java | 21 +-
test/unit/org/apache/cassandra/SchemaLoader.java | 33 ++
.../apache/cassandra/db/SecondaryIndexTest.java| 26 +
4 files changed, 80 insertions(+), 1 deletion(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index f04b489..c2bed92 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
3.0.19
+ * Use mean row count instead of mean column count for index selectivity
calculation (CASSANDRA-15259)
* Avoid updating unchanged gossip states (CASSANDRA-15097)
* Prevent recreation of previously dropped columns with a different kind
(CASSANDRA-14948)
* Prevent client requests from blocking on executor task queue
(CASSANDRA-15013)
diff --git a/src/java/org/apache/cassandra/index/internal/CassandraIndex.java
b/src/java/org/apache/cassandra/index/internal/CassandraIndex.java
index 3211fe9..ad5dd4b 100644
--- a/src/java/org/apache/cassandra/index/internal/CassandraIndex.java
+++ b/src/java/org/apache/cassandra/index/internal/CassandraIndex.java
@@ -278,7 +278,26 @@ public abstract class CassandraIndex implements Index
public long getEstimatedResultRows()
{
-return indexCfs.getMeanColumns();
+long totalRows = 0;
+long totalPartitions = 0;
+for (SSTableReader sstable :
indexCfs.getSSTables(SSTableSet.CANONICAL))
+{
+if (sstable.descriptor.version.storeRows())
+{
+totalPartitions += sstable.getEstimatedPartitionSize().count();
+totalRows += sstable.getTotalRows();
+} else
+{
+// for legacy sstables we don't have a total row count so we
approximate it
+// using estimated column count (which is the same logic as
pre-3.0
+// see CASSANDRA-15259
+long colCount = sstable.getEstimatedColumnCount().count();
+totalPartitions += colCount;
+totalRows += sstable.getEstimatedColumnCount().mean() *
colCount;
+}
+}
+
+return totalPartitions > 0 ? (int) (totalRows / totalPartitions) : 0;
}
/**
diff --git a/test/unit/org/apache/cassandra/SchemaLoader.java
b/test/unit/org/apache/cassandra/SchemaLoader.java
index 1686973..8d61f39 100644
--- a/test/unit/org/apache/cassandra/SchemaLoader.java
+++ b/test/unit/org/apache/cassandra/SchemaLoader.java
@@ -425,6 +425,39 @@ public class SchemaLoader
return cfm.compression(getCompressionParameters());
}
+
+public static CFMetaData compositeMultipleIndexCFMD(String ksName, String
cfName) throws ConfigurationException
+{
+CFMetaData cfm = CFMetaData.Builder.create(ksName, cfName)
+ .addPartitionKey("key",
AsciiType.instance)
+ .addClusteringColumn("c1",
AsciiType.instance)
+ .addRegularColumn("birthdate",
LongType.instance)
+ .addRegularColumn("notbirthdate",
LongType.instance)
+ .build();
+
+cfm.indexes(
+cfm.getIndexes()
+ .with(IndexMetadata.fromIndexTargets(cfm,
+Collections.singletonList(
+new IndexTarget(new
ColumnIdentifier("birthdate", true),
+
IndexTarget.Type.VALUES)),
+"birthdate_key_index",
+
IndexMetadata.Kind.COMPOSITES,
+Collections.EMPTY_MAP))
+ .with(IndexMetadata.fromIndexTargets(cfm,
+Collections.singletonList(
+new IndexTarget(new
ColumnIdentifier("notbirthdate", true),
+
IndexTarget.Type.VALUES)),
+"notbirthdate_key_index",
+
[cassandra] branch trunk updated (2117e2a -> 69b36a5)
This is an automated email from the ASF dual-hosted git repository. bdeggleston pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 2117e2a Make repair coordination less expensive by moving MerkleTrees off heap new da8d41f Use mean row count instead of mean column count for index selectivity calculation new 6b0b792 Merge branch 'cassandra-3.0' into cassandra-3.11 new 69b36a5 Merge branch 'cassandra-3.11' into trunk The 3 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 1 + .../org/apache/cassandra/db/ColumnFamilyStore.java | 13 ++ .../cassandra/index/internal/CassandraIndex.java | 2 +- test/unit/org/apache/cassandra/SchemaLoader.java | 29 ++ .../apache/cassandra/db/SecondaryIndexTest.java| 26 +++ 5 files changed, 70 insertions(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (71cb061 -> 6b0b792)
This is an automated email from the ASF dual-hosted git repository. bdeggleston pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 71cb061 Merge branch 'cassandra-3.0' into cassandra-3.11 new da8d41f Use mean row count instead of mean column count for index selectivity calculation new 6b0b792 Merge branch 'cassandra-3.0' into cassandra-3.11 The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 1 + .../cassandra/index/internal/CassandraIndex.java | 21 - test/unit/org/apache/cassandra/SchemaLoader.java | 35 -- .../apache/cassandra/db/SecondaryIndexTest.java| 26 4 files changed, 80 insertions(+), 3 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into trunk
This is an automated email from the ASF dual-hosted git repository.
bdeggleston pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 69b36a54f764a852ae707597f984b0fd8ae0f6b9
Merge: 2117e2a 6b0b792
Author: Blake Eggleston
AuthorDate: Tue Aug 6 10:22:29 2019 -0700
Merge branch 'cassandra-3.11' into trunk
CHANGES.txt| 1 +
.../org/apache/cassandra/db/ColumnFamilyStore.java | 13 ++
.../cassandra/index/internal/CassandraIndex.java | 2 +-
test/unit/org/apache/cassandra/SchemaLoader.java | 29 ++
.../apache/cassandra/db/SecondaryIndexTest.java| 26 +++
5 files changed, 70 insertions(+), 1 deletion(-)
diff --cc src/java/org/apache/cassandra/db/ColumnFamilyStore.java
index 5414f23,41b5e73..981bc05
--- a/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
+++ b/src/java/org/apache/cassandra/db/ColumnFamilyStore.java
@@@ -2410,6 -2471,6 +2410,19 @@@ public class ColumnFamilyStore implemen
return count > 0 ? sum * 1.0 / count : 0;
}
++public int getMeanRowCount()
++{
++long totalRows = 0;
++long totalPartitions = 0;
++for (SSTableReader sstable : getSSTables(SSTableSet.CANONICAL))
++{
++totalPartitions += sstable.getEstimatedPartitionSize().count();
++totalRows += sstable.getTotalRows();
++}
++
++return totalPartitions > 0 ? (int) (totalRows / totalPartitions) : 0;
++}
++
public long estimateKeys()
{
long n = 0;
diff --cc src/java/org/apache/cassandra/index/internal/CassandraIndex.java
index ecd25fd,e23882f..58056b9
--- a/src/java/org/apache/cassandra/index/internal/CassandraIndex.java
+++ b/src/java/org/apache/cassandra/index/internal/CassandraIndex.java
@@@ -270,7 -270,26 +270,7 @@@ public abstract class CassandraIndex im
public long getEstimatedResultRows()
{
- return indexCfs.getMeanColumns();
-long totalRows = 0;
-long totalPartitions = 0;
-for (SSTableReader sstable :
indexCfs.getSSTables(SSTableSet.CANONICAL))
-{
-if (sstable.descriptor.version.storeRows())
-{
-totalPartitions +=
sstable.getEstimatedPartitionSize().count();
-totalRows += sstable.getTotalRows();
-} else
-{
-// for legacy sstables we don't have a total row count so we
approximate it
-// using estimated column count (which is the same logic as
pre-3.0
-// see CASSANDRA-15259
-long colCount = sstable.getEstimatedColumnCount().count();
-totalPartitions += colCount;
-totalRows += sstable.getEstimatedColumnCount().mean() *
colCount;
-}
-}
-
-return totalPartitions > 0 ? (int) (totalRows / totalPartitions) : 0;
++return indexCfs.getMeanRowCount();
}
/**
diff --cc test/unit/org/apache/cassandra/SchemaLoader.java
index 41f8095,48b8af3..2bc9bda
--- a/test/unit/org/apache/cassandra/SchemaLoader.java
+++ b/test/unit/org/apache/cassandra/SchemaLoader.java
@@@ -461,183 -446,225 +461,212 @@@ public class SchemaLoade
if (withStaticIndex)
{
-cfm.indexes(
-cfm.getIndexes()
- .with(IndexMetadata.fromIndexTargets(cfm,
-
Collections.singletonList(
-new
IndexTarget(new ColumnIdentifier("static", true),
-
IndexTarget.Type.VALUES)),
-"static_index",
-
IndexMetadata.Kind.COMPOSITES,
-
Collections.EMPTY_MAP)));
+indexes.add(IndexMetadata.fromIndexTargets(
+Collections.singletonList(
+ new
IndexTarget(new ColumnIdentifier("static", true),
+
IndexTarget.Type.VALUES)),
+ cfName +
"_static_index",
+
IndexMetadata.Kind.COMPOSITES,
+
Collections.EMPTY_MAP));
}
-return cfm.compression(getCompressionParameters());
+return builder.indexes(indexes.build());
+ }
+
-public static CFMetaData compositeMultipleIndexCFMD(String ksName, String
cfName) throws ConfigurationException
++public static TableMetadata.Builder compositeMultipleIndexCFMD(String
ksName, String cfName)
[cassandra] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository.
bdeggleston pushed a commit to branch cassandra-3.11
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 6b0b792f66fa8dfdf1c8ce814d3f9f012ddb5006
Merge: 71cb061 da8d41f
Author: Blake Eggleston
AuthorDate: Tue Aug 6 10:16:48 2019 -0700
Merge branch 'cassandra-3.0' into cassandra-3.11
CHANGES.txt| 1 +
.../cassandra/index/internal/CassandraIndex.java | 21 -
test/unit/org/apache/cassandra/SchemaLoader.java | 35 --
.../apache/cassandra/db/SecondaryIndexTest.java| 26
4 files changed, 80 insertions(+), 3 deletions(-)
diff --cc CHANGES.txt
index 0233c0f,c2bed92..43dbda3
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,8 -1,5 +1,9 @@@
-3.0.19
+3.11.5
+ * Fix cassandra-env.sh to use $CASSANDRA_CONF to find cassandra-jaas.config
(CASSANDRA-14305)
+ * Fixed nodetool cfstats printing index name twice (CASSANDRA-14903)
+ * Add flag to disable SASI indexes, and warnings on creation
(CASSANDRA-14866)
+Merged from 3.0:
+ * Use mean row count instead of mean column count for index selectivity
calculation (CASSANDRA-15259)
* Avoid updating unchanged gossip states (CASSANDRA-15097)
* Prevent recreation of previously dropped columns with a different kind
(CASSANDRA-14948)
* Prevent client requests from blocking on executor task queue
(CASSANDRA-15013)
diff --cc test/unit/org/apache/cassandra/SchemaLoader.java
index 567da19,8d61f39..48b8af3
--- a/test/unit/org/apache/cassandra/SchemaLoader.java
+++ b/test/unit/org/apache/cassandra/SchemaLoader.java
@@@ -416,15 -401,10 +416,13 @@@ public class SchemaLoade
.build();
}
-public static CFMetaData compositeIndexCFMD(String ksName, String cfName,
boolean withIndex) throws ConfigurationException
+public static CFMetaData compositeIndexCFMD(String ksName, String cfName,
boolean withRegularIndex) throws ConfigurationException
+{
+return compositeIndexCFMD(ksName, cfName, withRegularIndex, false);
+}
+
+public static CFMetaData compositeIndexCFMD(String ksName, String cfName,
boolean withRegularIndex, boolean withStaticIndex) throws ConfigurationException
{
--// the withIndex flag exists to allow tests index creation
--// on existing columns
CFMetaData cfm = CFMetaData.Builder.create(ksName, cfName)
.addPartitionKey("key", AsciiType.instance)
.addClusteringColumn("c1", AsciiType.instance)
@@@ -444,24 -422,42 +442,57 @@@
"birthdate_key_index",
IndexMetadata.Kind.COMPOSITES,
Collections.EMPTY_MAP)));
+}
+
+if (withStaticIndex)
+{
+cfm.indexes(
+cfm.getIndexes()
+ .with(IndexMetadata.fromIndexTargets(cfm,
+
Collections.singletonList(
+new
IndexTarget(new ColumnIdentifier("static", true),
+
IndexTarget.Type.VALUES)),
+"static_index",
+
IndexMetadata.Kind.COMPOSITES,
+
Collections.EMPTY_MAP)));
+}
return cfm.compression(getCompressionParameters());
+ }
+
+ public static CFMetaData compositeMultipleIndexCFMD(String ksName, String
cfName) throws ConfigurationException
+ {
++// the withIndex flag exists to allow tests index creation
++// on existing columns
+ CFMetaData cfm = CFMetaData.Builder.create(ksName, cfName)
+.addPartitionKey("key",
AsciiType.instance)
+.addClusteringColumn("c1",
AsciiType.instance)
+.addRegularColumn("birthdate",
LongType.instance)
+.addRegularColumn("notbirthdate",
LongType.instance)
+.build();
+
+ cfm.indexes(
-cfm.getIndexes()
- .with(IndexMetadata.fromIndexTargets(cfm,
-Collections.singletonList(
-new IndexTarget(new
ColumnIdentifier("birthdate", true),
-
IndexTarget.Type.VALUES)),
-"birthdate_key_index",
-
[jira] [Commented] (CASSANDRA-15225) FileUtils.close() does not handle non-IOException
[
https://issues.apache.org/jira/browse/CASSANDRA-15225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901269#comment-16901269
]
Benedict commented on CASSANDRA-15225:
--
Thanks for the patch [~Override].
There's a third option, namely accumulating the throwable in a {{Throwable}}
variable, and maintaining the single catch clause. We have a utility method,
{{Throwables.maybeFail}} that takes a checked exception class, and rethrows the
exception as its checked-type if possible, or as an unchecked type if possible,
and otherwise wraps it in a {{RuntimeException}}.
Does that sound reasonable to you?
> FileUtils.close() does not handle non-IOException
> -
>
> Key: CASSANDRA-15225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15225
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Benedict
>Assignee: Liudmila Kornilova
>Priority: Normal
> Labels: pull-request-available
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This can lead to {{close}} not being invoked on remaining items
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15232) Arithmetic operators over decimal truncate results
[ https://issues.apache.org/jira/browse/CASSANDRA-15232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901242#comment-16901242 ] Liudmila Kornilova commented on CASSANDRA-15232: Hi, [~benedict] I'll go through the code one more time tomorrow and "Submit patch"! > Arithmetic operators over decimal truncate results > -- > > Key: CASSANDRA-15232 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15232 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Semantics >Reporter: Benedict >Assignee: Liudmila Kornilova >Priority: Normal > Labels: pull-request-available > Fix For: 4.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > The decimal operators hard-code a 128 bit precision for their computations. > Probably a precision needs to be configured or decided somehow, but it’s not > clear why 128bit was chosen. Particularly for multiplication and addition, > it’s very unclear why we truncate, which is different to our behaviour for > e.g. sum() aggregates. Probably for division we should also ensure that we > do not reduce the precision of the two operands. A minimum of decimal128 > seems reasonable, but a maximum does not. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15232) Arithmetic operators over decimal truncate results
[ https://issues.apache.org/jira/browse/CASSANDRA-15232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901240#comment-16901240 ] Benedict commented on CASSANDRA-15232: -- Oh, also, it helps if you "Submit Patch", so I can "Start Review" etc :) > Arithmetic operators over decimal truncate results > -- > > Key: CASSANDRA-15232 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15232 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Semantics >Reporter: Benedict >Assignee: Liudmila Kornilova >Priority: Normal > Labels: pull-request-available > Fix For: 4.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > The decimal operators hard-code a 128 bit precision for their computations. > Probably a precision needs to be configured or decided somehow, but it’s not > clear why 128bit was chosen. Particularly for multiplication and addition, > it’s very unclear why we truncate, which is different to our behaviour for > e.g. sum() aggregates. Probably for division we should also ensure that we > do not reduce the precision of the two operands. A minimum of decimal128 > seems reasonable, but a maximum does not. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15232) Arithmetic operators over decimal truncate results
[
https://issues.apache.org/jira/browse/CASSANDRA-15232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901239#comment-16901239
]
Benedict commented on CASSANDRA-15232:
--
Thanks for the insight [~blerer] :)
[~Override] thanks for the patch. It looks good. I have only one concern,
around division, namely how the scale calculation is now potentially costlier
than the division itself. This may not be a huge problem, but it is a shame,
and it would be nice to mitigate it.
The costliest part is calculating the first digit of each operand - I
personally think it would be acceptable to ignore this part of Postgres'
calculation to avoid introducing the extra garbage and computation.
However, if we do want to retain this part, we should at least avoid performing
it when we know it is of no value - i.e. when the scale of the result is such
that we must ignore the contribution of these digits, because we know for sure
the scale will be overridden by min or max; or when the scales are equal, we
can perform a comparison of the two decimals themselves without extracting the
first digit.
We can _probably_ also make this computation less costly by using
{{BigDecimal.scaleByPowerOfTen}}, if we keep it.
What do you think?
> Arithmetic operators over decimal truncate results
> --
>
> Key: CASSANDRA-15232
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15232
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Semantics
>Reporter: Benedict
>Assignee: Liudmila Kornilova
>Priority: Normal
> Labels: pull-request-available
> Fix For: 4.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The decimal operators hard-code a 128 bit precision for their computations.
> Probably a precision needs to be configured or decided somehow, but it’s not
> clear why 128bit was chosen. Particularly for multiplication and addition,
> it’s very unclear why we truncate, which is different to our behaviour for
> e.g. sum() aggregates. Probably for division we should also ensure that we
> do not reduce the precision of the two operands. A minimum of decimal128
> seems reasonable, but a maximum does not.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15259) Selecting Index by Lowest Mean Column Count Selects Random Index
[
https://issues.apache.org/jira/browse/CASSANDRA-15259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901213#comment-16901213
]
Jordan West commented on CASSANDRA-15259:
-
[~bdeggleston] pushed updates for 3.0 and 3.11. If I'm reading the code right
the legacy sstables aren't supported in trunk so I left the code as is since it
seemed cleaner and generally useful. Happy to change trunk as well though if
you prefer.
> Selecting Index by Lowest Mean Column Count Selects Random Index
>
>
> Key: CASSANDRA-15259
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15259
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Urgent
> Fix For: 3.0.19, 4.0, 3.11.x
>
>
> {{CassandraIndex}} uses
> [{{ColumnFamilyStore#getMeanColumns}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L273],
> average columns per partition, which always returns the same answer for
> index CFs because they contain no regular columns and clustering columns
> aren't included in the count in Cassandra 3.0+.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15259) Selecting Index by Lowest Mean Column Count Selects Random Index
[
https://issues.apache.org/jira/browse/CASSANDRA-15259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901202#comment-16901202
]
Blake Eggleston commented on CASSANDRA-15259:
-
I’m not 100% sure, but I think the math in both methods commute to the same
calculation, in which case I’d prefer {{getMeanRowCount}} for it’s simplicity.
I do agree this should move into {{CassandraIndex}} though, since it’s pretty
specific to that use case.
> Selecting Index by Lowest Mean Column Count Selects Random Index
>
>
> Key: CASSANDRA-15259
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15259
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/2i Index
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Urgent
> Fix For: 3.0.19, 4.0, 3.11.x
>
>
> {{CassandraIndex}} uses
> [{{ColumnFamilyStore#getMeanColumns}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L273],
> average columns per partition, which always returns the same answer for
> index CFs because they contain no regular columns and clustering columns
> aren't included in the count in Cassandra 3.0+.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15246) Add more information around commit message format expected for a patch
[ https://issues.apache.org/jira/browse/CASSANDRA-15246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901195#comment-16901195 ] Benedict commented on CASSANDRA-15246: -- Looks reasonable, but I'm not sure where the docs and website stuff actually lives? The patch doesn't apply to trunk, so after that I'm flummoxed. I would have assumed it would be a modification to docs/source/development/how_to_commit.rst, but honestly I haven't a clue about this side of things. > Add more information around commit message format expected for a patch > -- > > Key: CASSANDRA-15246 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15246 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Sumanth Pasupuleti >Assignee: Sumanth Pasupuleti >Priority: Normal > Fix For: 4.0 > > Attachments: patch_commit_message.patch > > > This is primarily from the suggestion > https://issues.apache.org/jira/browse/CASSANDRA-15013?focusedCommentId=16885255=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16885255, > to have the expected commit message format documented. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15222) BufferedDataOutputStreamPlus.write() should use FastByteOperations.copy()
[ https://issues.apache.org/jira/browse/CASSANDRA-15222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict updated CASSANDRA-15222: - Status: Patch Available (was: Review In Progress) > BufferedDataOutputStreamPlus.write() should use FastByteOperations.copy() > - > > Key: CASSANDRA-15222 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15222 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Local/SSTable, Messaging/Internode >Reporter: Benedict >Assignee: Boris Tsirkin >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.x > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15222) BufferedDataOutputStreamPlus.write() should use FastByteOperations.copy()
[ https://issues.apache.org/jira/browse/CASSANDRA-15222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict updated CASSANDRA-15222: - Status: Open (was: Patch Available) > BufferedDataOutputStreamPlus.write() should use FastByteOperations.copy() > - > > Key: CASSANDRA-15222 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15222 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Local/SSTable, Messaging/Internode >Reporter: Benedict >Assignee: Boris Tsirkin >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.x > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15222) BufferedDataOutputStreamPlus.write() should use FastByteOperations.copy()
[ https://issues.apache.org/jira/browse/CASSANDRA-15222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict updated CASSANDRA-15222: - Resolution: Not A Problem Status: Resolved (was: Open) > BufferedDataOutputStreamPlus.write() should use FastByteOperations.copy() > - > > Key: CASSANDRA-15222 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15222 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Local/SSTable, Messaging/Internode >Reporter: Benedict >Assignee: Boris Tsirkin >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.x > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15222) BufferedDataOutputStreamPlus.write() should use FastByteOperations.copy()
[ https://issues.apache.org/jira/browse/CASSANDRA-15222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict updated CASSANDRA-15222: - Status: Review In Progress (was: Changes Suggested) > BufferedDataOutputStreamPlus.write() should use FastByteOperations.copy() > - > > Key: CASSANDRA-15222 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15222 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Local/SSTable, Messaging/Internode >Reporter: Benedict >Assignee: Boris Tsirkin >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.x > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15222) BufferedDataOutputStreamPlus.write() should use FastByteOperations.copy()
[ https://issues.apache.org/jira/browse/CASSANDRA-15222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901188#comment-16901188 ] Benedict commented on CASSANDRA-15222: -- Ah, [~dotbg], I am really sorry. I have just realised I already made the intended change, as part of CASSANDRA-15066. If you take a look at the difference with 3.x, it will become apparent what I was intending with this ticket. I am sorry for wasting your time, and not looking more closely after you posted the first patch. I hope you engage on another ticket - I promise to look more carefully next time! > BufferedDataOutputStreamPlus.write() should use FastByteOperations.copy() > - > > Key: CASSANDRA-15222 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15222 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction, Local/SSTable, Messaging/Internode >Reporter: Benedict >Assignee: Boris Tsirkin >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.x > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15170) Reduce the time needed to release in-JVM dtest cluster resources after close
[ https://issues.apache.org/jira/browse/CASSANDRA-15170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict updated CASSANDRA-15170: - Test and Documentation Plan: test-only change Status: Patch Available (was: Open) > Reduce the time needed to release in-JVM dtest cluster resources after close > > > Key: CASSANDRA-15170 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15170 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > > There are a few issues that slow the in-JVM dtests from reclaiming metaspace > once the cluster is closed. > IsolatedExecutor issues the shutdown on a SingleExecutorThreadPool, sometimes > this thread was still running 10s after the dtest cluster was closed. > Instead, switch to a ThreadPoolExecutor with a core pool size of 0 so that > the thread executing the class loader close executes sooner. > If an OutboundTcpConnection is waiting to connect() and the endpoint is not > answering, it has to wait for a timeout before it exits. Instead it should > check the isShutdown flag and terminate early if shutdown has been requested. > In 3.0 and above, HintsCatalog.load uses java.nio.Files.list outside of a > try-with-resources construct and leaks a file handle for the directory. This > doesn't matter for normal usage, it leaks a file handle for each dtest > Instance created. > On trunk, Netty global event executor threads are still running and delay GC > for the instance class loader. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15170) Reduce the time needed to release in-JVM dtest cluster resources after close
[ https://issues.apache.org/jira/browse/CASSANDRA-15170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict updated CASSANDRA-15170: - Status: In Progress (was: Patch Available) > Reduce the time needed to release in-JVM dtest cluster resources after close > > > Key: CASSANDRA-15170 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15170 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > > There are a few issues that slow the in-JVM dtests from reclaiming metaspace > once the cluster is closed. > IsolatedExecutor issues the shutdown on a SingleExecutorThreadPool, sometimes > this thread was still running 10s after the dtest cluster was closed. > Instead, switch to a ThreadPoolExecutor with a core pool size of 0 so that > the thread executing the class loader close executes sooner. > If an OutboundTcpConnection is waiting to connect() and the endpoint is not > answering, it has to wait for a timeout before it exits. Instead it should > check the isShutdown flag and terminate early if shutdown has been requested. > In 3.0 and above, HintsCatalog.load uses java.nio.Files.list outside of a > try-with-resources construct and leaks a file handle for the directory. This > doesn't matter for normal usage, it leaks a file handle for each dtest > Instance created. > On trunk, Netty global event executor threads are still running and delay GC > for the instance class loader. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15170) Reduce the time needed to release in-JVM dtest cluster resources after close
[ https://issues.apache.org/jira/browse/CASSANDRA-15170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict updated CASSANDRA-15170: - Complexity: Normal Change Category: Quality Assurance Status: Open (was: Triage Needed) > Reduce the time needed to release in-JVM dtest cluster resources after close > > > Key: CASSANDRA-15170 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15170 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > > There are a few issues that slow the in-JVM dtests from reclaiming metaspace > once the cluster is closed. > IsolatedExecutor issues the shutdown on a SingleExecutorThreadPool, sometimes > this thread was still running 10s after the dtest cluster was closed. > Instead, switch to a ThreadPoolExecutor with a core pool size of 0 so that > the thread executing the class loader close executes sooner. > If an OutboundTcpConnection is waiting to connect() and the endpoint is not > answering, it has to wait for a timeout before it exits. Instead it should > check the isShutdown flag and terminate early if shutdown has been requested. > In 3.0 and above, HintsCatalog.load uses java.nio.Files.list outside of a > try-with-resources construct and leaks a file handle for the directory. This > doesn't matter for normal usage, it leaks a file handle for each dtest > Instance created. > On trunk, Netty global event executor threads are still running and delay GC > for the instance class loader. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15170) Reduce the time needed to release in-JVM dtest cluster resources after close
[
https://issues.apache.org/jira/browse/CASSANDRA-15170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901150#comment-16901150
]
Benedict commented on CASSANDRA-15170:
--
Thanks, the patch looks good overall. I've reviewed the 4.0 branch for now.
{{StreamingInboundHandler}}: We probably shouldn’t assume we cannot leak these
objects, particularly just to enable tests - we should probably store only weak
references if retaining references in a {{static}} collection. It might be
easier overall to instead use a {{ThreadGroup}} here, and simply interrupt all
of the threads in the group. In fact, this might be a cleaner way to manage
all errant threads on a per-node basis.
{{InboundSockets}}: Probably not great to {{awaitTermination}} inside the
listener that may be executed on the {{GlobalEventExecutor}} - which is single
threaded, and whose shutdown order we cannot guarantee. Not actually sure the
best solution to this problem. Perhaps accept an {{executor}} parameter to the
{{close}} method, so that the invoker can consciously guarantee that the
executor can both handle committing a thread to this and also ensure the
executor is not shutdown before its completion. It would be nicer to return a
{{Future}} that logically wraps {{awaitTermination}} without committing a
{{Thread}}, but unfortunately there’s seemingly no clean way to do so; it
should be possible to implement a {{java.util.concurrent.Future}} with only
{{awaitTermination}}, but not an {{io.netty.util.concurrent.Future}}. We could
plausibly have the {{Future}} return a function that accepts a {{nanoTime}}
deadline that invokes {{awaitTermination}}, which might be cleaner, if still
far from optimal.
Some nits:
* SSLFactory
** unused imports (4.0)
** isOpenSslAvailable != openSslIsAvailable?
* {{Ref}}:
** Ignoring parameters (looks to be pre-existing, but propagated bug)
** Marginally cleaner to {{awaitTermination}} of both items together?
Particularly given parameter indicating timeout that we should honour.
* IsolatedExecutor
** unused imports
** unused {{ThreadFactory}} variable
> Reduce the time needed to release in-JVM dtest cluster resources after close
>
>
> Key: CASSANDRA-15170
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15170
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
>
> There are a few issues that slow the in-JVM dtests from reclaiming metaspace
> once the cluster is closed.
> IsolatedExecutor issues the shutdown on a SingleExecutorThreadPool, sometimes
> this thread was still running 10s after the dtest cluster was closed.
> Instead, switch to a ThreadPoolExecutor with a core pool size of 0 so that
> the thread executing the class loader close executes sooner.
> If an OutboundTcpConnection is waiting to connect() and the endpoint is not
> answering, it has to wait for a timeout before it exits. Instead it should
> check the isShutdown flag and terminate early if shutdown has been requested.
> In 3.0 and above, HintsCatalog.load uses java.nio.Files.list outside of a
> try-with-resources construct and leaks a file handle for the directory. This
> doesn't matter for normal usage, it leaks a file handle for each dtest
> Instance created.
> On trunk, Netty global event executor threads are still running and delay GC
> for the instance class loader.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15259) Selecting Index by Lowest Mean Column Count Selects Random Index
[
https://issues.apache.org/jira/browse/CASSANDRA-15259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900575#comment-16900575
]
Jordan West edited comment on CASSANDRA-15259 at 8/6/19 2:43 PM:
-
[~bdeggleston] good catch re: 2.x sstables. I see two ways to handle that off
the top of my head – besides not including the legacy sstables in the
calculation which is broken.
I think I prefer {{getMeanRowCount2}} (average of the row count and column
count) because in the case of 100% legacy sstables or 100% new sstables it
degrades to {{getMeanColumns}} or the original {{getMeanRowCount.}} Neither
implementation is ideal since we have to handle it at the per sstable level and
what that means for an average is ambiguous.
Also, I wonder if the method name should change and/or if the logic should be
moved to somewhere index specific like {{CassandraIndex}}, now that what its
doing is a bit more specialized and less clear. WDYT?
{code:java}
public int getMeanRowCount()
{
long totalRows = 0;
long totalPartitions = 0;
for (SSTableReader sstable : getSSTables(SSTableSet.CANONICAL))
{
if (sstable.descriptor.version.storeRows())
{
totalPartitions += sstable.getEstimatedPartitionSize().count();
totalRows += sstable.getTotalRows();
} else
{
long colCount = sstable.getEstimatedColumnCount().count();
totalPartitions += colCount;
totalRows += sstable.getEstimatedColumnCount().mean() * colCount;
}
}
return totalPartitions > 0 ? (int) (totalRows / totalPartitions) : 0;
}
public int getMeanRowCount2()
{
long totalRows = 0;
long totalPartitions = 0;
long legacyCols = 0;
long legacyTotal = 0;
for (SSTableReader sstable : getSSTables(SSTableSet.CANONICAL))
{
if (sstable.descriptor.version.storeRows())
{
totalPartitions += sstable.getEstimatedPartitionSize().count();
totalRows += sstable.getTotalRows();
} else
{
long colCount = sstable.getEstimatedColumnCount().count();
legacyCols += sstable.getEstimatedColumnCount().mean() * colCount;
legacyTotal += colCount;
}
}
int rowMean = totalPartitions > 0 ? (int) (totalRows / totalPartitions) : 0;
int legacyMean = legacyTotal > 0 ? (int) (legacyCols / legacyTotal) : 0;
return (int) (((rowMean * totalPartitions) + (legacyMean * legacyTotal)) /
(totalPartitions + legacyTotal));
}
{code}
was (Author: jrwest):
[~bdeggleston] good catch re: 2.1 sstables. I see two ways to handle that off
the top of my head – besides not including the legacy sstables in the
calculation which is broken.
I think I prefer {{getMeanRowCount2}} (average of the row count and column
count) because in the case of 100% legacy sstables or 100% new sstables it
degrades to {{getMeanColumns}} or the original {{getMeanRowCount.}} Neither
implementation is ideal since we have to handle it at the per sstable level and
what that means for an average is ambiguous.
Also, I wonder if the method name should change and/or if the logic should be
moved to somewhere index specific like {{CassandraIndex}}, now that what its
doing is a bit more specialized and less clear. WDYT?
{code:java}
public int getMeanRowCount()
{
long totalRows = 0;
long totalPartitions = 0;
for (SSTableReader sstable : getSSTables(SSTableSet.CANONICAL))
{
if (sstable.descriptor.version.storeRows())
{
totalPartitions += sstable.getEstimatedPartitionSize().count();
totalRows += sstable.getTotalRows();
} else
{
long colCount = sstable.getEstimatedColumnCount().count();
totalPartitions += colCount;
totalRows += sstable.getEstimatedColumnCount().mean() * colCount;
}
}
return totalPartitions > 0 ? (int) (totalRows / totalPartitions) : 0;
}
public int getMeanRowCount2()
{
long totalRows = 0;
long totalPartitions = 0;
long legacyCols = 0;
long legacyTotal = 0;
for (SSTableReader sstable : getSSTables(SSTableSet.CANONICAL))
{
if (sstable.descriptor.version.storeRows())
{
totalPartitions += sstable.getEstimatedPartitionSize().count();
totalRows += sstable.getTotalRows();
} else
{
long colCount = sstable.getEstimatedColumnCount().count();
legacyCols += sstable.getEstimatedColumnCount().mean() * colCount;
legacyTotal += colCount;
}
}
int rowMean = totalPartitions > 0 ? (int) (totalRows / totalPartitions) : 0;
int legacyMean = legacyTotal > 0 ? (int) (legacyCols / legacyTotal) : 0;
return (int) (((rowMean * totalPartitions) + (legacyMean * legacyTotal)) /
(totalPartitions + legacyTotal));
}
{code}
> Selecting Index
[jira] [Assigned] (CASSANDRA-15172) LegacyLayout RangeTombstoneList throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-15172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict reassigned CASSANDRA-15172:
Assignee: Benedict
> LegacyLayout RangeTombstoneList throws IndexOutOfBoundsException
>
>
> Key: CASSANDRA-15172
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15172
> Project: Cassandra
> Issue Type: Bug
>Reporter: Shalom
>Assignee: Benedict
>Priority: Normal
>
> Hi All,
> This is the first time I open an issue, so apologies if I'm not following the
> rules properly.
>
> After upgrading a node from version 2.1.21 to 3.11.4, we've started seeing a
> lot of AbstractLocalAwareExecutorService exceptions. This happened right
> after the node successfully started up with the new 3.11.4 binaries.
> INFO [main] 2019-06-05 04:41:37,730 Gossiper.java:1715 - No gossip backlog;
> proceeding
> INFO [main] 2019-06-05 04:41:38,036 NativeTransportService.java:70 - Netty
> using native Epoll event loop
> INFO [main] 2019-06-05 04:41:38,117 Server.java:155 - Using Netty Version:
> [netty-buffer=netty-buffer-4.0.44.Final.452812a,
> netty-codec=netty-codec-4.0.44.Final.452812a,
> netty-codec-haproxy=netty-codec-haproxy-4.0.44.Final.452812a,
> netty-codec-http=netty-codec-http-4.0.44.Final.452812a,
> netty-codec-socks=netty-codec-socks-4.0.44.Final.452812a,
> netty-common=netty-common-4.0.44.Final.452812a,
> netty-handler=netty-handler-4.0.44.Final.452812a,
> netty-tcnative=netty-tcnative-1.1.33.Fork26.142ecbb,
> netty-transport=netty-transport-4.0.44.Final.452812a,
> netty-transport-native-epoll=netty-transport-native-epoll-4.0.44.Final.452812a,
> netty-transport-rxtx=netty-transport-rxtx-4.0.44.Final.452812a,
> netty-transport-sctp=netty-transport-sctp-4.0.44.Final.452812a,
> netty-transport-udt=netty-transport-udt-4.0.44.Final.452812a]
> INFO [main] 2019-06-05 04:41:38,118 Server.java:156 - Starting listening for
> CQL clients on /0.0.0.0:9042 (unencrypted)...
> INFO [main] 2019-06-05 04:41:38,179 CassandraDaemon.java:556 - Not starting
> RPC server as requested. Use JMX (StorageService->startRPCServer()) or
> nodetool (enablethrift) to start it
> INFO [Native-Transport-Requests-21] 2019-06-05 04:41:39,145
> AuthCache.java:161 - (Re)initializing PermissionsCache (validity
> period/update interval/max entries) (2000/2000/1000)
> INFO [OptionalTasks:1] 2019-06-05 04:41:39,729 CassandraAuthorizer.java:409
> - Converting legacy permissions data
> INFO [HANDSHAKE-/10.10.10.8] 2019-06-05 04:41:39,808
> OutboundTcpConnection.java:561 - Handshaking version with /10.10.10.8
> INFO [HANDSHAKE-/10.10.10.9] 2019-06-05 04:41:39,808
> OutboundTcpConnection.java:561 - Handshaking version with /10.10.10.9
> INFO [HANDSHAKE-dc1_02/10.10.10.6] 2019-06-05 04:41:39,809
> OutboundTcpConnection.java:561 - Handshaking version with dc1_02/10.10.10.6
> WARN [ReadStage-2] 2019-06-05 04:41:39,857
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-2,5,main]: {}
> java.lang.ArrayIndexOutOfBoundsException: 1
> at
> org.apache.cassandra.db.AbstractBufferClusteringPrefix.get(AbstractBufferClusteringPrefix.java:55)
> at
> org.apache.cassandra.db.LegacyLayout$LegacyRangeTombstoneList.serializedSizeCompound(LegacyLayout.java:2545)
> at
> org.apache.cassandra.db.LegacyLayout$LegacyRangeTombstoneList.serializedSize(LegacyLayout.java:2522)
> at
> org.apache.cassandra.db.LegacyLayout.serializedSizeAsLegacyPartition(LegacyLayout.java:565)
> at
> org.apache.cassandra.db.ReadResponse$Serializer.serializedSize(ReadResponse.java:446)
> at
> org.apache.cassandra.db.ReadResponse$Serializer.serializedSize(ReadResponse.java:352)
> at
> org.apache.cassandra.net.MessageOut.payloadSize(MessageOut.java:171)
> at
> org.apache.cassandra.net.OutboundTcpConnectionPool.getConnection(OutboundTcpConnectionPool.java:77)
> at
> org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:802)
> at
> org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:953)
> at
> org.apache.cassandra.net.MessagingService.sendReply(MessagingService.java:929)
> at
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:62)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at
>
[jira] [Commented] (CASSANDRA-15261) Improve performance by adding serialize cache in mutation
[
https://issues.apache.org/jira/browse/CASSANDRA-15261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901055#comment-16901055
]
Benedict commented on CASSANDRA-15261:
--
Hi [~sdycreate],
This is in the category of optimisations the project has discussed on a number
of occasions. Am I right in understanding that your proposed solution caches
the _result_ of serialisation, not just its size? Since the latter should
already be cached, particularly in 4.0. This approach would also have some
negative consequences, by increasing the total amount of memory in flight at
any one time, potentially increasing the pressure on GC and exacerbating the
cost of a slow or dying recipient node.
CASSANDRA-9834 would be my starting point here, although it is non-trivial. As
part of this work, serialising to the same format would be valuable, (although
in 4.0 serialization to peers for some data is dependent on the current time in
nanos, so we would need to update this part when serialising to peers). This
has the advantage of _reducing_ in-flight memory usage, by eliminating the need
to maintain the {{Mutation}} object until we receive ACKs for writing hints,
and permits us to (if necessary) temporarily shed message from main-memory for
ordinary delivery, without actually shedding the message itself.
This is a fairly involved piece of work, which is why the project hasn't as yet
undertaken it.
> Improve performance by adding serialize cache in mutation
> -
>
> Key: CASSANDRA-15261
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15261
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Batch Log
>Reporter: Shen dayu
>Priority: Normal
>
> I am trying to add a serialize cache in mutation, for there is so many
> redundant serialization
> # calculate binary size before serialize to binary, this calculation double
> the serialization operation.
> # reuse binary in network message for commitlog, this can reduce a
> serialization operation
> In my test, I use cassandra version is 3.0.14, and it gains 20% performance
> improvement.
> I know cassandra 3.0.x only accept critical bug fixes now.
> So I was wondering any one would review my code if I patch this for 4.0
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15172) LegacyLayout RangeTombstoneList throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-15172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901049#comment-16901049
]
feroz shaik commented on CASSANDRA-15172:
-
Sure, I shall raise a separate request.
> LegacyLayout RangeTombstoneList throws IndexOutOfBoundsException
>
>
> Key: CASSANDRA-15172
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15172
> Project: Cassandra
> Issue Type: Bug
>Reporter: Shalom
>Priority: Normal
>
> Hi All,
> This is the first time I open an issue, so apologies if I'm not following the
> rules properly.
>
> After upgrading a node from version 2.1.21 to 3.11.4, we've started seeing a
> lot of AbstractLocalAwareExecutorService exceptions. This happened right
> after the node successfully started up with the new 3.11.4 binaries.
> INFO [main] 2019-06-05 04:41:37,730 Gossiper.java:1715 - No gossip backlog;
> proceeding
> INFO [main] 2019-06-05 04:41:38,036 NativeTransportService.java:70 - Netty
> using native Epoll event loop
> INFO [main] 2019-06-05 04:41:38,117 Server.java:155 - Using Netty Version:
> [netty-buffer=netty-buffer-4.0.44.Final.452812a,
> netty-codec=netty-codec-4.0.44.Final.452812a,
> netty-codec-haproxy=netty-codec-haproxy-4.0.44.Final.452812a,
> netty-codec-http=netty-codec-http-4.0.44.Final.452812a,
> netty-codec-socks=netty-codec-socks-4.0.44.Final.452812a,
> netty-common=netty-common-4.0.44.Final.452812a,
> netty-handler=netty-handler-4.0.44.Final.452812a,
> netty-tcnative=netty-tcnative-1.1.33.Fork26.142ecbb,
> netty-transport=netty-transport-4.0.44.Final.452812a,
> netty-transport-native-epoll=netty-transport-native-epoll-4.0.44.Final.452812a,
> netty-transport-rxtx=netty-transport-rxtx-4.0.44.Final.452812a,
> netty-transport-sctp=netty-transport-sctp-4.0.44.Final.452812a,
> netty-transport-udt=netty-transport-udt-4.0.44.Final.452812a]
> INFO [main] 2019-06-05 04:41:38,118 Server.java:156 - Starting listening for
> CQL clients on /0.0.0.0:9042 (unencrypted)...
> INFO [main] 2019-06-05 04:41:38,179 CassandraDaemon.java:556 - Not starting
> RPC server as requested. Use JMX (StorageService->startRPCServer()) or
> nodetool (enablethrift) to start it
> INFO [Native-Transport-Requests-21] 2019-06-05 04:41:39,145
> AuthCache.java:161 - (Re)initializing PermissionsCache (validity
> period/update interval/max entries) (2000/2000/1000)
> INFO [OptionalTasks:1] 2019-06-05 04:41:39,729 CassandraAuthorizer.java:409
> - Converting legacy permissions data
> INFO [HANDSHAKE-/10.10.10.8] 2019-06-05 04:41:39,808
> OutboundTcpConnection.java:561 - Handshaking version with /10.10.10.8
> INFO [HANDSHAKE-/10.10.10.9] 2019-06-05 04:41:39,808
> OutboundTcpConnection.java:561 - Handshaking version with /10.10.10.9
> INFO [HANDSHAKE-dc1_02/10.10.10.6] 2019-06-05 04:41:39,809
> OutboundTcpConnection.java:561 - Handshaking version with dc1_02/10.10.10.6
> WARN [ReadStage-2] 2019-06-05 04:41:39,857
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-2,5,main]: {}
> java.lang.ArrayIndexOutOfBoundsException: 1
> at
> org.apache.cassandra.db.AbstractBufferClusteringPrefix.get(AbstractBufferClusteringPrefix.java:55)
> at
> org.apache.cassandra.db.LegacyLayout$LegacyRangeTombstoneList.serializedSizeCompound(LegacyLayout.java:2545)
> at
> org.apache.cassandra.db.LegacyLayout$LegacyRangeTombstoneList.serializedSize(LegacyLayout.java:2522)
> at
> org.apache.cassandra.db.LegacyLayout.serializedSizeAsLegacyPartition(LegacyLayout.java:565)
> at
> org.apache.cassandra.db.ReadResponse$Serializer.serializedSize(ReadResponse.java:446)
> at
> org.apache.cassandra.db.ReadResponse$Serializer.serializedSize(ReadResponse.java:352)
> at
> org.apache.cassandra.net.MessageOut.payloadSize(MessageOut.java:171)
> at
> org.apache.cassandra.net.OutboundTcpConnectionPool.getConnection(OutboundTcpConnectionPool.java:77)
> at
> org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:802)
> at
> org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:953)
> at
> org.apache.cassandra.net.MessagingService.sendReply(MessagingService.java:929)
> at
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:62)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at
>
[jira] [Comment Edited] (CASSANDRA-15172) LegacyLayout RangeTombstoneList throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-15172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901010#comment-16901010
]
Benedict edited comment on CASSANDRA-15172 at 8/6/19 1:11 PM:
--
[~Sagges], sorry for the slow response - I missed the original filing of this
ticket.
[~ferozshaik...@gmail.com] it looks like your bug, while very similar, presents
differently. It would be great if you could file a separate ticket.
Both of these look to be among the category of 2.1->3.0 upgrade bugs involving
range deletions. To best investigate and diagnose, it would be great to start
with information about the affected schema, the kinds of range tombstone
deletes you perform, and preferably if you could pin down sstables that are
affected and upload them somewhere private for us to access. This would help
us investigate much more readily.
Could you also confirm if you utilise thrift, or CQL schema? It's possible
this is a compatibility issue specific to thrift.
was (Author: benedict):
[~Sagges], sorry for the slow response - I missed the original filing of this
ticket.
[~ferozshaik...@gmail.com] it looks like your bug, while very similar, presents
differently. It would be great if you could file a separate ticket.
Both of these look to be among the category of 2.1->3.0 upgrade bugs involving
range deletions. To best investigate and diagnose, it would be great to start
with information about the affected schema, the kinds of range tombstone
deletes you perform, and preferably if you could pin down sstables that are
affected and upload them somewhere private for us to access. This would help
us investigate much more readily.
> LegacyLayout RangeTombstoneList throws IndexOutOfBoundsException
>
>
> Key: CASSANDRA-15172
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15172
> Project: Cassandra
> Issue Type: Bug
>Reporter: Shalom
>Priority: Normal
>
> Hi All,
> This is the first time I open an issue, so apologies if I'm not following the
> rules properly.
>
> After upgrading a node from version 2.1.21 to 3.11.4, we've started seeing a
> lot of AbstractLocalAwareExecutorService exceptions. This happened right
> after the node successfully started up with the new 3.11.4 binaries.
> INFO [main] 2019-06-05 04:41:37,730 Gossiper.java:1715 - No gossip backlog;
> proceeding
> INFO [main] 2019-06-05 04:41:38,036 NativeTransportService.java:70 - Netty
> using native Epoll event loop
> INFO [main] 2019-06-05 04:41:38,117 Server.java:155 - Using Netty Version:
> [netty-buffer=netty-buffer-4.0.44.Final.452812a,
> netty-codec=netty-codec-4.0.44.Final.452812a,
> netty-codec-haproxy=netty-codec-haproxy-4.0.44.Final.452812a,
> netty-codec-http=netty-codec-http-4.0.44.Final.452812a,
> netty-codec-socks=netty-codec-socks-4.0.44.Final.452812a,
> netty-common=netty-common-4.0.44.Final.452812a,
> netty-handler=netty-handler-4.0.44.Final.452812a,
> netty-tcnative=netty-tcnative-1.1.33.Fork26.142ecbb,
> netty-transport=netty-transport-4.0.44.Final.452812a,
> netty-transport-native-epoll=netty-transport-native-epoll-4.0.44.Final.452812a,
> netty-transport-rxtx=netty-transport-rxtx-4.0.44.Final.452812a,
> netty-transport-sctp=netty-transport-sctp-4.0.44.Final.452812a,
> netty-transport-udt=netty-transport-udt-4.0.44.Final.452812a]
> INFO [main] 2019-06-05 04:41:38,118 Server.java:156 - Starting listening for
> CQL clients on /0.0.0.0:9042 (unencrypted)...
> INFO [main] 2019-06-05 04:41:38,179 CassandraDaemon.java:556 - Not starting
> RPC server as requested. Use JMX (StorageService->startRPCServer()) or
> nodetool (enablethrift) to start it
> INFO [Native-Transport-Requests-21] 2019-06-05 04:41:39,145
> AuthCache.java:161 - (Re)initializing PermissionsCache (validity
> period/update interval/max entries) (2000/2000/1000)
> INFO [OptionalTasks:1] 2019-06-05 04:41:39,729 CassandraAuthorizer.java:409
> - Converting legacy permissions data
> INFO [HANDSHAKE-/10.10.10.8] 2019-06-05 04:41:39,808
> OutboundTcpConnection.java:561 - Handshaking version with /10.10.10.8
> INFO [HANDSHAKE-/10.10.10.9] 2019-06-05 04:41:39,808
> OutboundTcpConnection.java:561 - Handshaking version with /10.10.10.9
> INFO [HANDSHAKE-dc1_02/10.10.10.6] 2019-06-05 04:41:39,809
> OutboundTcpConnection.java:561 - Handshaking version with dc1_02/10.10.10.6
> WARN [ReadStage-2] 2019-06-05 04:41:39,857
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-2,5,main]: {}
> java.lang.ArrayIndexOutOfBoundsException: 1
> at
> org.apache.cassandra.db.AbstractBufferClusteringPrefix.get(AbstractBufferClusteringPrefix.java:55)
> at
>
[jira] [Updated] (CASSANDRA-15172) LegacyLayout RangeTombstoneList throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/CASSANDRA-15172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedict updated CASSANDRA-15172:
-
Summary: LegacyLayout RangeTombstoneList throws IndexOutOfBoundsException
(was: AbstractLocalAwareExecutorService Exception During Upgrade to 3.11.4)
> LegacyLayout RangeTombstoneList throws IndexOutOfBoundsException
>
>
> Key: CASSANDRA-15172
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15172
> Project: Cassandra
> Issue Type: Bug
>Reporter: Shalom
>Priority: Normal
>
> Hi All,
> This is the first time I open an issue, so apologies if I'm not following the
> rules properly.
>
> After upgrading a node from version 2.1.21 to 3.11.4, we've started seeing a
> lot of AbstractLocalAwareExecutorService exceptions. This happened right
> after the node successfully started up with the new 3.11.4 binaries.
> INFO [main] 2019-06-05 04:41:37,730 Gossiper.java:1715 - No gossip backlog;
> proceeding
> INFO [main] 2019-06-05 04:41:38,036 NativeTransportService.java:70 - Netty
> using native Epoll event loop
> INFO [main] 2019-06-05 04:41:38,117 Server.java:155 - Using Netty Version:
> [netty-buffer=netty-buffer-4.0.44.Final.452812a,
> netty-codec=netty-codec-4.0.44.Final.452812a,
> netty-codec-haproxy=netty-codec-haproxy-4.0.44.Final.452812a,
> netty-codec-http=netty-codec-http-4.0.44.Final.452812a,
> netty-codec-socks=netty-codec-socks-4.0.44.Final.452812a,
> netty-common=netty-common-4.0.44.Final.452812a,
> netty-handler=netty-handler-4.0.44.Final.452812a,
> netty-tcnative=netty-tcnative-1.1.33.Fork26.142ecbb,
> netty-transport=netty-transport-4.0.44.Final.452812a,
> netty-transport-native-epoll=netty-transport-native-epoll-4.0.44.Final.452812a,
> netty-transport-rxtx=netty-transport-rxtx-4.0.44.Final.452812a,
> netty-transport-sctp=netty-transport-sctp-4.0.44.Final.452812a,
> netty-transport-udt=netty-transport-udt-4.0.44.Final.452812a]
> INFO [main] 2019-06-05 04:41:38,118 Server.java:156 - Starting listening for
> CQL clients on /0.0.0.0:9042 (unencrypted)...
> INFO [main] 2019-06-05 04:41:38,179 CassandraDaemon.java:556 - Not starting
> RPC server as requested. Use JMX (StorageService->startRPCServer()) or
> nodetool (enablethrift) to start it
> INFO [Native-Transport-Requests-21] 2019-06-05 04:41:39,145
> AuthCache.java:161 - (Re)initializing PermissionsCache (validity
> period/update interval/max entries) (2000/2000/1000)
> INFO [OptionalTasks:1] 2019-06-05 04:41:39,729 CassandraAuthorizer.java:409
> - Converting legacy permissions data
> INFO [HANDSHAKE-/10.10.10.8] 2019-06-05 04:41:39,808
> OutboundTcpConnection.java:561 - Handshaking version with /10.10.10.8
> INFO [HANDSHAKE-/10.10.10.9] 2019-06-05 04:41:39,808
> OutboundTcpConnection.java:561 - Handshaking version with /10.10.10.9
> INFO [HANDSHAKE-dc1_02/10.10.10.6] 2019-06-05 04:41:39,809
> OutboundTcpConnection.java:561 - Handshaking version with dc1_02/10.10.10.6
> WARN [ReadStage-2] 2019-06-05 04:41:39,857
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-2,5,main]: {}
> java.lang.ArrayIndexOutOfBoundsException: 1
> at
> org.apache.cassandra.db.AbstractBufferClusteringPrefix.get(AbstractBufferClusteringPrefix.java:55)
> at
> org.apache.cassandra.db.LegacyLayout$LegacyRangeTombstoneList.serializedSizeCompound(LegacyLayout.java:2545)
> at
> org.apache.cassandra.db.LegacyLayout$LegacyRangeTombstoneList.serializedSize(LegacyLayout.java:2522)
> at
> org.apache.cassandra.db.LegacyLayout.serializedSizeAsLegacyPartition(LegacyLayout.java:565)
> at
> org.apache.cassandra.db.ReadResponse$Serializer.serializedSize(ReadResponse.java:446)
> at
> org.apache.cassandra.db.ReadResponse$Serializer.serializedSize(ReadResponse.java:352)
> at
> org.apache.cassandra.net.MessageOut.payloadSize(MessageOut.java:171)
> at
> org.apache.cassandra.net.OutboundTcpConnectionPool.getConnection(OutboundTcpConnectionPool.java:77)
> at
> org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:802)
> at
> org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:953)
> at
> org.apache.cassandra.net.MessagingService.sendReply(MessagingService.java:929)
> at
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:62)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at
>
[jira] [Commented] (CASSANDRA-15172) AbstractLocalAwareExecutorService Exception During Upgrade to 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16901010#comment-16901010
]
Benedict commented on CASSANDRA-15172:
--
[~Sagges], sorry for the slow response - I missed the original filing of this
ticket.
[~ferozshaik...@gmail.com] it looks like your bug, while very similar, presents
differently. It would be great if you could file a separate ticket.
Both of these look to be among the category of 2.1->3.0 upgrade bugs involving
range deletions. To best investigate and diagnose, it would be great to start
with information about the affected schema, the kinds of range tombstone
deletes you perform, and preferably if you could pin down sstables that are
affected and upload them somewhere private for us to access. This would help
us investigate much more readily.
> AbstractLocalAwareExecutorService Exception During Upgrade to 3.11.4
>
>
> Key: CASSANDRA-15172
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15172
> Project: Cassandra
> Issue Type: Bug
>Reporter: Shalom
>Priority: Normal
>
> Hi All,
> This is the first time I open an issue, so apologies if I'm not following the
> rules properly.
>
> After upgrading a node from version 2.1.21 to 3.11.4, we've started seeing a
> lot of AbstractLocalAwareExecutorService exceptions. This happened right
> after the node successfully started up with the new 3.11.4 binaries.
> INFO [main] 2019-06-05 04:41:37,730 Gossiper.java:1715 - No gossip backlog;
> proceeding
> INFO [main] 2019-06-05 04:41:38,036 NativeTransportService.java:70 - Netty
> using native Epoll event loop
> INFO [main] 2019-06-05 04:41:38,117 Server.java:155 - Using Netty Version:
> [netty-buffer=netty-buffer-4.0.44.Final.452812a,
> netty-codec=netty-codec-4.0.44.Final.452812a,
> netty-codec-haproxy=netty-codec-haproxy-4.0.44.Final.452812a,
> netty-codec-http=netty-codec-http-4.0.44.Final.452812a,
> netty-codec-socks=netty-codec-socks-4.0.44.Final.452812a,
> netty-common=netty-common-4.0.44.Final.452812a,
> netty-handler=netty-handler-4.0.44.Final.452812a,
> netty-tcnative=netty-tcnative-1.1.33.Fork26.142ecbb,
> netty-transport=netty-transport-4.0.44.Final.452812a,
> netty-transport-native-epoll=netty-transport-native-epoll-4.0.44.Final.452812a,
> netty-transport-rxtx=netty-transport-rxtx-4.0.44.Final.452812a,
> netty-transport-sctp=netty-transport-sctp-4.0.44.Final.452812a,
> netty-transport-udt=netty-transport-udt-4.0.44.Final.452812a]
> INFO [main] 2019-06-05 04:41:38,118 Server.java:156 - Starting listening for
> CQL clients on /0.0.0.0:9042 (unencrypted)...
> INFO [main] 2019-06-05 04:41:38,179 CassandraDaemon.java:556 - Not starting
> RPC server as requested. Use JMX (StorageService->startRPCServer()) or
> nodetool (enablethrift) to start it
> INFO [Native-Transport-Requests-21] 2019-06-05 04:41:39,145
> AuthCache.java:161 - (Re)initializing PermissionsCache (validity
> period/update interval/max entries) (2000/2000/1000)
> INFO [OptionalTasks:1] 2019-06-05 04:41:39,729 CassandraAuthorizer.java:409
> - Converting legacy permissions data
> INFO [HANDSHAKE-/10.10.10.8] 2019-06-05 04:41:39,808
> OutboundTcpConnection.java:561 - Handshaking version with /10.10.10.8
> INFO [HANDSHAKE-/10.10.10.9] 2019-06-05 04:41:39,808
> OutboundTcpConnection.java:561 - Handshaking version with /10.10.10.9
> INFO [HANDSHAKE-dc1_02/10.10.10.6] 2019-06-05 04:41:39,809
> OutboundTcpConnection.java:561 - Handshaking version with dc1_02/10.10.10.6
> WARN [ReadStage-2] 2019-06-05 04:41:39,857
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-2,5,main]: {}
> java.lang.ArrayIndexOutOfBoundsException: 1
> at
> org.apache.cassandra.db.AbstractBufferClusteringPrefix.get(AbstractBufferClusteringPrefix.java:55)
> at
> org.apache.cassandra.db.LegacyLayout$LegacyRangeTombstoneList.serializedSizeCompound(LegacyLayout.java:2545)
> at
> org.apache.cassandra.db.LegacyLayout$LegacyRangeTombstoneList.serializedSize(LegacyLayout.java:2522)
> at
> org.apache.cassandra.db.LegacyLayout.serializedSizeAsLegacyPartition(LegacyLayout.java:565)
> at
> org.apache.cassandra.db.ReadResponse$Serializer.serializedSize(ReadResponse.java:446)
> at
> org.apache.cassandra.db.ReadResponse$Serializer.serializedSize(ReadResponse.java:352)
> at
> org.apache.cassandra.net.MessageOut.payloadSize(MessageOut.java:171)
> at
> org.apache.cassandra.net.OutboundTcpConnectionPool.getConnection(OutboundTcpConnectionPool.java:77)
> at
> org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:802)
> at
> org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:953)
>
[jira] [Commented] (CASSANDRA-13556) Corrupted SSTables
[
https://issues.apache.org/jira/browse/CASSANDRA-13556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900912#comment-16900912
]
Chakravarthi Manepalli commented on CASSANDRA-13556:
I have observed the same issue in one of our setups. There were no removal or
addition of columns in a recent period. I have observed the stack error in
debug log.
WARN [ReadStage-1] 2019-08-06 16:34:29,093
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
Thread[ReadStage-1,5,main]: {}
java.lang.RuntimeException:
org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
/media/db_store/data/server_data/known_ap_ssid_list-d2cde2f0adf211e99625cd7f2acaf155/mc-5-big-Data.db
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2598)
~[apache-cassandra-3.11.1.jar:3.11.1]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
~[na:1.8.0_152]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
~[apache-cassandra-3.11.1.jar:3.11.1]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
[apache-cassandra-3.11.1.jar:3.11.1]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109)
[apache-cassandra-3.11.1.jar:3.11.1]
at java.lang.Thread.run(Thread.java:748) [na:1.8.0_152]
Caused by: org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted:
/media/db_store/data/server_data/known_ap_ssid_list-d2cde2f0adf211e99625cd7f2acaf155/mc-5-big-Data.db
at
org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:391)
~[apache-cassandra-3.11.1.jar:3.11.1]
at
org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:258)
~[apache-cassandra-3.11.1.jar:3.11.1]
at
org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
~[apache-cassandra-3.11.1.jar:3.11.1]
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:116)
~[apache-cassandra-3.11.1.jar:3.11.1]
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:47)
~[apache-cassandra-3.11.1.jar:3.11.1]
at
org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
~[apache-cassandra-3.11.1.jar:3.11.1]
at
org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:374)
~[apache-cassandra-3.11.1.jar:3.11.1]
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:186)
~[apache-cassandra-3.11.1.jar:3.11.1]
at
org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:155)
~[apache-cassandra-3.11.1.jar:3.11.1]
at
org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
~[apache-cassandra-3.11.1.jar:3.11.1]
at
org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:499)
~[apache-cassandra-3.11.1.jar:3.11.1]
at
org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:359)
~[apache-cassandra-3.11.1.jar:3.11.1]
at
org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
~[apache-cassandra-3.11.1.jar:3.11.1]
at
org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
~[apache-cassandra-3.11.1.jar:3.11.1]
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:136)
~[apache-cassandra-3.11.1.jar:3.11.1]
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:92)
~[apache-cassandra-3.11.1.jar:3.11.1]
at
org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:79)
~[apache-cassandra-3.11.1.jar:3.11.1]
at
org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:308)
~[apache-cassandra-3.11.1.jar:3.11.1]
at
org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:167)
~[apache-cassandra-3.11.1.jar:3.11.1]
at
org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:160)
~[apache-cassandra-3.11.1.jar:3.11.1]
at
org.apache.cassandra.db.ReadResponse$LocalDataResponse.(ReadResponse.java:156)
~[apache-cassandra-3.11.1.jar:3.11.1]
at
[jira] [Commented] (CASSANDRA-15172) AbstractLocalAwareExecutorService Exception During Upgrade to 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900882#comment-16900882
]
feroz shaik commented on CASSANDRA-15172:
-
We have currently isolated this node (cut off thrift , native protocols) and
trying to run upgradesstables to see if it can re-write all the files and stop
logging the below message.
"WARN [ReadStage-6] 2019-08-06 10:44:09,773
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
Thread[ReadStage-6,5,main]: {}
java.lang.NullPointerException: null"
I will keep the thread posted about its outcome,
> AbstractLocalAwareExecutorService Exception During Upgrade to 3.11.4
>
>
> Key: CASSANDRA-15172
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15172
> Project: Cassandra
> Issue Type: Bug
>Reporter: Shalom
>Priority: Normal
>
> Hi All,
> This is the first time I open an issue, so apologies if I'm not following the
> rules properly.
>
> After upgrading a node from version 2.1.21 to 3.11.4, we've started seeing a
> lot of AbstractLocalAwareExecutorService exceptions. This happened right
> after the node successfully started up with the new 3.11.4 binaries.
> INFO [main] 2019-06-05 04:41:37,730 Gossiper.java:1715 - No gossip backlog;
> proceeding
> INFO [main] 2019-06-05 04:41:38,036 NativeTransportService.java:70 - Netty
> using native Epoll event loop
> INFO [main] 2019-06-05 04:41:38,117 Server.java:155 - Using Netty Version:
> [netty-buffer=netty-buffer-4.0.44.Final.452812a,
> netty-codec=netty-codec-4.0.44.Final.452812a,
> netty-codec-haproxy=netty-codec-haproxy-4.0.44.Final.452812a,
> netty-codec-http=netty-codec-http-4.0.44.Final.452812a,
> netty-codec-socks=netty-codec-socks-4.0.44.Final.452812a,
> netty-common=netty-common-4.0.44.Final.452812a,
> netty-handler=netty-handler-4.0.44.Final.452812a,
> netty-tcnative=netty-tcnative-1.1.33.Fork26.142ecbb,
> netty-transport=netty-transport-4.0.44.Final.452812a,
> netty-transport-native-epoll=netty-transport-native-epoll-4.0.44.Final.452812a,
> netty-transport-rxtx=netty-transport-rxtx-4.0.44.Final.452812a,
> netty-transport-sctp=netty-transport-sctp-4.0.44.Final.452812a,
> netty-transport-udt=netty-transport-udt-4.0.44.Final.452812a]
> INFO [main] 2019-06-05 04:41:38,118 Server.java:156 - Starting listening for
> CQL clients on /0.0.0.0:9042 (unencrypted)...
> INFO [main] 2019-06-05 04:41:38,179 CassandraDaemon.java:556 - Not starting
> RPC server as requested. Use JMX (StorageService->startRPCServer()) or
> nodetool (enablethrift) to start it
> INFO [Native-Transport-Requests-21] 2019-06-05 04:41:39,145
> AuthCache.java:161 - (Re)initializing PermissionsCache (validity
> period/update interval/max entries) (2000/2000/1000)
> INFO [OptionalTasks:1] 2019-06-05 04:41:39,729 CassandraAuthorizer.java:409
> - Converting legacy permissions data
> INFO [HANDSHAKE-/10.10.10.8] 2019-06-05 04:41:39,808
> OutboundTcpConnection.java:561 - Handshaking version with /10.10.10.8
> INFO [HANDSHAKE-/10.10.10.9] 2019-06-05 04:41:39,808
> OutboundTcpConnection.java:561 - Handshaking version with /10.10.10.9
> INFO [HANDSHAKE-dc1_02/10.10.10.6] 2019-06-05 04:41:39,809
> OutboundTcpConnection.java:561 - Handshaking version with dc1_02/10.10.10.6
> WARN [ReadStage-2] 2019-06-05 04:41:39,857
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-2,5,main]: {}
> java.lang.ArrayIndexOutOfBoundsException: 1
> at
> org.apache.cassandra.db.AbstractBufferClusteringPrefix.get(AbstractBufferClusteringPrefix.java:55)
> at
> org.apache.cassandra.db.LegacyLayout$LegacyRangeTombstoneList.serializedSizeCompound(LegacyLayout.java:2545)
> at
> org.apache.cassandra.db.LegacyLayout$LegacyRangeTombstoneList.serializedSize(LegacyLayout.java:2522)
> at
> org.apache.cassandra.db.LegacyLayout.serializedSizeAsLegacyPartition(LegacyLayout.java:565)
> at
> org.apache.cassandra.db.ReadResponse$Serializer.serializedSize(ReadResponse.java:446)
> at
> org.apache.cassandra.db.ReadResponse$Serializer.serializedSize(ReadResponse.java:352)
> at
> org.apache.cassandra.net.MessageOut.payloadSize(MessageOut.java:171)
> at
> org.apache.cassandra.net.OutboundTcpConnectionPool.getConnection(OutboundTcpConnectionPool.java:77)
> at
> org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:802)
> at
> org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:953)
> at
> org.apache.cassandra.net.MessagingService.sendReply(MessagingService.java:929)
> at
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:62)
> at
>
[jira] [Commented] (CASSANDRA-15172) AbstractLocalAwareExecutorService Exception During Upgrade to 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900879#comment-16900879
]
feroz shaik commented on CASSANDRA-15172:
-
What we also know is that the nodes suffered some heavy tombstones recently..
could it be under specific condition like "tombstones" plus reading legacy
version files is hitting this problem. [~Sagges] did you cluster have any
tombstone references at all?
> AbstractLocalAwareExecutorService Exception During Upgrade to 3.11.4
>
>
> Key: CASSANDRA-15172
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15172
> Project: Cassandra
> Issue Type: Bug
>Reporter: Shalom
>Priority: Normal
>
> Hi All,
> This is the first time I open an issue, so apologies if I'm not following the
> rules properly.
>
> After upgrading a node from version 2.1.21 to 3.11.4, we've started seeing a
> lot of AbstractLocalAwareExecutorService exceptions. This happened right
> after the node successfully started up with the new 3.11.4 binaries.
> INFO [main] 2019-06-05 04:41:37,730 Gossiper.java:1715 - No gossip backlog;
> proceeding
> INFO [main] 2019-06-05 04:41:38,036 NativeTransportService.java:70 - Netty
> using native Epoll event loop
> INFO [main] 2019-06-05 04:41:38,117 Server.java:155 - Using Netty Version:
> [netty-buffer=netty-buffer-4.0.44.Final.452812a,
> netty-codec=netty-codec-4.0.44.Final.452812a,
> netty-codec-haproxy=netty-codec-haproxy-4.0.44.Final.452812a,
> netty-codec-http=netty-codec-http-4.0.44.Final.452812a,
> netty-codec-socks=netty-codec-socks-4.0.44.Final.452812a,
> netty-common=netty-common-4.0.44.Final.452812a,
> netty-handler=netty-handler-4.0.44.Final.452812a,
> netty-tcnative=netty-tcnative-1.1.33.Fork26.142ecbb,
> netty-transport=netty-transport-4.0.44.Final.452812a,
> netty-transport-native-epoll=netty-transport-native-epoll-4.0.44.Final.452812a,
> netty-transport-rxtx=netty-transport-rxtx-4.0.44.Final.452812a,
> netty-transport-sctp=netty-transport-sctp-4.0.44.Final.452812a,
> netty-transport-udt=netty-transport-udt-4.0.44.Final.452812a]
> INFO [main] 2019-06-05 04:41:38,118 Server.java:156 - Starting listening for
> CQL clients on /0.0.0.0:9042 (unencrypted)...
> INFO [main] 2019-06-05 04:41:38,179 CassandraDaemon.java:556 - Not starting
> RPC server as requested. Use JMX (StorageService->startRPCServer()) or
> nodetool (enablethrift) to start it
> INFO [Native-Transport-Requests-21] 2019-06-05 04:41:39,145
> AuthCache.java:161 - (Re)initializing PermissionsCache (validity
> period/update interval/max entries) (2000/2000/1000)
> INFO [OptionalTasks:1] 2019-06-05 04:41:39,729 CassandraAuthorizer.java:409
> - Converting legacy permissions data
> INFO [HANDSHAKE-/10.10.10.8] 2019-06-05 04:41:39,808
> OutboundTcpConnection.java:561 - Handshaking version with /10.10.10.8
> INFO [HANDSHAKE-/10.10.10.9] 2019-06-05 04:41:39,808
> OutboundTcpConnection.java:561 - Handshaking version with /10.10.10.9
> INFO [HANDSHAKE-dc1_02/10.10.10.6] 2019-06-05 04:41:39,809
> OutboundTcpConnection.java:561 - Handshaking version with dc1_02/10.10.10.6
> WARN [ReadStage-2] 2019-06-05 04:41:39,857
> AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
> Thread[ReadStage-2,5,main]: {}
> java.lang.ArrayIndexOutOfBoundsException: 1
> at
> org.apache.cassandra.db.AbstractBufferClusteringPrefix.get(AbstractBufferClusteringPrefix.java:55)
> at
> org.apache.cassandra.db.LegacyLayout$LegacyRangeTombstoneList.serializedSizeCompound(LegacyLayout.java:2545)
> at
> org.apache.cassandra.db.LegacyLayout$LegacyRangeTombstoneList.serializedSize(LegacyLayout.java:2522)
> at
> org.apache.cassandra.db.LegacyLayout.serializedSizeAsLegacyPartition(LegacyLayout.java:565)
> at
> org.apache.cassandra.db.ReadResponse$Serializer.serializedSize(ReadResponse.java:446)
> at
> org.apache.cassandra.db.ReadResponse$Serializer.serializedSize(ReadResponse.java:352)
> at
> org.apache.cassandra.net.MessageOut.payloadSize(MessageOut.java:171)
> at
> org.apache.cassandra.net.OutboundTcpConnectionPool.getConnection(OutboundTcpConnectionPool.java:77)
> at
> org.apache.cassandra.net.MessagingService.getConnection(MessagingService.java:802)
> at
> org.apache.cassandra.net.MessagingService.sendOneWay(MessagingService.java:953)
> at
> org.apache.cassandra.net.MessagingService.sendReply(MessagingService.java:929)
> at
> org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:62)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
>
[jira] [Commented] (CASSANDRA-15172) AbstractLocalAwareExecutorService Exception During Upgrade to 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900876#comment-16900876
]
feroz shaik commented on CASSANDRA-15172:
-
Full stack trace is as below:
WARN [ReadStage-4] 2019-08-06 02:57:57,408
AbstractLocalAwareExecutorService.java:167 - Uncaught exception on thread
Thread[ReadStage-4,5,main]: {}
java.lang.NullPointerException: null
at
org.apache.cassandra.db.LegacyLayout$LegacyRangeTombstoneList.updateDigest(LegacyLayout.java:2433)
~[apache-cassandra-3.11.4.jar:3.11.4]
at
org.apache.cassandra.db.LegacyLayout$LegacyUnfilteredPartition.digest(LegacyLayout.java:1479)
~[apache-cassandra-3.11.4.jar:3.11.4]
at
org.apache.cassandra.db.rows.UnfilteredRowIterators.digest(UnfilteredRowIterators.java:182)
~[apache-cassandra-3.11.4.jar:3.11.4]
at
org.apache.cassandra.db.partitions.UnfilteredPartitionIterators.digest(UnfilteredPartitionIterators.java:263)
~[apache-cassandra-3.11.4.jar:3.11.4]
at org.apache.cassandra.db.ReadResponse.makeDigest(ReadResponse.java:140)
~[apache-cassandra-3.11.4.jar:3.11.4]
at
org.apache.cassandra.db.ReadResponse.createDigestResponse(ReadResponse.java:87)
~[apache-cassandra-3.11.4.jar:3.11.4]
at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:352)
~[apache-cassandra-3.11.4.jar:3.11.4]
at
org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:50)
~[apache-cassandra-3.11.4.jar:3.11.4]
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:66)
~[apache-cassandra-3.11.4.jar:3.11.4]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
~[na:1.8.0_131]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
~[apache-cassandra-3.11.4.jar:3.11.4]
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
[apache-cassandra-3.11.4.jar:3.11.4]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:114)
[apache-cassandra-3.11.4.jar:3.11.4]
at java.lang.Thread.run(Thread.java:748) [na:1.8.0_131]
> AbstractLocalAwareExecutorService Exception During Upgrade to 3.11.4
>
>
> Key: CASSANDRA-15172
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15172
> Project: Cassandra
> Issue Type: Bug
>Reporter: Shalom
>Priority: Normal
>
> Hi All,
> This is the first time I open an issue, so apologies if I'm not following the
> rules properly.
>
> After upgrading a node from version 2.1.21 to 3.11.4, we've started seeing a
> lot of AbstractLocalAwareExecutorService exceptions. This happened right
> after the node successfully started up with the new 3.11.4 binaries.
> INFO [main] 2019-06-05 04:41:37,730 Gossiper.java:1715 - No gossip backlog;
> proceeding
> INFO [main] 2019-06-05 04:41:38,036 NativeTransportService.java:70 - Netty
> using native Epoll event loop
> INFO [main] 2019-06-05 04:41:38,117 Server.java:155 - Using Netty Version:
> [netty-buffer=netty-buffer-4.0.44.Final.452812a,
> netty-codec=netty-codec-4.0.44.Final.452812a,
> netty-codec-haproxy=netty-codec-haproxy-4.0.44.Final.452812a,
> netty-codec-http=netty-codec-http-4.0.44.Final.452812a,
> netty-codec-socks=netty-codec-socks-4.0.44.Final.452812a,
> netty-common=netty-common-4.0.44.Final.452812a,
> netty-handler=netty-handler-4.0.44.Final.452812a,
> netty-tcnative=netty-tcnative-1.1.33.Fork26.142ecbb,
> netty-transport=netty-transport-4.0.44.Final.452812a,
> netty-transport-native-epoll=netty-transport-native-epoll-4.0.44.Final.452812a,
> netty-transport-rxtx=netty-transport-rxtx-4.0.44.Final.452812a,
> netty-transport-sctp=netty-transport-sctp-4.0.44.Final.452812a,
> netty-transport-udt=netty-transport-udt-4.0.44.Final.452812a]
> INFO [main] 2019-06-05 04:41:38,118 Server.java:156 - Starting listening for
> CQL clients on /0.0.0.0:9042 (unencrypted)...
> INFO [main] 2019-06-05 04:41:38,179 CassandraDaemon.java:556 - Not starting
> RPC server as requested. Use JMX (StorageService->startRPCServer()) or
> nodetool (enablethrift) to start it
> INFO [Native-Transport-Requests-21] 2019-06-05 04:41:39,145
> AuthCache.java:161 - (Re)initializing PermissionsCache (validity
> period/update interval/max entries) (2000/2000/1000)
> INFO [OptionalTasks:1] 2019-06-05 04:41:39,729 CassandraAuthorizer.java:409
> - Converting legacy permissions data
> INFO [HANDSHAKE-/10.10.10.8] 2019-06-05 04:41:39,808
> OutboundTcpConnection.java:561 - Handshaking version with /10.10.10.8
> INFO [HANDSHAKE-/10.10.10.9] 2019-06-05 04:41:39,808
> OutboundTcpConnection.java:561 - Handshaking version with /10.10.10.9
> INFO [HANDSHAKE-dc1_02/10.10.10.6] 2019-06-05 04:41:39,809
>
[jira] [Created] (CASSANDRA-15261) Improve performance by adding serialize cache in mutation
Shen dayu created CASSANDRA-15261: - Summary: Improve performance by adding serialize cache in mutation Key: CASSANDRA-15261 URL: https://issues.apache.org/jira/browse/CASSANDRA-15261 Project: Cassandra Issue Type: Improvement Components: Consistency/Batch Log Reporter: Shen dayu I am trying to add a serialize cache in mutation, for there is so many redundant serialization # calculate binary size before serialize to binary, this calculation double the serialization operation. # reuse binary in network message for commitlog, this can reduce a serialization operation In my test, I use cassandra version is 3.0.14, and it gains 20% performance improvement. I know cassandra 3.0.x only accept critical bug fixes now. So I was wondering any one would review my code if I patch this for 4.0 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
