[jira] [Comment Edited] (CASSANDRA-15146) Transitional TLS server configuration options are overly complex
[
https://issues.apache.org/jira/browse/CASSANDRA-15146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096015#comment-17096015
]
Ekaterina Dimitrova edited comment on CASSANDRA-15146 at 4/30/20, 2:17 AM:
---
+1. I believe this is already part of CASSANDRA-15262.+ *EDIT: * Different
optional, my bad
2. I can add these name changes in CASSANDRA-15234. The actual code for name
change of parameters with backward compatibility is already implemented there.
I have to complete the rest of the ticket this week. (working async on other
things too but this is more or less done)
For completeness, I will link CASSANDRA-15262 and CASSANDRA-15234 to this one.
was (Author: e.dimitrova):
+1. I believe this is already part of CASSANDRA-15262.+ Different optional, my
bad
2. I can add these name changes in CASSANDRA-15234. The actual code for name
change of parameters with backward compatibility is already implemented there.
I have to complete the rest of the ticket this week. (working async on other
things too but this is more or less done)
For completeness, I will link CASSANDRA-15262 and CASSANDRA-15234 to this one.
> Transitional TLS server configuration options are overly complex
>
>
> Key: CASSANDRA-15146
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15146
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption, Local/Config
>Reporter: Joey Lynch
>Assignee: M Carlise
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
>
> It appears as part of the port from transitional client TLS to transitional
> server TLS in CASSANDRA-10404 (the ability to switch a cluster to using
> {{internode_encryption}} without listening on two ports and without downtime)
> we carried the {{enabled}} setting over from the client implementation. I
> believe that the {{enabled}} option is redundant to {{internode_encryption}}
> and {{optional}} and it should therefore be removed prior to the 4.0 release
> where we will have to start respecting that interface.
> Current trunk yaml:
> {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
> {noformat}
> I propose we eliminate {{enabled}} and just use {{optional}} and
> {{internode_encryption}} to determine the listener setup. I also propose we
> change the default of {{optional}} to true. We could also re-name
> {{optional}} since it's a new option but I think it's good to stay consistent
> with the client and use {{optional}}.
> ||optional||internode_encryption||description||
> |true|none|(default) No encryption is used but if a server reaches out with
> it we'll use it|
> |false|dc|Encryption is required for inter-dc communication, but not intra-dc|
> |false|all|Encryption is required for all communication|
> |false|none|We only listen for unencrypted connections|
> |true|dc|Encryption is used for inter-dc communication but is not required|
> |true|all|Encryption is used for all communication but is not required|
> From these states it is clear when we should be accepting TLS connections
> (all except for false and none) as well as when we must enforce it.
> To transition without downtime from an un-encrypted cluster to an encrypted
> cluster the user would do the following:
> 1. After adding valid truststores,
[jira] [Comment Edited] (CASSANDRA-15146) Transitional TLS server configuration options are overly complex
[
https://issues.apache.org/jira/browse/CASSANDRA-15146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096015#comment-17096015
]
Ekaterina Dimitrova edited comment on CASSANDRA-15146 at 4/30/20, 2:16 AM:
---
+1. I believe this is already part of CASSANDRA-15262.+ Different optional, my
bad
2. I can add these name changes in CASSANDRA-15234. The actual code for name
change of parameters with backward compatibility is already implemented there.
I have to complete the rest of the ticket this week. (working async on other
things too but this is more or less done)
For completeness, I will link CASSANDRA-15262 and CASSANDRA-15234 to this one.
was (Author: e.dimitrova):
+1. I believe this is already part of CASSANDRA-15262. + Different optional, my
bad
2. I can add these name changes in CASSANDRA-15234. The actual code for name
change of parameters with backward compatibility is already implemented there.
I have to complete the rest of the ticket this week. (working async on other
things too but this is more or less done)
For completeness, I will link CASSANDRA-15262 and CASSANDRA-15234 to this one.
> Transitional TLS server configuration options are overly complex
>
>
> Key: CASSANDRA-15146
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15146
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption, Local/Config
>Reporter: Joey Lynch
>Assignee: M Carlise
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
>
> It appears as part of the port from transitional client TLS to transitional
> server TLS in CASSANDRA-10404 (the ability to switch a cluster to using
> {{internode_encryption}} without listening on two ports and without downtime)
> we carried the {{enabled}} setting over from the client implementation. I
> believe that the {{enabled}} option is redundant to {{internode_encryption}}
> and {{optional}} and it should therefore be removed prior to the 4.0 release
> where we will have to start respecting that interface.
> Current trunk yaml:
> {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
> {noformat}
> I propose we eliminate {{enabled}} and just use {{optional}} and
> {{internode_encryption}} to determine the listener setup. I also propose we
> change the default of {{optional}} to true. We could also re-name
> {{optional}} since it's a new option but I think it's good to stay consistent
> with the client and use {{optional}}.
> ||optional||internode_encryption||description||
> |true|none|(default) No encryption is used but if a server reaches out with
> it we'll use it|
> |false|dc|Encryption is required for inter-dc communication, but not intra-dc|
> |false|all|Encryption is required for all communication|
> |false|none|We only listen for unencrypted connections|
> |true|dc|Encryption is used for inter-dc communication but is not required|
> |true|all|Encryption is used for all communication but is not required|
> From these states it is clear when we should be accepting TLS connections
> (all except for false and none) as well as when we must enforce it.
> To transition without downtime from an un-encrypted cluster to an encrypted
> cluster the user would do the following:
> 1. After adding valid truststores, change
[jira] [Comment Edited] (CASSANDRA-15146) Transitional TLS server configuration options are overly complex
[
https://issues.apache.org/jira/browse/CASSANDRA-15146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096015#comment-17096015
]
Ekaterina Dimitrova edited comment on CASSANDRA-15146 at 4/30/20, 2:16 AM:
---
+1. I believe this is already part of CASSANDRA-15262. + Different optional, my
bad
2. I can add these name changes in CASSANDRA-15234. The actual code for name
change of parameters with backward compatibility is already implemented there.
I have to complete the rest of the ticket this week. (working async on other
things too but this is more or less done)
For completeness, I will link CASSANDRA-15262 and CASSANDRA-15234 to this one.
was (Author: e.dimitrova):
-1. I believe this is already part of CASSANDRA-15262. - Different optional, my
bad
2. I can add these name changes in CASSANDRA-15234. The actual code for name
change of parameters with backward compatibility is already implemented there.
I have to complete the rest of the ticket this week. (working async on other
things too but this is more or less done)
For completeness, I will link CASSANDRA-15262 and CASSANDRA-15234 to this one.
> Transitional TLS server configuration options are overly complex
>
>
> Key: CASSANDRA-15146
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15146
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption, Local/Config
>Reporter: Joey Lynch
>Assignee: M Carlise
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
>
> It appears as part of the port from transitional client TLS to transitional
> server TLS in CASSANDRA-10404 (the ability to switch a cluster to using
> {{internode_encryption}} without listening on two ports and without downtime)
> we carried the {{enabled}} setting over from the client implementation. I
> believe that the {{enabled}} option is redundant to {{internode_encryption}}
> and {{optional}} and it should therefore be removed prior to the 4.0 release
> where we will have to start respecting that interface.
> Current trunk yaml:
> {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
> {noformat}
> I propose we eliminate {{enabled}} and just use {{optional}} and
> {{internode_encryption}} to determine the listener setup. I also propose we
> change the default of {{optional}} to true. We could also re-name
> {{optional}} since it's a new option but I think it's good to stay consistent
> with the client and use {{optional}}.
> ||optional||internode_encryption||description||
> |true|none|(default) No encryption is used but if a server reaches out with
> it we'll use it|
> |false|dc|Encryption is required for inter-dc communication, but not intra-dc|
> |false|all|Encryption is required for all communication|
> |false|none|We only listen for unencrypted connections|
> |true|dc|Encryption is used for inter-dc communication but is not required|
> |true|all|Encryption is used for all communication but is not required|
> From these states it is clear when we should be accepting TLS connections
> (all except for false and none) as well as when we must enforce it.
> To transition without downtime from an un-encrypted cluster to an encrypted
> cluster the user would do the following:
> 1. After adding valid truststores, change
[jira] [Comment Edited] (CASSANDRA-15146) Transitional TLS server configuration options are overly complex
[
https://issues.apache.org/jira/browse/CASSANDRA-15146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096015#comment-17096015
]
Ekaterina Dimitrova edited comment on CASSANDRA-15146 at 4/30/20, 2:15 AM:
---
-1. I believe this is already part of CASSANDRA-15262. - Different optional, my
bad
2. I can add these name changes in CASSANDRA-15234. The actual code for name
change of parameters with backward compatibility is already implemented there.
I have to complete the rest of the ticket this week. (working async on other
things too but this is more or less done)
For completeness, I will link CASSANDRA-15262 and CASSANDRA-15234 to this one.
was (Author: e.dimitrova):
1. I believe this is already part of CASSANDRA-15262.
2. I can add these name changes in CASSANDRA-15234. The actual code for name
change of parameters with backward compatibility is already implemented there.
I have to complete the rest of the ticket this week. (working async on other
things too but this is more or less done)
For completeness, I will link CASSANDRA-15262 and CASSANDRA-15234 to this one.
> Transitional TLS server configuration options are overly complex
>
>
> Key: CASSANDRA-15146
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15146
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption, Local/Config
>Reporter: Joey Lynch
>Assignee: M Carlise
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
>
> It appears as part of the port from transitional client TLS to transitional
> server TLS in CASSANDRA-10404 (the ability to switch a cluster to using
> {{internode_encryption}} without listening on two ports and without downtime)
> we carried the {{enabled}} setting over from the client implementation. I
> believe that the {{enabled}} option is redundant to {{internode_encryption}}
> and {{optional}} and it should therefore be removed prior to the 4.0 release
> where we will have to start respecting that interface.
> Current trunk yaml:
> {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
> {noformat}
> I propose we eliminate {{enabled}} and just use {{optional}} and
> {{internode_encryption}} to determine the listener setup. I also propose we
> change the default of {{optional}} to true. We could also re-name
> {{optional}} since it's a new option but I think it's good to stay consistent
> with the client and use {{optional}}.
> ||optional||internode_encryption||description||
> |true|none|(default) No encryption is used but if a server reaches out with
> it we'll use it|
> |false|dc|Encryption is required for inter-dc communication, but not intra-dc|
> |false|all|Encryption is required for all communication|
> |false|none|We only listen for unencrypted connections|
> |true|dc|Encryption is used for inter-dc communication but is not required|
> |true|all|Encryption is used for all communication but is not required|
> From these states it is clear when we should be accepting TLS connections
> (all except for false and none) as well as when we must enforce it.
> To transition without downtime from an un-encrypted cluster to an encrypted
> cluster the user would do the following:
> 1. After adding valid truststores, change {{internode_encryption}} to the
[jira] [Commented] (CASSANDRA-15146) Transitional TLS server configuration options are overly complex
[
https://issues.apache.org/jira/browse/CASSANDRA-15146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096015#comment-17096015
]
Ekaterina Dimitrova commented on CASSANDRA-15146:
-
1. I believe this is already part of CASSANDRA-15262.
2. I can add these name changes in CASSANDRA-15234. The actual code for name
change of parameters with backward compatibility is already implemented there.
I have to complete the rest of the ticket this week. (working async on other
things too but this is more or less done)
For completeness, I will link CASSANDRA-15262 and CASSANDRA-15234 to this one.
> Transitional TLS server configuration options are overly complex
>
>
> Key: CASSANDRA-15146
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15146
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Encryption, Local/Config
>Reporter: Joey Lynch
>Assignee: M Carlise
>Priority: Normal
> Fix For: 4.0, 4.0-beta
>
>
> It appears as part of the port from transitional client TLS to transitional
> server TLS in CASSANDRA-10404 (the ability to switch a cluster to using
> {{internode_encryption}} without listening on two ports and without downtime)
> we carried the {{enabled}} setting over from the client implementation. I
> believe that the {{enabled}} option is redundant to {{internode_encryption}}
> and {{optional}} and it should therefore be removed prior to the 4.0 release
> where we will have to start respecting that interface.
> Current trunk yaml:
> {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
> {noformat}
> I propose we eliminate {{enabled}} and just use {{optional}} and
> {{internode_encryption}} to determine the listener setup. I also propose we
> change the default of {{optional}} to true. We could also re-name
> {{optional}} since it's a new option but I think it's good to stay consistent
> with the client and use {{optional}}.
> ||optional||internode_encryption||description||
> |true|none|(default) No encryption is used but if a server reaches out with
> it we'll use it|
> |false|dc|Encryption is required for inter-dc communication, but not intra-dc|
> |false|all|Encryption is required for all communication|
> |false|none|We only listen for unencrypted connections|
> |true|dc|Encryption is used for inter-dc communication but is not required|
> |true|all|Encryption is used for all communication but is not required|
> From these states it is clear when we should be accepting TLS connections
> (all except for false and none) as well as when we must enforce it.
> To transition without downtime from an un-encrypted cluster to an encrypted
> cluster the user would do the following:
> 1. After adding valid truststores, change {{internode_encryption}} to the
> desired level of encryption (recommended {{all}}) and restart Cassandra
> 2. Change {{optional=false}} and restart Cassandra to enforce #1
> If {{optional}} defaulted to {{false}} as it does right now we'd need a third
> restart to first change {{optional}} to {{true}}, which given my
> understanding of the OptionalSslHandler isn't really relevant.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail:
[jira] [Comment Edited] (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:comment-tabpanel=17096003#comment-17096003
]
Ekaterina Dimitrova edited comment on CASSANDRA-15262 at 4/30/20, 1:54 AM:
---
[~jolynch], I am not sure whether you had the opportunity to look at the
failures we talked about last night.
Update on my end:
Currently the following two D-tests fail:
_
_native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl_
_ _TestNodeToNodeSSLEncryption::test_optional_outbound_tls_
- native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl
fails. - _client_encryption_options:optional_ should be set to_ False_ in
_native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl._
- _TestNodeToNodeSSLEncryption::test_optional_outbound_tls_ fails at the point
when we restart node1 with encryption being enabled and plaintext port
shutdown. The inbound connection node2 is refused because of
_InvalidLegacyProtocolMagic: Read 369295616, Expected -900387334_. Making
server_encryption_options:enabled private is not working.
I double-checked the changes with the private variable and they look correct.
This means that there is something more non-trivial? (I am new to this part of
the codebase, probably you might know something more to be considered than the
public to private change)
I don't see an issue with the change of optional to default value of True in
cassandra.yaml but I suggest if we want to setup
_server_encryption_options:enabled_ to _True_ as an immutable value, just to
leave it commented and if the user tries to change it to false - to reject the
change with a warning. We can mark it as Deprecated in the DatabaseDescriptor
as other parameters. I tried simply to comment
server_encryption_options:enabled in cassandra.yaml and the tests are passing.
[~jolynch], considering you mentioned there is already a ticket for improvement
to land in 4.1 which suggests to split _ServerEncryptionOptions_ class from
_EncryptionOptions_ class, I would personally leave this patch in the suggested
way with minimum changes applied to the code as we are in code freeze. WDYT?
was (Author: e.dimitrova):
[~jolynch], I am not sure whether you had the opportunity to look at the
failures we talked about last night.
Update on my end:
Currently the following two D-tests fail:
_
_native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl_
_ _TestNodeToNodeSSLEncryption::test_optional_outbound_tls_
- native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl
fails. - _client_encryption_options:optional_ should be set to_ False_ in
_native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl._
- _TestNodeToNodeSSLEncryption::test_optional_outbound_tls_ fails at the point
when we restart node1 with encryption being enabled and plaintext port
shutdown. The inbound connection node2 is refused because of
_InvalidLegacyProtocolMagic: Read 369295616, Expected -900387334_. Making
server_encryption_options:enabled private is not working.
I double-checked the changes with the private variable and they look correct.
This means that there is something more non-trivial? (I am new to this part of
the codebase, probably you might know something more to be considered than the
public to private change)
I don't see an issue with the change of optional to default value of True in
cassandra.yaml but I suggest if we want to setup
server_encryption_options:enabled to True as a default value, just to leave it
commented and if the user tries to change it to false - to reject the change
with a warning. I tried simply to comment server_encryption_options:enabled in
cassandra.yaml and the tests are passing.
[~jolynch], considering you mentioned there is already a ticket for improvement
to land in 4.1 which suggests to split ServerEncryptionOptions class from
EncryptionOptions class, I would personally leave this patch in the suggested
way with minimum changes applied to the code as we are in code freeze. WDYT?
> 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: Joey Lynch
>Assignee: Joey Lynch
>Priority: Normal
> Fix For: 4.0, 4.0-alpha
>
>
> 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
[jira] [Comment Edited] (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:comment-tabpanel=17096003#comment-17096003
]
Ekaterina Dimitrova edited comment on CASSANDRA-15262 at 4/30/20, 1:50 AM:
---
[~jolynch], I am not sure whether you had the opportunity to look at the
failures we talked about last night.
Update on my end:
Currently the following two D-tests fail:
_
_native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl_
_ _TestNodeToNodeSSLEncryption::test_optional_outbound_tls_
- native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl
fails. - _client_encryption_options:optional_ should be set to_ False_ in
_native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl._
- _TestNodeToNodeSSLEncryption::test_optional_outbound_tls_ fails at the point
when we restart node1 with encryption being enabled and plaintext port
shutdown. The inbound connection node2 is refused because of
_InvalidLegacyProtocolMagic: Read 369295616, Expected -900387334_. Making
server_encryption_options:enabled private is not working.
I double-checked the changes with the private variable and they look correct.
This means that there is something more non-trivial? (I am new to this part of
the codebase, probably you might know something more to be considered than the
public to private change)
I don't see an issue with the change of optional to default value of True in
cassandra.yaml but I suggest if we want to setup
server_encryption_options:enabled to True as a default value, just to leave it
commented and if the user tries to change it to false - to reject the change
with a warning. I tried simply to comment server_encryption_options:enabled in
cassandra.yaml and the tests are passing.
[~jolynch], considering you mentioned there is already a ticket for improvement
to land in 4.1 which suggests to split ServerEncryptionOptions class from
EncryptionOptions class, I would personally leave this patch in the suggested
way with minimum changes applied to the code as we are in code freeze. WDYT?
was (Author: e.dimitrova):
[~jolynch], I am not sure whether you had the opportunity to look at the
failures we talked about last night.
Update on my end:
Currently the following two D-tests fail:
_
_native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl_
_ _TestNodeToNodeSSLEncryption::test_optional_outbound_tls_
- native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl
fails consistently. Making server_encryption_options:enabled private is not
working.
I double-checked the changes with the private variable and they look correct.
This means that there is something more non-trivial? (I am new to this part of
the codebase, probably you might know something more to be considered than the
public to private change)
- _TestNodeToNodeSSLEncryption::test_optional_outbound_tls_ fails at the point
when we restart node1 with encryption being enabled and plaintext port
shutdown. The inbound connection node2 is refused because of
_InvalidLegacyProtocolMagic: Read 369295616, Expected -900387334_.
- _client_encryption_options:optional_ should be set to_ False_ in
_native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl._
I don't see an issue with the change of optional to default value of True in
cassandra.yaml but I suggest if we want to setup
server_encryption_options:enabled to True as a default value, just to leave it
commented and if the user tries to change it to false - to reject the change
with a warning. I tried simply to comment server_encryption_options:enabled in
cassandra.yaml and the tests are passing.
[~jolynch], considering you mentioned there is already a ticket for improvement
to land in 4.1 which suggests to split ServerEncryptionOptions class from
EncryptionOptions class, I would personally leave this patch in the suggested
way with minimum changes applied to the code as we are in code freeze. WDYT?
> 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: Joey Lynch
>Assignee: Joey Lynch
>Priority: Normal
> Fix For: 4.0, 4.0-alpha
>
>
> 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
>
[jira] [Comment Edited] (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:comment-tabpanel=17096003#comment-17096003
]
Ekaterina Dimitrova edited comment on CASSANDRA-15262 at 4/30/20, 1:48 AM:
---
[~jolynch], I am not sure whether you had the opportunity to look at the
failures we talked about last night.
Update on my end:
Currently the following two D-tests fail:
_
_native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl_
- _TestNodeToNodeSSLEncryption::test_optional_outbound_tls_
- native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl
fails consistently. Making server_encryption_options:enabled private is not
working.
I double-checked the changes with the private variable and they look correct.
This means that there is something more non-trivial? (I am new to this part of
the codebase, probably you might know something more to be considered than the
public to private change)
- _TestNodeToNodeSSLEncryption::test_optional_outbound_tls_ fails at the point
when we restart node1 with encryption being enabled and plaintext port
shutdown. The inbound connection node2 is refused because of
_InvalidLegacyProtocolMagic: Read 369295616, Expected -900387334_.
- _client_encryption_options:optional_ should be set to_ False_ in
_native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl._
I don't see an issue with the change of optional to default value of True in
cassandra.yaml but I suggest if we want to setup
server_encryption_options:enabled to True as a default value, just to leave it
commented and if the user tries to change it to false - to reject the change
with a warning. I tried simply to comment server_encryption_options:enabled in
cassandra.yaml and the tests are passing.
[~jolynch], considering you mentioned there is already a ticket for improvement
to land in 4.1 which suggests to split ServerEncryptionOptions class from
EncryptionOptions class, I would personally leave this patch in the suggested
way with minimum changes applied to the code as we are in code freeze. WDYT?
was (Author: e.dimitrova):
[~jolynch], I am not sure whether you had the opportunity to look at the
failures we talked about last night.
Update on my end:
Currently the following two D-tests fail:
_- native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl
- TestNodeToNodeSSLEncryption::test_optional_outbound_tls_
- native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl
fails consistently. Making server_encryption_options:enabled private is not
working.
I double-checked the changes with the private variable and they look correct.
This means that there is something more non-trivial? (I am new to this part of
the codebase, probably you might know something more to be considered than the
public to private change)
- _TestNodeToNodeSSLEncryption::test_optional_outbound_tls_ fails at the point
when we restart node1 with encryption being enabled and plaintext port
shutdown. The inbound connection node2 is refused because of
_InvalidLegacyProtocolMagic: Read 369295616, Expected -900387334_.
- _client_encryption_options:optional_ should be set to_ False_ in
_native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl._
I don't see an issue with the change of optional to default value of True in
cassandra.yaml but I suggest if we want to setup
server_encryption_options:enabled to True as a default value, just to leave it
commented and if the user tries to change it to false - to reject the change
with a warning. I tried simply to comment server_encryption_options:enabled in
cassandra.yaml and the tests are passing.
[~jolynch], considering you mentioned there is already a ticket for improvement
to land in 4.1 which suggests to split ServerEncryptionOptions class from
EncryptionOptions class, I would personally leave this patch in the suggested
way with minimum changes applied to the code as we are in code freeze. WDYT?
> 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: Joey Lynch
>Assignee: Joey Lynch
>Priority: Normal
> Fix For: 4.0, 4.0-alpha
>
>
> 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:
[jira] [Comment Edited] (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:comment-tabpanel=17096003#comment-17096003
]
Ekaterina Dimitrova edited comment on CASSANDRA-15262 at 4/30/20, 1:48 AM:
---
[~jolynch], I am not sure whether you had the opportunity to look at the
failures we talked about last night.
Update on my end:
Currently the following two D-tests fail:
_
_native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl_
_ _TestNodeToNodeSSLEncryption::test_optional_outbound_tls_
- native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl
fails consistently. Making server_encryption_options:enabled private is not
working.
I double-checked the changes with the private variable and they look correct.
This means that there is something more non-trivial? (I am new to this part of
the codebase, probably you might know something more to be considered than the
public to private change)
- _TestNodeToNodeSSLEncryption::test_optional_outbound_tls_ fails at the point
when we restart node1 with encryption being enabled and plaintext port
shutdown. The inbound connection node2 is refused because of
_InvalidLegacyProtocolMagic: Read 369295616, Expected -900387334_.
- _client_encryption_options:optional_ should be set to_ False_ in
_native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl._
I don't see an issue with the change of optional to default value of True in
cassandra.yaml but I suggest if we want to setup
server_encryption_options:enabled to True as a default value, just to leave it
commented and if the user tries to change it to false - to reject the change
with a warning. I tried simply to comment server_encryption_options:enabled in
cassandra.yaml and the tests are passing.
[~jolynch], considering you mentioned there is already a ticket for improvement
to land in 4.1 which suggests to split ServerEncryptionOptions class from
EncryptionOptions class, I would personally leave this patch in the suggested
way with minimum changes applied to the code as we are in code freeze. WDYT?
was (Author: e.dimitrova):
[~jolynch], I am not sure whether you had the opportunity to look at the
failures we talked about last night.
Update on my end:
Currently the following two D-tests fail:
_
_native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl_
- _TestNodeToNodeSSLEncryption::test_optional_outbound_tls_
- native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl
fails consistently. Making server_encryption_options:enabled private is not
working.
I double-checked the changes with the private variable and they look correct.
This means that there is something more non-trivial? (I am new to this part of
the codebase, probably you might know something more to be considered than the
public to private change)
- _TestNodeToNodeSSLEncryption::test_optional_outbound_tls_ fails at the point
when we restart node1 with encryption being enabled and plaintext port
shutdown. The inbound connection node2 is refused because of
_InvalidLegacyProtocolMagic: Read 369295616, Expected -900387334_.
- _client_encryption_options:optional_ should be set to_ False_ in
_native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl._
I don't see an issue with the change of optional to default value of True in
cassandra.yaml but I suggest if we want to setup
server_encryption_options:enabled to True as a default value, just to leave it
commented and if the user tries to change it to false - to reject the change
with a warning. I tried simply to comment server_encryption_options:enabled in
cassandra.yaml and the tests are passing.
[~jolynch], considering you mentioned there is already a ticket for improvement
to land in 4.1 which suggests to split ServerEncryptionOptions class from
EncryptionOptions class, I would personally leave this patch in the suggested
way with minimum changes applied to the code as we are in code freeze. WDYT?
> 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: Joey Lynch
>Assignee: Joey Lynch
>Priority: Normal
> Fix For: 4.0, 4.0-alpha
>
>
> 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
>
[jira] [Commented] (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:comment-tabpanel=17096003#comment-17096003
]
Ekaterina Dimitrova commented on CASSANDRA-15262:
-
[~jolynch], I am not sure whether you had the opportunity to look at the
failures we talked about last night.
Update on my end:
Currently the following two D-tests fail:
_- native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl
- TestNodeToNodeSSLEncryption::test_optional_outbound_tls_
- native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl
fails consistently. Making server_encryption_options:enabled private is not
working.
I double-checked the changes with the private variable and they look correct.
This means that there is something more non-trivial? (I am new to this part of
the codebase, probably you might know something more to be considered than the
public to private change)
- _TestNodeToNodeSSLEncryption::test_optional_outbound_tls_ fails at the point
when we restart node1 with encryption being enabled and plaintext port
shutdown. The inbound connection node2 is refused because of
_InvalidLegacyProtocolMagic: Read 369295616, Expected -900387334_.
- _client_encryption_options:optional_ should be set to_ False_ in
_native_transport_ssl_test.py::TestNativeTransportSSL::test_connect_to_ssl._
I don't see an issue with the change of optional to default value of True in
cassandra.yaml but I suggest if we want to setup
server_encryption_options:enabled to True as a default value, just to leave it
commented and if the user tries to change it to false - to reject the change
with a warning. I tried simply to comment server_encryption_options:enabled in
cassandra.yaml and the tests are passing.
[~jolynch], considering you mentioned there is already a ticket for improvement
to land in 4.1 which suggests to split ServerEncryptionOptions class from
EncryptionOptions class, I would personally leave this patch in the suggested
way with minimum changes applied to the code as we are in code freeze. WDYT?
> 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: Joey Lynch
>Assignee: Joey Lynch
>Priority: Normal
> Fix For: 4.0, 4.0-alpha
>
>
> 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
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15565) Fix flaky test org.apache.cassandra.index.internal.CassandraIndexTest indexCorrectlyMarkedAsBuildAndRemoved
[
https://issues.apache.org/jira/browse/CASSANDRA-15565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17096002#comment-17096002
]
Jordan West commented on CASSANDRA-15565:
-
While reviewing an unrelated patch today I came across a new but similar
failure in this test:
https://circleci.com/gh/jrwest/cassandra/429#tests/containers/56
> Fix flaky test org.apache.cassandra.index.internal.CassandraIndexTest
> indexCorrectlyMarkedAsBuildAndRemoved
> ---
>
> Key: CASSANDRA-15565
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15565
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: David Capwell
>Assignee: Jorge Bay
>Priority: Normal
> Labels: pull-request-available
> Fix For: 3.0.21, 3.11.7, 4.0-alpha
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {code}
> junit.framework.AssertionFailedError: Got more rows than expected. Expected 1
> but got 4.
> at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1098)
> at
> org.apache.cassandra.index.internal.CassandraIndexTest.indexCorrectlyMarkedAsBuildAndRemoved(CassandraIndexTest.java:499)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
> The failure was seen on java 11.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15396) RandomAccessReader does not override skip or skipBytes so will do a lot of disk io when n is large
[ https://issues.apache.org/jira/browse/CASSANDRA-15396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-15396: - Summary: RandomAccessReader does not override skip or skipBytes so will do a lot of disk io when n is large (was: RAR does not override skip or skipBytes so will do a lot of disk io when n is large) > RandomAccessReader does not override skip or skipBytes so will do a lot of > disk io when n is large > -- > > Key: CASSANDRA-15396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15396 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > > RandomAccessReader does not override skip or skipBytes which becomes a > problem when the size of n (the bytes to skip) is larger than a single > buffer; in these cases we can rely on seek to avoid the extra disk io. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15533) Don't allocate unneeded MergeIterator in OnDiskToken#iterator
[
https://issues.apache.org/jira/browse/CASSANDRA-15533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095972#comment-17095972
]
Jordan West edited comment on CASSANDRA-15533 at 4/30/20, 12:03 AM:
Thanks for taking a look [~Bereng] [~blerer]. I spoke with [~bdeggleston] and
while this patch works, we'd like to extend it to other cases where allocating
a {{MergeIterator}} is unnecessary besides SASI. That said, we can split that
out in the spirit of getting this closed for 4.0.
was (Author: jrwest):
Thanks for taking a look [~Bereng] [~blerer]. I had spoken with [~bdeggleston]
and while this patch works, we'd like to extend it to other cases where
allocating a {{MergeIterator}} is unnecessary besides SASI. That said, we can
split that out in the spirit of getting this closed for 4.0.
> Don't allocate unneeded MergeIterator in OnDiskToken#iterator
> --
>
> Key: CASSANDRA-15533
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15533
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SASI
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0, 4.0-rc
>
>
> When reviewing CASSANDRA-15392 it became apparent that the MergeIterator
> allocated by OnDiskToken#iterator is rarely necessary and so we should avoid
> allocating one when not needed and skip the MergeIterator pool when needed
> because its unlikely to be sized correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15533) Don't allocate unneeded MergeIterator in OnDiskToken#iterator
[
https://issues.apache.org/jira/browse/CASSANDRA-15533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095972#comment-17095972
]
Jordan West commented on CASSANDRA-15533:
-
Thanks for taking a look [~Bereng] [~blerer]. I had spoken with [~bdeggleston]
and while this patch works, we'd like to extend it to other cases where
allocating a {{MergeIterator}} is unnecessary besides SASI. That said, we can
split that out in the spirit of getting this closed for 4.0.
> Don't allocate unneeded MergeIterator in OnDiskToken#iterator
> --
>
> Key: CASSANDRA-15533
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15533
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/SASI
>Reporter: Jordan West
>Assignee: Jordan West
>Priority: Normal
> Fix For: 4.0, 4.0-rc
>
>
> When reviewing CASSANDRA-15392 it became apparent that the MergeIterator
> allocated by OnDiskToken#iterator is rarely necessary and so we should avoid
> allocating one when not needed and skip the MergeIterator pool when needed
> because its unlikely to be sized correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15775) Configuration to disallow queries with "allow filtering"
[ https://issues.apache.org/jira/browse/CASSANDRA-15775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095919#comment-17095919 ] David Capwell commented on CASSANDRA-15775: --- yep, or allow at the table level only. > Configuration to disallow queries with "allow filtering" > > > Key: CASSANDRA-15775 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15775 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Local Write-Read Paths >Reporter: Christian Fredriksson >Priority: Normal > > Problem: We have inexperienced developers not following guidelines or best > pratices who do queries with "allow filtering" which have negative impact on > performance on other queries and developers. > It would be beneficial to have a (server side) configuration to disallow > these queries altogether. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15775) Configuration to disallow queries with "allow filtering"
[ https://issues.apache.org/jira/browse/CASSANDRA-15775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095891#comment-17095891 ] Brandon Williams commented on CASSANDRA-15775: -- I agree, we just need to be sure to include a warning that any analytical queries (such as Spark) will fail with it disabled. > Configuration to disallow queries with "allow filtering" > > > Key: CASSANDRA-15775 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15775 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Local Write-Read Paths >Reporter: Christian Fredriksson >Priority: Normal > > Problem: We have inexperienced developers not following guidelines or best > pratices who do queries with "allow filtering" which have negative impact on > performance on other queries and developers. > It would be beneficial to have a (server side) configuration to disallow > these queries altogether. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15396) RAR does not override skip or skipBytes so will do a lot of disk io when n is large
[ https://issues.apache.org/jira/browse/CASSANDRA-15396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095889#comment-17095889 ] David Capwell commented on CASSANDRA-15396: --- ||PR||tests|| |[link|https://github.com/apache/cassandra/pull/378]|[link|https://circleci.com/gh/dcapwell/workflows/cassandra/tree/randomAccessReaderSkipBytes]| In my testing, the following cases improve by relying on seek: 1) compressed data (avoid decompressing when not needed) 2) non-mmap data (avoid the extra extra io) The cases which did not improve noticeably (but also did not regress): 1) mmap data which is in the page cache (mmap rebuffer doesn’t copy into buffers, instead switches the position of the buffer. This patch lowers the amount of times we update the buffer position) Plan to run stress tests as well, but still learning the Data.db read path to figure out which patterns call .skipByte* > RAR does not override skip or skipBytes so will do a lot of disk io when n is > large > --- > > Key: CASSANDRA-15396 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15396 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > > RandomAccessReader does not override skip or skipBytes which becomes a > problem when the size of n (the bytes to skip) is larger than a single > buffer; in these cases we can rely on seek to avoid the extra disk io. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-22) RESTEasy integration for Cassandra Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095880#comment-17095880 ] Jon Haddad commented on CASSANDRASC-22: --- Great patch Dinesh. I have a single request which I left on the PR: [https://github.com/apache/cassandra-sidecar/pull/13#pullrequestreview-402999246] Feel free to merge afterwards. > RESTEasy integration for Cassandra Sidecar > -- > > Key: CASSANDRASC-22 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-22 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Dinesh Joshi >Assignee: Dinesh Joshi >Priority: Normal > Attachments: image-2020-04-27-22-59-40-060.png, > image-2020-04-29-01-14-11-756.png, image-2020-04-29-10-33-37-196.png, > image-2020-04-29-13-33-13-467.png, image-2020-04-29-13-33-43-069.png, > image-2020-04-29-13-35-17-071.png, image-2020-04-29-13-35-29-981.png > > > Add support for JAX-RS based routing via RESTEasy to Cassandra Sidecar. This > also dynamically generates swagger documentation and adds the swagger UI. > [Branch|https://github.com/dineshjoshi/cassandra-sidecar/tree/resteasy-swagger] > [Tests|https://circleci.com/workflow-run/a7888146-a22d-45af-983a-8833b77eef59] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-22) RESTEasy integration for Cassandra Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Haddad updated CASSANDRASC-22: -- Attachment: image-2020-04-29-13-35-29-981.png > RESTEasy integration for Cassandra Sidecar > -- > > Key: CASSANDRASC-22 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-22 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Dinesh Joshi >Assignee: Dinesh Joshi >Priority: Normal > Attachments: image-2020-04-27-22-59-40-060.png, > image-2020-04-29-01-14-11-756.png, image-2020-04-29-10-33-37-196.png, > image-2020-04-29-13-33-13-467.png, image-2020-04-29-13-33-43-069.png, > image-2020-04-29-13-35-17-071.png, image-2020-04-29-13-35-29-981.png > > > Add support for JAX-RS based routing via RESTEasy to Cassandra Sidecar. This > also dynamically generates swagger documentation and adds the swagger UI. > [Branch|https://github.com/dineshjoshi/cassandra-sidecar/tree/resteasy-swagger] > [Tests|https://circleci.com/workflow-run/a7888146-a22d-45af-983a-8833b77eef59] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-22) RESTEasy integration for Cassandra Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Haddad updated CASSANDRASC-22: -- Attachment: image-2020-04-29-13-35-17-071.png > RESTEasy integration for Cassandra Sidecar > -- > > Key: CASSANDRASC-22 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-22 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Dinesh Joshi >Assignee: Dinesh Joshi >Priority: Normal > Attachments: image-2020-04-27-22-59-40-060.png, > image-2020-04-29-01-14-11-756.png, image-2020-04-29-10-33-37-196.png, > image-2020-04-29-13-33-13-467.png, image-2020-04-29-13-33-43-069.png, > image-2020-04-29-13-35-17-071.png, image-2020-04-29-13-35-29-981.png > > > Add support for JAX-RS based routing via RESTEasy to Cassandra Sidecar. This > also dynamically generates swagger documentation and adds the swagger UI. > [Branch|https://github.com/dineshjoshi/cassandra-sidecar/tree/resteasy-swagger] > [Tests|https://circleci.com/workflow-run/a7888146-a22d-45af-983a-8833b77eef59] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-22) RESTEasy integration for Cassandra Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Haddad updated CASSANDRASC-22: -- Attachment: image-2020-04-29-13-33-43-069.png > RESTEasy integration for Cassandra Sidecar > -- > > Key: CASSANDRASC-22 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-22 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Dinesh Joshi >Assignee: Dinesh Joshi >Priority: Normal > Attachments: image-2020-04-27-22-59-40-060.png, > image-2020-04-29-01-14-11-756.png, image-2020-04-29-10-33-37-196.png, > image-2020-04-29-13-33-13-467.png, image-2020-04-29-13-33-43-069.png > > > Add support for JAX-RS based routing via RESTEasy to Cassandra Sidecar. This > also dynamically generates swagger documentation and adds the swagger UI. > [Branch|https://github.com/dineshjoshi/cassandra-sidecar/tree/resteasy-swagger] > [Tests|https://circleci.com/workflow-run/a7888146-a22d-45af-983a-8833b77eef59] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-22) RESTEasy integration for Cassandra Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Haddad updated CASSANDRASC-22: -- Attachment: image-2020-04-29-13-33-13-467.png > RESTEasy integration for Cassandra Sidecar > -- > > Key: CASSANDRASC-22 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-22 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Dinesh Joshi >Assignee: Dinesh Joshi >Priority: Normal > Attachments: image-2020-04-27-22-59-40-060.png, > image-2020-04-29-01-14-11-756.png, image-2020-04-29-10-33-37-196.png, > image-2020-04-29-13-33-13-467.png, image-2020-04-29-13-33-43-069.png > > > Add support for JAX-RS based routing via RESTEasy to Cassandra Sidecar. This > also dynamically generates swagger documentation and adds the swagger UI. > [Branch|https://github.com/dineshjoshi/cassandra-sidecar/tree/resteasy-swagger] > [Tests|https://circleci.com/workflow-run/a7888146-a22d-45af-983a-8833b77eef59] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15674) liveDiskSpaceUsed and totalDiskSpaceUsed get corrupted if IndexSummaryRedistribution gets interrupted
[ https://issues.apache.org/jira/browse/CASSANDRA-15674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095868#comment-17095868 ] David Capwell commented on CASSANDRA-15674: --- The trunk build Python dtests failed because of CASSANDRA-15776, sent out patch to fix those (unrelated to this one). > liveDiskSpaceUsed and totalDiskSpaceUsed get corrupted if > IndexSummaryRedistribution gets interrupted > - > > Key: CASSANDRA-15674 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15674 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction, Observability/Metrics >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-alpha > > > IndexSummaryRedistribution is a compaction task and as such extends Holder > and supports cancelation by throwing a CompactionInterruptedException. The > issue is that IndexSummaryRedistribution tries to use transactions, but > mutates the sstable in-place; transaction is unable to roll back. > This would be fine (only updates summary) if it wasn’t for the fact the task > attempts to also mutate the two metrics liveDiskSpaceUsed and > totalDiskSpaceUsed, since these can’t be rolled back any cancelation could > corrupt these metrics. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15674) liveDiskSpaceUsed and totalDiskSpaceUsed get corrupted if IndexSummaryRedistribution gets interrupted
[ https://issues.apache.org/jira/browse/CASSANDRA-15674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17094973#comment-17094973 ] David Capwell edited comment on CASSANDRA-15674 at 4/29/20, 8:16 PM: - Patches per version ||branch||link||CI|CI Results| |trunk|[Git Hub PR|https://github.com/apache/cassandra/pull/500]|[Circle CI|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=bug%2FnegativeDiskSpace]|YELLOW| |3.11|[Git Hub|https://github.com/dcapwell/cassandra/tree/bug/negativeDiskSpace-3.11]|[Circle CI|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=bug%2FnegativeDiskSpace-3.11]|GREEN| |3.0|[Git Hub|https://github.com/dcapwell/cassandra/tree/bug/negativeDiskSpace-3.0]|[Circle CI|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=bug%2FnegativeDiskSpace-3.0]|GREEN| was (Author: dcapwell): Patches per version ||branch||link||CI|CI Results| |trunk|[Git Hub PR|https://github.com/apache/cassandra/pull/500]|[Circle CI|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=bug%2FnegativeDiskSpace]|UNKNOWN| |3.11|[Git Hub|https://github.com/dcapwell/cassandra/tree/bug/negativeDiskSpace-3.11]|[Circle CI|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=bug%2FnegativeDiskSpace-3.11]|GREEN| |3.0|[Git Hub|https://github.com/dcapwell/cassandra/tree/bug/negativeDiskSpace-3.0]|[Circle CI|https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=bug%2FnegativeDiskSpace-3.0]|GREEN| > liveDiskSpaceUsed and totalDiskSpaceUsed get corrupted if > IndexSummaryRedistribution gets interrupted > - > > Key: CASSANDRA-15674 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15674 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction, Observability/Metrics >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-alpha > > > IndexSummaryRedistribution is a compaction task and as such extends Holder > and supports cancelation by throwing a CompactionInterruptedException. The > issue is that IndexSummaryRedistribution tries to use transactions, but > mutates the sstable in-place; transaction is unable to roll back. > This would be fine (only updates summary) if it wasn’t for the fact the task > attempts to also mutate the two metrics liveDiskSpaceUsed and > totalDiskSpaceUsed, since these can’t be rolled back any cancelation could > corrupt these metrics. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15776) python dtest regression caused by CASSANDRA-15637
[ https://issues.apache.org/jira/browse/CASSANDRA-15776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRA-15776: - Reviewers: Dinesh Joshi > python dtest regression caused by CASSANDRA-15637 > - > > Key: CASSANDRA-15776 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15776 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-alpha > > Time Spent: 10m > Remaining Estimate: 0h > > CASSANDRA-15637 deprecated size_estimates in favor of table_estimates to > allow for local primary range estimates (needed for MapReduce). This appears > to have caused a regression in the python dtest nodetool_test.TestNodetool. > test_refresh_size_estimates_clears_invalid_entries (as seen by [Circle > CI|https://app.circleci.com/pipelines/github/dcapwell/cassandra/255/workflows/21907001-93ed-4963-9314-6a0ac6ea0f1d/jobs/1246/tests] > and > [Jenkins|https://ci-cassandra.apache.org/job/Cassandra-trunk-dtest/56/]). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15776) python dtest regression caused by CASSANDRA-15637
[ https://issues.apache.org/jira/browse/CASSANDRA-15776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095841#comment-17095841 ] David Capwell edited comment on CASSANDRA-15776 at 4/29/20, 8:12 PM: - [Circle CI BranchI| https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=bug%2FCASSANDRA-15776] [Circle CI Workflow|https://app.circleci.com/pipelines/github/dcapwell/cassandra/261/workflows/fb90e467-0703-45b2-abf0-3a4b45208091] - tests passing was (Author: dcapwell): [Circle CI| https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=bug%2FCASSANDRA-15776] > python dtest regression caused by CASSANDRA-15637 > - > > Key: CASSANDRA-15776 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15776 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-alpha > > Time Spent: 10m > Remaining Estimate: 0h > > CASSANDRA-15637 deprecated size_estimates in favor of table_estimates to > allow for local primary range estimates (needed for MapReduce). This appears > to have caused a regression in the python dtest nodetool_test.TestNodetool. > test_refresh_size_estimates_clears_invalid_entries (as seen by [Circle > CI|https://app.circleci.com/pipelines/github/dcapwell/cassandra/255/workflows/21907001-93ed-4963-9314-6a0ac6ea0f1d/jobs/1246/tests] > and > [Jenkins|https://ci-cassandra.apache.org/job/Cassandra-trunk-dtest/56/]). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-14781) Log message when mutation passed to CommitLog#add(Mutation) is too large is not descriptive enough
[ https://issues.apache.org/jira/browse/CASSANDRA-14781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi reassigned CASSANDRA-14781: Assignee: Venkata Harikrishna Nukala (was: Tom Petracca) > Log message when mutation passed to CommitLog#add(Mutation) is too large is > not descriptive enough > -- > > Key: CASSANDRA-14781 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14781 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Hints, Local/Commit Log, Messaging/Client >Reporter: Jordan West >Assignee: Venkata Harikrishna Nukala >Priority: Normal > Labels: protocolv5 > Fix For: 4.0-beta > > Attachments: CASSANDRA-14781.patch, CASSANDRA-14781_3.0.patch, > CASSANDRA-14781_3.11.patch > > > When hitting > [https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/commitlog/CommitLog.java#L256-L257], > the log message produced does not help the operator track down what data is > being written. At a minimum the keyspace and cfIds involved would be useful > (and are available) – more detail might not be reasonable to include. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15775) Configuration to disallow queries with "allow filtering"
[ https://issues.apache.org/jira/browse/CASSANDRA-15775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095864#comment-17095864 ] David Capwell commented on CASSANDRA-15775: --- This would be helpful as a means to keep the DB stable. > Configuration to disallow queries with "allow filtering" > > > Key: CASSANDRA-15775 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15775 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Local Write-Read Paths >Reporter: Christian Fredriksson >Priority: Normal > > Problem: We have inexperienced developers not following guidelines or best > pratices who do queries with "allow filtering" which have negative impact on > performance on other queries and developers. > It would be beneficial to have a (server side) configuration to disallow > these queries altogether. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15775) Configuration to disallow queries with "allow filtering"
[ https://issues.apache.org/jira/browse/CASSANDRA-15775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15775: -- Change Category: Operability Complexity: Low Hanging Fruit Component/s: Legacy/Local Write-Read Paths Status: Open (was: Triage Needed) > Configuration to disallow queries with "allow filtering" > > > Key: CASSANDRA-15775 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15775 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Local Write-Read Paths >Reporter: Christian Fredriksson >Priority: Normal > > Problem: We have inexperienced developers not following guidelines or best > pratices who do queries with "allow filtering" which have negative impact on > performance on other queries and developers. > It would be beneficial to have a (server side) configuration to disallow > these queries altogether. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15729) Jenkins Test Results Report in plaintext for ASF ML
[ https://issues.apache.org/jira/browse/CASSANDRA-15729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095846#comment-17095846 ] Michael Semb Wever commented on CASSANDRA-15729: Example cqlshlib test reports: - https://ci-cassandra.apache.org/job/Cassandra-3.0-cqlsh-tests/19/testReport/ - https://ci-cassandra.apache.org/job/Cassandra-3.11-cqlsh-tests/22/testReport/ - https://ci-cassandra.apache.org/job/Cassandra-trunk-cqlsh-tests/101/testReport/ > Jenkins Test Results Report in plaintext for ASF ML > --- > > Key: CASSANDRA-15729 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15729 > Project: Cassandra > Issue Type: Task > Components: Build, CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Labels: Jenkins > Fix For: 4.0-beta > > > The Jenkins pipeline builds now aggregate all test reports. > For example: > - https://ci-cassandra.apache.org/job/Cassandra-trunk/68/testReport/ > - > https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-trunk/detail/Cassandra-trunk/68/tests > But Jenkins can only keep a limited amount of build history, so those links > are not permanent, can't be used as references, and don't help for bisecting > and blame on regressions (and flakey tests) over a longer period of time. > The builds@ ML can provide a permanent record of test results. > This was first brought up in these two threads: > - > https://lists.apache.org/thread.html/re8122e4fdd8629e7fbca2abf27d72054b3bc0e3690ece8b8e66f618b%40%3Cdev.cassandra.apache.org%3E > - > https://lists.apache.org/thread.html/ra5f6aeea89546825fe7ccc4a80898c62f8ed57decabf709d81d9c720%40%3Cdev.cassandra.apache.org%3E > An example plaintext report, to demonstrate feasibility, is available here: > https://lists.apache.org/thread.html/r80d13f7af706bf8dfbf2387fab46004c1fbd3917b7bc339c49e69aa8%40%3Cbuilds.cassandra.apache.org%3E > Hurdles: > - the ASF mailing lists won't accept html, attachments, or any message body > over 1MB. > - packages are used as a differentiator in the final aggregated report. The > cqlsh and dtests currently don't specify it. It needs to be added as a > "dot-separated" prefix to the testsuite and testcase name. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15776) python dtest regression caused by CASSANDRA-15637
[ https://issues.apache.org/jira/browse/CASSANDRA-15776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095841#comment-17095841 ] David Capwell commented on CASSANDRA-15776: --- [Circle CI| https://app.circleci.com/pipelines/github/dcapwell/cassandra?branch=bug%2FCASSANDRA-15776] > python dtest regression caused by CASSANDRA-15637 > - > > Key: CASSANDRA-15776 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15776 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-alpha > > Time Spent: 10m > Remaining Estimate: 0h > > CASSANDRA-15637 deprecated size_estimates in favor of table_estimates to > allow for local primary range estimates (needed for MapReduce). This appears > to have caused a regression in the python dtest nodetool_test.TestNodetool. > test_refresh_size_estimates_clears_invalid_entries (as seen by [Circle > CI|https://app.circleci.com/pipelines/github/dcapwell/cassandra/255/workflows/21907001-93ed-4963-9314-6a0ac6ea0f1d/jobs/1246/tests] > and > [Jenkins|https://ci-cassandra.apache.org/job/Cassandra-trunk-dtest/56/]). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15776) python dtest regression caused by CASSANDRA-15637
[ https://issues.apache.org/jira/browse/CASSANDRA-15776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15776: -- Test and Documentation Plan: Circle CI Status: Patch Available (was: Open) > python dtest regression caused by CASSANDRA-15637 > - > > Key: CASSANDRA-15776 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15776 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-alpha > > Time Spent: 10m > Remaining Estimate: 0h > > CASSANDRA-15637 deprecated size_estimates in favor of table_estimates to > allow for local primary range estimates (needed for MapReduce). This appears > to have caused a regression in the python dtest nodetool_test.TestNodetool. > test_refresh_size_estimates_clears_invalid_entries (as seen by [Circle > CI|https://app.circleci.com/pipelines/github/dcapwell/cassandra/255/workflows/21907001-93ed-4963-9314-6a0ac6ea0f1d/jobs/1246/tests] > and > [Jenkins|https://ci-cassandra.apache.org/job/Cassandra-trunk-dtest/56/]). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15776) python dtest regression caused by CASSANDRA-15637
[ https://issues.apache.org/jira/browse/CASSANDRA-15776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15776: -- Description: CASSANDRA-15637 deprecated size_estimates in favor of table_estimates to allow for local primary range estimates (needed for MapReduce). This appears to have caused a regression in the python dtest nodetool_test.TestNodetool. test_refresh_size_estimates_clears_invalid_entries (as seen by [Circle CI|https://app.circleci.com/pipelines/github/dcapwell/cassandra/255/workflows/21907001-93ed-4963-9314-6a0ac6ea0f1d/jobs/1246/tests] and [Jenkins|https://ci-cassandra.apache.org/job/Cassandra-trunk-dtest/56/]). (was: CASSANDRA-15637 deprecated size_estimates in favor of table_estimates to allow for local primary range estimates (needed for MapReduce). This appears to have caused a regression in the python dtest nodetool_test.TestNodetool. test_refresh_size_estimates_clears_invalid_entries (as seen by Circle CI https://app.circleci.com/pipelines/github/dcapwell/cassandra/255/workflows/21907001-93ed-4963-9314-6a0ac6ea0f1d/jobs/1246/tests and Jenkins https://ci-cassandra.apache.org/job/Cassandra-trunk-dtest/56/).) > python dtest regression caused by CASSANDRA-15637 > - > > Key: CASSANDRA-15776 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15776 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > > CASSANDRA-15637 deprecated size_estimates in favor of table_estimates to > allow for local primary range estimates (needed for MapReduce). This appears > to have caused a regression in the python dtest nodetool_test.TestNodetool. > test_refresh_size_estimates_clears_invalid_entries (as seen by [Circle > CI|https://app.circleci.com/pipelines/github/dcapwell/cassandra/255/workflows/21907001-93ed-4963-9314-6a0ac6ea0f1d/jobs/1246/tests] > and > [Jenkins|https://ci-cassandra.apache.org/job/Cassandra-trunk-dtest/56/]). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15776) python dtest regression caused by CASSANDRA-15637
[ https://issues.apache.org/jira/browse/CASSANDRA-15776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15776: -- Fix Version/s: 4.0-alpha > python dtest regression caused by CASSANDRA-15637 > - > > Key: CASSANDRA-15776 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15776 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.0-alpha > > > CASSANDRA-15637 deprecated size_estimates in favor of table_estimates to > allow for local primary range estimates (needed for MapReduce). This appears > to have caused a regression in the python dtest nodetool_test.TestNodetool. > test_refresh_size_estimates_clears_invalid_entries (as seen by [Circle > CI|https://app.circleci.com/pipelines/github/dcapwell/cassandra/255/workflows/21907001-93ed-4963-9314-6a0ac6ea0f1d/jobs/1246/tests] > and > [Jenkins|https://ci-cassandra.apache.org/job/Cassandra-trunk-dtest/56/]). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15776) python dtest regression caused by CASSANDRA-15637
David Capwell created CASSANDRA-15776: - Summary: python dtest regression caused by CASSANDRA-15637 Key: CASSANDRA-15776 URL: https://issues.apache.org/jira/browse/CASSANDRA-15776 Project: Cassandra Issue Type: Bug Components: Test/dtest Reporter: David Capwell Assignee: David Capwell CASSANDRA-15637 deprecated size_estimates in favor of table_estimates to allow for local primary range estimates (needed for MapReduce). This appears to have caused a regression in the python dtest nodetool_test.TestNodetool. test_refresh_size_estimates_clears_invalid_entries (as seen by Circle CI https://app.circleci.com/pipelines/github/dcapwell/cassandra/255/workflows/21907001-93ed-4963-9314-6a0ac6ea0f1d/jobs/1246/tests and Jenkins https://ci-cassandra.apache.org/job/Cassandra-trunk-dtest/56/). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15776) python dtest regression caused by CASSANDRA-15637
[ https://issues.apache.org/jira/browse/CASSANDRA-15776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15776: -- Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Low Hanging Fruit Discovered By: Unit Test Severity: Low Status: Open (was: Triage Needed) > python dtest regression caused by CASSANDRA-15637 > - > > Key: CASSANDRA-15776 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15776 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > > CASSANDRA-15637 deprecated size_estimates in favor of table_estimates to > allow for local primary range estimates (needed for MapReduce). This appears > to have caused a regression in the python dtest nodetool_test.TestNodetool. > test_refresh_size_estimates_clears_invalid_entries (as seen by Circle CI > https://app.circleci.com/pipelines/github/dcapwell/cassandra/255/workflows/21907001-93ed-4963-9314-6a0ac6ea0f1d/jobs/1246/tests > and Jenkins https://ci-cassandra.apache.org/job/Cassandra-trunk-dtest/56/). -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15729) Jenkins Test Results Report in plaintext for ASF ML
[ https://issues.apache.org/jira/browse/CASSANDRA-15729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15729: --- Status: Patch Available (was: Ready to Commit) Back to in-progress for remaining steps/commits. > Jenkins Test Results Report in plaintext for ASF ML > --- > > Key: CASSANDRA-15729 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15729 > Project: Cassandra > Issue Type: Task > Components: Build, CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Labels: Jenkins > Fix For: 4.0-beta > > > The Jenkins pipeline builds now aggregate all test reports. > For example: > - https://ci-cassandra.apache.org/job/Cassandra-trunk/68/testReport/ > - > https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-trunk/detail/Cassandra-trunk/68/tests > But Jenkins can only keep a limited amount of build history, so those links > are not permanent, can't be used as references, and don't help for bisecting > and blame on regressions (and flakey tests) over a longer period of time. > The builds@ ML can provide a permanent record of test results. > This was first brought up in these two threads: > - > https://lists.apache.org/thread.html/re8122e4fdd8629e7fbca2abf27d72054b3bc0e3690ece8b8e66f618b%40%3Cdev.cassandra.apache.org%3E > - > https://lists.apache.org/thread.html/ra5f6aeea89546825fe7ccc4a80898c62f8ed57decabf709d81d9c720%40%3Cdev.cassandra.apache.org%3E > An example plaintext report, to demonstrate feasibility, is available here: > https://lists.apache.org/thread.html/r80d13f7af706bf8dfbf2387fab46004c1fbd3917b7bc339c49e69aa8%40%3Cbuilds.cassandra.apache.org%3E > Hurdles: > - the ASF mailing lists won't accept html, attachments, or any message body > over 1MB. > - packages are used as a differentiator in the final aggregated report. The > cqlsh and dtests currently don't specify it. It needs to be added as a > "dot-separated" prefix to the testsuite and testcase name. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15729) Jenkins Test Results Report in plaintext for ASF ML
[ https://issues.apache.org/jira/browse/CASSANDRA-15729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-15729: --- Status: In Progress (was: Patch Available) > Jenkins Test Results Report in plaintext for ASF ML > --- > > Key: CASSANDRA-15729 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15729 > Project: Cassandra > Issue Type: Task > Components: Build, CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Labels: Jenkins > Fix For: 4.0-beta > > > The Jenkins pipeline builds now aggregate all test reports. > For example: > - https://ci-cassandra.apache.org/job/Cassandra-trunk/68/testReport/ > - > https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-trunk/detail/Cassandra-trunk/68/tests > But Jenkins can only keep a limited amount of build history, so those links > are not permanent, can't be used as references, and don't help for bisecting > and blame on regressions (and flakey tests) over a longer period of time. > The builds@ ML can provide a permanent record of test results. > This was first brought up in these two threads: > - > https://lists.apache.org/thread.html/re8122e4fdd8629e7fbca2abf27d72054b3bc0e3690ece8b8e66f618b%40%3Cdev.cassandra.apache.org%3E > - > https://lists.apache.org/thread.html/ra5f6aeea89546825fe7ccc4a80898c62f8ed57decabf709d81d9c720%40%3Cdev.cassandra.apache.org%3E > An example plaintext report, to demonstrate feasibility, is available here: > https://lists.apache.org/thread.html/r80d13f7af706bf8dfbf2387fab46004c1fbd3917b7bc339c49e69aa8%40%3Cbuilds.cassandra.apache.org%3E > Hurdles: > - the ASF mailing lists won't accept html, attachments, or any message body > over 1MB. > - packages are used as a differentiator in the final aggregated report. The > cqlsh and dtests currently don't specify it. It needs to be added as a > "dot-separated" prefix to the testsuite and testcase name. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15729) Jenkins Test Results Report in plaintext for ASF ML
[ https://issues.apache.org/jira/browse/CASSANDRA-15729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095830#comment-17095830 ] Michael Semb Wever commented on CASSANDRA-15729: Committed the cqlshlib test report/package name change [here|https://github.com/apache/cassandra/commit/ed62641748fbea4c98d16ea4fe386450475fdac9] to 3.0, 3.11, and trunk. > Jenkins Test Results Report in plaintext for ASF ML > --- > > Key: CASSANDRA-15729 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15729 > Project: Cassandra > Issue Type: Task > Components: Build, CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Labels: Jenkins > Fix For: 4.0-beta > > > The Jenkins pipeline builds now aggregate all test reports. > For example: > - https://ci-cassandra.apache.org/job/Cassandra-trunk/68/testReport/ > - > https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-trunk/detail/Cassandra-trunk/68/tests > But Jenkins can only keep a limited amount of build history, so those links > are not permanent, can't be used as references, and don't help for bisecting > and blame on regressions (and flakey tests) over a longer period of time. > The builds@ ML can provide a permanent record of test results. > This was first brought up in these two threads: > - > https://lists.apache.org/thread.html/re8122e4fdd8629e7fbca2abf27d72054b3bc0e3690ece8b8e66f618b%40%3Cdev.cassandra.apache.org%3E > - > https://lists.apache.org/thread.html/ra5f6aeea89546825fe7ccc4a80898c62f8ed57decabf709d81d9c720%40%3Cdev.cassandra.apache.org%3E > An example plaintext report, to demonstrate feasibility, is available here: > https://lists.apache.org/thread.html/r80d13f7af706bf8dfbf2387fab46004c1fbd3917b7bc339c49e69aa8%40%3Cbuilds.cassandra.apache.org%3E > Hurdles: > - the ASF mailing lists won't accept html, attachments, or any message body > over 1MB. > - packages are used as a differentiator in the final aggregated report. The > cqlsh and dtests currently don't specify it. It needs to be added as a > "dot-separated" prefix to the testsuite and testcase name. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (5fe434c -> 8a4e2ed)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 5fe434c Merge branch 'cassandra-3.0' into cassandra-3.11 new ed62641 Use different package names for the cqlsh-tests matrix values, so final aggregated test reports are distinguished new 8a4e2ed 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: pylib/cassandra-cqlsh-tests.sh | 7 +++ 1 file changed, 7 insertions(+) - 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.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. mck pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 8a4e2edcfff079b909a97ceff8360b9373ea4a95 Merge: 5fe434c ed62641 Author: Mick Semb Wever AuthorDate: Wed Apr 29 21:08:31 2020 +0200 Merge branch 'cassandra-3.0' into cassandra-3.11 pylib/cassandra-cqlsh-tests.sh | 7 +++ 1 file changed, 7 insertions(+) - 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 different package names for the cqlsh-tests matrix values, so final aggregated test reports are distinguished
This is an automated email from the ASF dual-hosted git repository.
mck 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 ed62641 Use different package names for the cqlsh-tests matrix
values, so final aggregated test reports are distinguished
ed62641 is described below
commit ed62641748fbea4c98d16ea4fe386450475fdac9
Author: Mick Semb Wever
AuthorDate: Wed Apr 29 21:07:33 2020 +0200
Use different package names for the cqlsh-tests matrix values, so final
aggregated test reports are distinguished
patch by Mick Semb Wever; reviewed by David Capwell for CASSANDRA-15729
---
pylib/cassandra-cqlsh-tests.sh | 7 +++
1 file changed, 7 insertions(+)
diff --git a/pylib/cassandra-cqlsh-tests.sh b/pylib/cassandra-cqlsh-tests.sh
index 1fb3aa0..8174636 100755
--- a/pylib/cassandra-cqlsh-tests.sh
+++ b/pylib/cassandra-cqlsh-tests.sh
@@ -22,6 +22,7 @@ export CCM_HEAP_NEWSIZE="200M"
export CCM_CONFIG_DIR=${WORKSPACE}/.ccm
export NUM_TOKENS="32"
export CASSANDRA_DIR=${WORKSPACE}
+export TESTSUITE_NAME="cqlshlib.python2.jdk8"
# Loop to prevent failure due to maven-ant-tasks not downloading a jar..
for x in $(seq 1 3); do
@@ -45,9 +46,12 @@ pip install -r ${CASSANDRA_DIR}/pylib/requirements.txt
pip freeze
if [ "$cython" = "yes" ]; then
+TESTSUITE_NAME="${TESTSUITE_NAME}.cython"
pip install "Cython>=0.20,<0.25"
cd pylib/; python setup.py build_ext --inplace
cd ${WORKSPACE}
+else
+TESTSUITE_NAME="${TESTSUITE_NAME}.no_cython"
fi
@@ -85,6 +89,9 @@ set +e # disable immediate exit from this point
nosetests
ccm remove
+# hack around --xunit-prefix-with-testsuite-name not being available in nose
1.3.7
+sed -i "s/testsuite name=\"nosetests\"/testsuite name=\"${TESTSUITE_NAME}\"/g"
nosetests.xml
+sed -i "s/testcase classname=\"cqlshlib./testcase
classname=\"${TESTSUITE_NAME}./g" nosetests.xml
mv nosetests.xml ${WORKSPACE}/cqlshlib.xml
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (712b434 -> 54472f8)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 712b434 Merge branch 'cassandra-3.11' into trunk new ed62641 Use different package names for the cqlsh-tests matrix values, so final aggregated test reports are distinguished new 8a4e2ed Merge branch 'cassandra-3.0' into cassandra-3.11 new 54472f8 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: pylib/cassandra-cqlsh-tests.sh | 13 + 1 file changed, 13 insertions(+) - 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.
mck pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
commit 54472f8801e422674e3cc3cb46731cad1423d2e9
Merge: 712b434 8a4e2ed
Author: Mick Semb Wever
AuthorDate: Wed Apr 29 21:10:06 2020 +0200
Merge branch 'cassandra-3.11' into trunk
pylib/cassandra-cqlsh-tests.sh | 13 +
1 file changed, 13 insertions(+)
diff --cc pylib/cassandra-cqlsh-tests.sh
index 56672f1,8174636..2013507
--- a/pylib/cassandra-cqlsh-tests.sh
+++ b/pylib/cassandra-cqlsh-tests.sh
@@@ -32,11 -22,8 +32,18 @@@ export CCM_HEAP_NEWSIZE="200M
export CCM_CONFIG_DIR=${WORKSPACE}/.ccm
export NUM_TOKENS="32"
export CASSANDRA_DIR=${WORKSPACE}
-export TESTSUITE_NAME="cqlshlib.python2.jdk8"
++export TESTSUITE_NAME="cqlshlib.${PYTHON_VERSION}"
+
+if [ -z "$CASSANDRA_USE_JDK11" ]; then
+export CASSANDRA_USE_JDK11=false
+fi
+
++if [ "$CASSANDRA_USE_JDK11" = true ] ; then
++TESTSUITE_NAME="${TESTSUITE_NAME}.jdk11"
++else
++TESTSUITE_NAME="${TESTSUITE_NAME}.jdk8"
++fi
+
# Loop to prevent failure due to maven-ant-tasks not downloading a jar..
for x in $(seq 1 3); do
ant -buildfile ${CASSANDRA_DIR}/build.xml realclean jar
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15729) Jenkins Test Results Report in plaintext for ASF ML
[ https://issues.apache.org/jira/browse/CASSANDRA-15729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15729: -- Status: Ready to Commit (was: Review In Progress) https://1267-209217594-gh.circle-artifacts.com/0/cqlsh_tests/cqlshlib.xml LGTM +1 > Jenkins Test Results Report in plaintext for ASF ML > --- > > Key: CASSANDRA-15729 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15729 > Project: Cassandra > Issue Type: Task > Components: Build, CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Labels: Jenkins > Fix For: 4.0-beta > > > The Jenkins pipeline builds now aggregate all test reports. > For example: > - https://ci-cassandra.apache.org/job/Cassandra-trunk/68/testReport/ > - > https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-trunk/detail/Cassandra-trunk/68/tests > But Jenkins can only keep a limited amount of build history, so those links > are not permanent, can't be used as references, and don't help for bisecting > and blame on regressions (and flakey tests) over a longer period of time. > The builds@ ML can provide a permanent record of test results. > This was first brought up in these two threads: > - > https://lists.apache.org/thread.html/re8122e4fdd8629e7fbca2abf27d72054b3bc0e3690ece8b8e66f618b%40%3Cdev.cassandra.apache.org%3E > - > https://lists.apache.org/thread.html/ra5f6aeea89546825fe7ccc4a80898c62f8ed57decabf709d81d9c720%40%3Cdev.cassandra.apache.org%3E > An example plaintext report, to demonstrate feasibility, is available here: > https://lists.apache.org/thread.html/r80d13f7af706bf8dfbf2387fab46004c1fbd3917b7bc339c49e69aa8%40%3Cbuilds.cassandra.apache.org%3E > Hurdles: > - the ASF mailing lists won't accept html, attachments, or any message body > over 1MB. > - packages are used as a differentiator in the final aggregated report. The > cqlsh and dtests currently don't specify it. It needs to be added as a > "dot-separated" prefix to the testsuite and testcase name. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15729) Jenkins Test Results Report in plaintext for ASF ML
[ https://issues.apache.org/jira/browse/CASSANDRA-15729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15729: -- Reviewers: David Capwell, David Capwell (was: David Capwell) David Capwell, David Capwell (was: David Capwell) Status: Review In Progress (was: Patch Available) > Jenkins Test Results Report in plaintext for ASF ML > --- > > Key: CASSANDRA-15729 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15729 > Project: Cassandra > Issue Type: Task > Components: Build, CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Labels: Jenkins > Fix For: 4.0-beta > > > The Jenkins pipeline builds now aggregate all test reports. > For example: > - https://ci-cassandra.apache.org/job/Cassandra-trunk/68/testReport/ > - > https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-trunk/detail/Cassandra-trunk/68/tests > But Jenkins can only keep a limited amount of build history, so those links > are not permanent, can't be used as references, and don't help for bisecting > and blame on regressions (and flakey tests) over a longer period of time. > The builds@ ML can provide a permanent record of test results. > This was first brought up in these two threads: > - > https://lists.apache.org/thread.html/re8122e4fdd8629e7fbca2abf27d72054b3bc0e3690ece8b8e66f618b%40%3Cdev.cassandra.apache.org%3E > - > https://lists.apache.org/thread.html/ra5f6aeea89546825fe7ccc4a80898c62f8ed57decabf709d81d9c720%40%3Cdev.cassandra.apache.org%3E > An example plaintext report, to demonstrate feasibility, is available here: > https://lists.apache.org/thread.html/r80d13f7af706bf8dfbf2387fab46004c1fbd3917b7bc339c49e69aa8%40%3Cbuilds.cassandra.apache.org%3E > Hurdles: > - the ASF mailing lists won't accept html, attachments, or any message body > over 1MB. > - packages are used as a differentiator in the final aggregated report. The > cqlsh and dtests currently don't specify it. It needs to be added as a > "dot-separated" prefix to the testsuite and testcase name. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15729) Jenkins Test Results Report in plaintext for ASF ML
[ https://issues.apache.org/jira/browse/CASSANDRA-15729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-15729: -- Test and Documentation Plan: Ran via Circle CI to validate XML Status: Patch Available (was: In Progress) > Jenkins Test Results Report in plaintext for ASF ML > --- > > Key: CASSANDRA-15729 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15729 > Project: Cassandra > Issue Type: Task > Components: Build, CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Labels: Jenkins > Fix For: 4.0-beta > > > The Jenkins pipeline builds now aggregate all test reports. > For example: > - https://ci-cassandra.apache.org/job/Cassandra-trunk/68/testReport/ > - > https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-trunk/detail/Cassandra-trunk/68/tests > But Jenkins can only keep a limited amount of build history, so those links > are not permanent, can't be used as references, and don't help for bisecting > and blame on regressions (and flakey tests) over a longer period of time. > The builds@ ML can provide a permanent record of test results. > This was first brought up in these two threads: > - > https://lists.apache.org/thread.html/re8122e4fdd8629e7fbca2abf27d72054b3bc0e3690ece8b8e66f618b%40%3Cdev.cassandra.apache.org%3E > - > https://lists.apache.org/thread.html/ra5f6aeea89546825fe7ccc4a80898c62f8ed57decabf709d81d9c720%40%3Cdev.cassandra.apache.org%3E > An example plaintext report, to demonstrate feasibility, is available here: > https://lists.apache.org/thread.html/r80d13f7af706bf8dfbf2387fab46004c1fbd3917b7bc339c49e69aa8%40%3Cbuilds.cassandra.apache.org%3E > Hurdles: > - the ASF mailing lists won't accept html, attachments, or any message body > over 1MB. > - packages are used as a differentiator in the final aggregated report. The > cqlsh and dtests currently don't specify it. It needs to be added as a > "dot-separated" prefix to the testsuite and testcase name. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-23) Set up structure for handling multiple Cassandra versions
[
https://issues.apache.org/jira/browse/CASSANDRASC-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Haddad updated CASSANDRASC-23:
--
Change Category: Operability
Complexity: Normal
Status: Open (was: Triage Needed)
> Set up structure for handling multiple Cassandra versions
> -
>
> Key: CASSANDRASC-23
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-23
> Project: Sidecar for Apache Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Jon Haddad
>Assignee: Jon Haddad
>Priority: Normal
>
> The first sidecar release will be for Cassandra 4.0, but one of the project
> goals is to be able to handle multiple versions. This will be especially
> important in mixed version clusters, or even mixed version 1:N sidecar to C*
> nodes (see CASSANDRASC-17).
> This JIRA is to lay the foundational work for supporting multiple Cassandra
> versions.
> Each Cassandra version (for example \{{cassandra40}}, \{{cassandra50}}, will
> be in a separate Gradle subproject, implementing a common interface defined
> in a \{{common}} subproject. A common cassandra integration testing
> framework will be able to test every version to ensure each version adheres
> to the expected interface.
> Each module will define the minimum compatibility it supports, so if someone
> (for example) wants to implement a Cassandra30 module for their own cluster,
> they will have the ability to do so.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-22) RESTEasy integration for Cassandra Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095787#comment-17095787 ] Jon Haddad commented on CASSANDRASC-22: --- Awesome, thanks Dinesh. Glad we agree :) Reviewing the patch now. > RESTEasy integration for Cassandra Sidecar > -- > > Key: CASSANDRASC-22 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-22 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Dinesh Joshi >Assignee: Dinesh Joshi >Priority: Normal > Attachments: image-2020-04-27-22-59-40-060.png, > image-2020-04-29-01-14-11-756.png, image-2020-04-29-10-33-37-196.png > > > Add support for JAX-RS based routing via RESTEasy to Cassandra Sidecar. This > also dynamically generates swagger documentation and adds the swagger UI. > [Branch|https://github.com/dineshjoshi/cassandra-sidecar/tree/resteasy-swagger] > [Tests|https://circleci.com/workflow-run/a7888146-a22d-45af-983a-8833b77eef59] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRASC-23) Set up structure for handling multiple Cassandra versions
Jon Haddad created CASSANDRASC-23:
-
Summary: Set up structure for handling multiple Cassandra versions
Key: CASSANDRASC-23
URL: https://issues.apache.org/jira/browse/CASSANDRASC-23
Project: Sidecar for Apache Cassandra
Issue Type: Improvement
Components: Configuration
Reporter: Jon Haddad
Assignee: Jon Haddad
The first sidecar release will be for Cassandra 4.0, but one of the project
goals is to be able to handle multiple versions. This will be especially
important in mixed version clusters, or even mixed version 1:N sidecar to C*
nodes (see CASSANDRASC-17).
This JIRA is to lay the foundational work for supporting multiple Cassandra
versions.
Each Cassandra version (for example \{{cassandra40}}, \{{cassandra50}}, will be
in a separate Gradle subproject, implementing a common interface defined in a
\{{common}} subproject. A common cassandra integration testing framework will
be able to test every version to ensure each version adheres to the expected
interface.
Each module will define the minimum compatibility it supports, so if someone
(for example) wants to implement a Cassandra30 module for their own cluster,
they will have the ability to do so.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRASC-22) RESTEasy integration for Cassandra Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17094142#comment-17094142 ] Dinesh Joshi edited comment on CASSANDRASC-22 at 4/29/20, 5:39 PM: --- FYI: Contains some circleci changes that fixed my test failures. To elaborate, I ported the build over to Docker for Java 8 and it started succeeding. I think there is something peculiar about CircleCI's baremetal machines that causes this failure. Same build running fails after 4m21s on baremetal and succeeds within 2m inside Docker. !image-2020-04-27-22-59-40-060.png|width=372,height=314! was (Author: djoshi3): FYI: Contains some circleci changes that fixed my test failures. To elaborate, I ported the build over to Docker for Java 8 and it started succeeding. I think there is something peculiar about CircleCI's baremetal machines that causes this failure. Same build running fails after 4m21s on baremetal and succeeds within 2m inside Docker. !image-2020-04-27-22-59-40-060.png! > RESTEasy integration for Cassandra Sidecar > -- > > Key: CASSANDRASC-22 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-22 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Dinesh Joshi >Assignee: Dinesh Joshi >Priority: Normal > Attachments: image-2020-04-27-22-59-40-060.png, > image-2020-04-29-01-14-11-756.png, image-2020-04-29-10-33-37-196.png > > > Add support for JAX-RS based routing via RESTEasy to Cassandra Sidecar. This > also dynamically generates swagger documentation and adds the swagger UI. > [Branch|https://github.com/dineshjoshi/cassandra-sidecar/tree/resteasy-swagger] > [Tests|https://circleci.com/workflow-run/a7888146-a22d-45af-983a-8833b77eef59] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-22) RESTEasy integration for Cassandra Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095736#comment-17095736 ] Dinesh Joshi commented on CASSANDRASC-22: - [~rustyrazorblade] I probably did not address the Docker & Machine image topic properly. I meant to keep the Docker _and_ Machine images for precisely the reason you mentioned (y). It allowed us to surface an issue that we otherwise wouldn't have caught. Here's how the workflow looks: !image-2020-04-29-10-33-37-196.png|width=374,height=155! We have both Java 8 and Java 11 builds within Docker _and_ Machine images. When they succeed, we kick off the package builds. We can iterate and tweak this workflow based on your feedback. > RESTEasy integration for Cassandra Sidecar > -- > > Key: CASSANDRASC-22 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-22 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Dinesh Joshi >Assignee: Dinesh Joshi >Priority: Normal > Attachments: image-2020-04-27-22-59-40-060.png, > image-2020-04-29-01-14-11-756.png, image-2020-04-29-10-33-37-196.png > > > Add support for JAX-RS based routing via RESTEasy to Cassandra Sidecar. This > also dynamically generates swagger documentation and adds the swagger UI. > [Branch|https://github.com/dineshjoshi/cassandra-sidecar/tree/resteasy-swagger] > [Tests|https://circleci.com/workflow-run/a7888146-a22d-45af-983a-8833b77eef59] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-22) RESTEasy integration for Cassandra Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dinesh Joshi updated CASSANDRASC-22: Attachment: image-2020-04-29-10-33-37-196.png > RESTEasy integration for Cassandra Sidecar > -- > > Key: CASSANDRASC-22 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-22 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Dinesh Joshi >Assignee: Dinesh Joshi >Priority: Normal > Attachments: image-2020-04-27-22-59-40-060.png, > image-2020-04-29-01-14-11-756.png, image-2020-04-29-10-33-37-196.png > > > Add support for JAX-RS based routing via RESTEasy to Cassandra Sidecar. This > also dynamically generates swagger documentation and adds the swagger UI. > [Branch|https://github.com/dineshjoshi/cassandra-sidecar/tree/resteasy-swagger] > [Tests|https://circleci.com/workflow-run/a7888146-a22d-45af-983a-8833b77eef59] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15775) Configuration to disallow queries with "allow filtering"
Christian Fredriksson created CASSANDRA-15775: - Summary: Configuration to disallow queries with "allow filtering" Key: CASSANDRA-15775 URL: https://issues.apache.org/jira/browse/CASSANDRA-15775 Project: Cassandra Issue Type: Improvement Reporter: Christian Fredriksson Problem: We have inexperienced developers not following guidelines or best pratices who do queries with "allow filtering" which have negative impact on performance on other queries and developers. It would be beneficial to have a (server side) configuration to disallow these queries altogether. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-22) RESTEasy integration for Cassandra Sidecar
[
https://issues.apache.org/jira/browse/CASSANDRASC-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095724#comment-17095724
]
Yifan Cai commented on CASSANDRASC-22:
--
{quote}The {{index.html}} is required to be checked in. Its the entry point to
{{localhost:9043/docs/index.html}}. You'll find that if you delete that file
and run {{./gradlew clean run}}, it will the Swagger UI stops working. Its
mapped
[here|https://github.com/apache/cassandra-sidecar/compare/master...dineshjoshi:resteasy-swagger#diff-4ccf0add938ab660c975035eeb204be5R120].
{quote}
You are right. Probably I did not run {{clean}} last time. :P
> RESTEasy integration for Cassandra Sidecar
> --
>
> Key: CASSANDRASC-22
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-22
> Project: Sidecar for Apache Cassandra
> Issue Type: Improvement
> Components: Rest API
>Reporter: Dinesh Joshi
>Assignee: Dinesh Joshi
>Priority: Normal
> Attachments: image-2020-04-27-22-59-40-060.png,
> image-2020-04-29-01-14-11-756.png
>
>
> Add support for JAX-RS based routing via RESTEasy to Cassandra Sidecar. This
> also dynamically generates swagger documentation and adds the swagger UI.
> [Branch|https://github.com/dineshjoshi/cassandra-sidecar/tree/resteasy-swagger]
> [Tests|https://circleci.com/workflow-run/a7888146-a22d-45af-983a-8833b77eef59]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-22) RESTEasy integration for Cassandra Sidecar
[
https://issues.apache.org/jira/browse/CASSANDRASC-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095716#comment-17095716
]
Jon Haddad commented on CASSANDRASC-22:
---
{quote}Do you want me to add generating the clients in this ticket or in a
different one? I'd prefer the latter.
{quote}
I've already got CASSANDRASC-21 open to generate the clients, I'd prefer to
keep scope in this issue limited to what you're already doing.
> RESTEasy integration for Cassandra Sidecar
> --
>
> Key: CASSANDRASC-22
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-22
> Project: Sidecar for Apache Cassandra
> Issue Type: Improvement
> Components: Rest API
>Reporter: Dinesh Joshi
>Assignee: Dinesh Joshi
>Priority: Normal
> Attachments: image-2020-04-27-22-59-40-060.png,
> image-2020-04-29-01-14-11-756.png
>
>
> Add support for JAX-RS based routing via RESTEasy to Cassandra Sidecar. This
> also dynamically generates swagger documentation and adds the swagger UI.
> [Branch|https://github.com/dineshjoshi/cassandra-sidecar/tree/resteasy-swagger]
> [Tests|https://circleci.com/workflow-run/a7888146-a22d-45af-983a-8833b77eef59]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15099) Debian 10 buster: init file require PID file to be owned by root
[ https://issues.apache.org/jira/browse/CASSANDRA-15099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-15099: - Resolution: Duplicate Status: Resolved (was: Triage Needed) Resolved by CASSANDRA-15770 which has a better solution. > Debian 10 buster: init file require PID file to be owned by root > > > Key: CASSANDRA-15099 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15099 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Yury Vidineev >Priority: Normal > > Restarting Cassandra: cassandrastart-stop-daemon: matching only on non-root > pidfile /var/run/cassandra/cassandra.pid is insecure > failed! -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15770) stop and restart fail in Debian 10 buster
[
https://issues.apache.org/jira/browse/CASSANDRA-15770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15770:
-
Since Version: 3.0.0
Source Control Link:
https://github.com/apache/cassandra/commit/469c6496ae8817975140e5d353ccdebedbea6c06
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed, thanks!
> stop and restart fail in Debian 10 buster
> -
>
> Key: CASSANDRA-15770
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15770
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Vicente Jimenez Aguilar
>Assignee: Vicente Jimenez Aguilar
>Priority: Normal
> Labels: Debian, easyfix, patch
> Fix For: 3.0.21, 3.11.7, 4.0-alpha
>
> Attachments: 0001-Fix-init-script-for-debian-Buster.patch
>
>
> Debian 10 "buster" has an updated {{start-stop-daemon}} version that causes
> init script to fail to stop or restart Cassandra daemon. {{stop}} option do
> not stops first launched instance and depending of previous operations,
> {{restart}} and {{start}} could launch a second Cassandra daemon instance.
> {{start-stop-daemon}} since version 1.19.3 fail to stop matching only a
> pidfile that can be writen by an unprivileged (non-root) user because it is
> considered a security risk.
> Adding a second matching option (user) solved this.
> This fix does not break compatibility with older versions and does not mess
> with pidfile's mode or permissions.
> Related: CASSANDRA-15099
> https://github.com/vice/cassandra/tree/debian-buster
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (d7ffdb2 -> 5fe434c)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from d7ffdb2 fix missing CHANGES entry new 469c649 Fix init script for debian Buster new 5fe434c 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 + debian/init | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (fb9e74a -> 712b434)
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from fb9e74a Fix buffer pool NPE with concurrent release due to in-progress tiny pool eviction new 469c649 Fix init script for debian Buster new 5fe434c Merge branch 'cassandra-3.0' into cassandra-3.11 new 712b434 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 + debian/init | 2 +- 2 files changed, 2 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.0 updated: Fix init script for debian Buster
This is an automated email from the ASF dual-hosted git repository. brandonwilliams 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 469c649 Fix init script for debian Buster 469c649 is described below commit 469c6496ae8817975140e5d353ccdebedbea6c06 Author: Vicente Jimenez Aguilar AuthorDate: Wed Apr 29 11:03:30 2020 +0200 Fix init script for debian Buster Patch by Vicente Jimenez Aguilar, reviewed by brandonwilliams for CASSANDRA-15770 --- CHANGES.txt | 1 + debian/init | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/CHANGES.txt b/CHANGES.txt index b906f15..c495cd6 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,5 @@ 3.0.21 + * Fix Debian init start/stop (CASSANDRA-15770) * Fix infinite loop on index query paging in tables with clustering (CASSANDRA-14242) * Fix chunk index overflow due to large sstable with small chunk length (CASSANDRA-15595) * cqlsh return non-zero status when STDIN CQL fails (CASSANDRA-15623) diff --git a/debian/init b/debian/init index 26ce55c..0518cd2 100644 --- a/debian/init +++ b/debian/init @@ -98,7 +98,7 @@ do_stop() # 1 if daemon was already stopped # 2 if daemon could not be stopped # other if a failure occurred -start-stop-daemon -K -p "$PIDFILE" -R TERM/30/KILL/5 >/dev/null +start-stop-daemon -K -u cassandra -p "$PIDFILE" -R TERM/30/KILL/5 >/dev/null RET=$? rm -f "$PIDFILE" return $RET - 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.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 5fe434c4ab44b22a296640dff6f6c3f5431229c6 Merge: d7ffdb2 469c649 Author: Brandon Williams AuthorDate: Wed Apr 29 12:03:31 2020 -0500 Merge branch 'cassandra-3.0' into cassandra-3.11 CHANGES.txt | 1 + debian/init | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --cc CHANGES.txt index bc28c28,c495cd6..6d3a3c7 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,9 -1,7 +1,10 @@@ -3.0.21 +3.11.7 + * Allow sstableloader to use SSL on the native port (CASSANDRA-14904) +Merged from 3.0: + * Fix Debian init start/stop (CASSANDRA-15770) * Fix infinite loop on index query paging in tables with clustering (CASSANDRA-14242) * Fix chunk index overflow due to large sstable with small chunk length (CASSANDRA-15595) + * Allow selecting static column only when querying static index (CASSANDRA-14242) * cqlsh return non-zero status when STDIN CQL fails (CASSANDRA-15623) * Don't skip sstables in slice queries based only on local min/max/deletion timestamp (CASSANDRA-15690) * Memtable memory allocations may deadlock (CASSANDRA-15367) - 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. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 712b43408a8f147c03620b4a5c05fdeb0fef4290 Merge: fb9e74a 5fe434c Author: Brandon Williams AuthorDate: Wed Apr 29 12:03:53 2020 -0500 Merge branch 'cassandra-3.11' into trunk CHANGES.txt | 1 + debian/init | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --cc CHANGES.txt index d25ba64,6d3a3c7..a1bf2fc --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,22 -1,7 +1,23 @@@ -3.11.7 - * Allow sstableloader to use SSL on the native port (CASSANDRA-14904) +4.0-alpha5 + * Fix buffer pool NPE with concurrent release due to in-progress tiny pool eviction (CASSANDRA-15726) + * Avoid race condition when completing stream sessions (CASSANDRA-15666) + * Flush with fast compressors by default (CASSANDRA-15379) + * Fix CqlInputFormat regression from the switch to system.size_estimates (CASSANDRA-15637) + * Allow sending Entire SSTables over SSL (CASSANDRA-15740) + * Fix CQLSH UTF-8 encoding issue for Python 2/3 compatibility (CASSANDRA-15739) + * Fix batch statement preparation when multiple tables and parameters are used (CASSANDRA-15730) + * Fix regression with traceOutgoingMessage printing message size (CASSANDRA-15687) + * Ensure repaired data tracking reads a consistent amount of data across replicas (CASSANDRA-15601) + * Fix CQLSH to avoid arguments being evaluated (CASSANDRA-15660) + * Correct Visibility and Improve Safety of Methods in LatencyMetrics (CASSANDRA-15597) + * Allow cqlsh to run with Python2.7/Python3.6+ (CASSANDRA-15659,CASSANDRA-15573) + * Improve logging around incremental repair (CASSANDRA-15599) + * Do not check cdc_raw_directory filesystem space if CDC disabled (CASSANDRA-15688) + * Replace array iterators with get by index (CASSANDRA-15394) + * Minimize BTree iterator allocations (CASSANDRA-15389) +Merged from 3.11: Merged from 3.0: + * Fix Debian init start/stop (CASSANDRA-15770) * Fix infinite loop on index query paging in tables with clustering (CASSANDRA-14242) * Fix chunk index overflow due to large sstable with small chunk length (CASSANDRA-15595) * Allow selecting static column only when querying static index (CASSANDRA-14242) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15773) Add test to cover metrics related to the BufferPool
[
https://issues.apache.org/jira/browse/CASSANDRA-15773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-15773:
-
Reviewers: Dinesh Joshi, Dinesh Joshi (was: Dinesh Joshi)
Dinesh Joshi, Dinesh Joshi (was: Dinesh Joshi)
Status: Review In Progress (was: Patch Available)
> Add test to cover metrics related to the BufferPool
> ---
>
> Key: CASSANDRA-15773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15773
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Normal
>
> At this time there do not appear to be unit tests to validate
> {{BufferPoolMetrics}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15773) Add test to cover metrics related to the BufferPool
[
https://issues.apache.org/jira/browse/CASSANDRA-15773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095704#comment-17095704
]
Dinesh Joshi commented on CASSANDRA-15773:
--
thanks for the patch [~spmallette]. I've kicked off CI
[here|https://circleci.com/workflow-run/fa06016a-fb74-455c-8bc0-4ee96034c3dd].
> Add test to cover metrics related to the BufferPool
> ---
>
> Key: CASSANDRA-15773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15773
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Normal
>
> At this time there do not appear to be unit tests to validate
> {{BufferPoolMetrics}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15770) stop and restart fail in Debian 10 buster
[
https://issues.apache.org/jira/browse/CASSANDRA-15770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15770:
-
Status: Ready to Commit (was: Review In Progress)
> stop and restart fail in Debian 10 buster
> -
>
> Key: CASSANDRA-15770
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15770
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Vicente Jimenez Aguilar
>Assignee: Vicente Jimenez Aguilar
>Priority: Normal
> Labels: Debian, easyfix, patch
> Fix For: 3.0.21, 3.11.7, 4.0-alpha
>
> Attachments: 0001-Fix-init-script-for-debian-Buster.patch
>
>
> Debian 10 "buster" has an updated {{start-stop-daemon}} version that causes
> init script to fail to stop or restart Cassandra daemon. {{stop}} option do
> not stops first launched instance and depending of previous operations,
> {{restart}} and {{start}} could launch a second Cassandra daemon instance.
> {{start-stop-daemon}} since version 1.19.3 fail to stop matching only a
> pidfile that can be writen by an unprivileged (non-root) user because it is
> considered a security risk.
> Adding a second matching option (user) solved this.
> This fix does not break compatibility with older versions and does not mess
> with pidfile's mode or permissions.
> Related: CASSANDRA-15099
> https://github.com/vice/cassandra/tree/debian-buster
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15772) DOC - Improve tpstats documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-15772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-15772:
--
Status: Open (was: Triage Needed)
> DOC - Improve tpstats documentation
> ---
>
> Key: CASSANDRA-15772
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15772
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation/Website
>Reporter: Mark Curtis
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> h2. Background
> The docs for {{nodetool tpstats}} gives the user a good overview of the
> correct command format, but lack an explanation of the message types.
> As of Cassandra4.0 and CASSANDRA-15066 the Message types have expanded a lot
> so this becomes quite overwhelming (particularly for new users).
> I'd propose we offer a simple explanation of these grouping them into logical
> groups (see CASSANDRA-15771 which I opened for the formatting output).
> The github code for the {{Verb.java}} class does give the user some idea of
> what these are but not everyone will go looking for that.
> h2. Example
> Code for ref
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/Verb.java]
> I tried to sort some of the tpstats output into categories and made a first
> attempt at an explanation here:
> {code:java}
> BatchesBATCH_REMOVE_REQ
> BatchesBATCH_REMOVE_RSP
> BatchesBATCH_STORE_REQ
> BatchesBATCH_STORE_RSP
> - These are batches, I'd assume the store / removes are as we add and process
> them?
>
> Counters COUNTER_MUTATION_REQ
> Counters COUNTER_MUTATION_RSP
> - Counter writes
> Deprecated INTERNAL_RSP
> Deprecated REQUEST_RSP
> - Some of these are shown as deprecated in the code. Not sure what we should
> add here
>
> Gossip ECHO_REQ
> Gossip ECHO_RSP
> Gossip GOSSIP_DIGEST_ACK
> Gossip GOSSIP_DIGEST_ACK2
> Gossip GOSSIP_DIGEST_SYN
> Gossip GOSSIP_SHUTDOWN
> Gossip PING_REQ
> Gossip PING_RSP
> - Gossip, probably we'd refer to a more detailed page on gossip from here
>
> Hints HINT_REQ
> Hints HINT_RSP
> - Hints!
>
> LWTs PAXOS_COMMIT_REQ
> LWTs PAXOS_COMMIT_RSP
> LWTs PAXOS_PREPARE_REQ
> LWTs PAXOS_PREPARE_RSP
> LWTs PAXOS_PROPOSE_REQ
> LWTs PAXOS_PROPOSE_RSP
> - Paxos phases request / response
>
> Migration SCHEMA_PULL_REQ
> Migration SCHEMA_PULL_RSP
> Migration SCHEMA_PUSH_REQ
> Migration SCHEMA_PUSH_RSP
> Migration SCHEMA_VERSION_REQ
> Migration SCHEMA_VERSION_RSP
> - Schema migration messaging (i.e. adding new tables)
> Misc REPLICATION_DONE_REQ
> Misc REPLICATION_DONE_RSP
> Misc SNAPSHOT_MSG
> Misc SNAPSHOT_REQ
> Misc SNAPSHOT_RSP
> - Unsure of these, could the snapshots be for simply nodetool snapshot
> requests like on truncates?
>
> Reads RANGE_REQ
> Reads RANGE_RSP
> Reads READ_REPAIR_REQ
> Reads READ_REPAIR_RSP
> Reads READ_REQ
> Reads READ_RSP
> - All types of read messages
>
> Repair CLEANUP_MSG
> Repair FAILED_SESSION_MSG
> Repair FAILURE_RSP
> Repair FINALIZE_COMMIT_MSG
> Repair FINALIZE_PROMISE_MSG
> Repair FINALIZE_PROPOSE_MSG
> Repair PREPARE_CONSISTENT_REQ
> Repair PREPARE_CONSISTENT_RSP
> Repair PREPARE_MSG
> Repair REPAIR_RSP
> Repair STATUS_REQ
> Repair STATUS_RSP
> Repair SYNC_REQ
> Repair SYNC_RSP
> Repair VALIDATION_REQ
> Repair VALIDATION_RSP
> Repair ASYMMETRIC_SYNC_REQ
> - Repairs, and phases, I think we'd need a bit more explanation here.
> Validation, Sync etc ok. But unsure on these other types
>
> Writes MUTATION_REQ
> Writes MUTATION_RSP
> Writes TRUNCATE_REQ
> Writes TRUNCATE_RSP
> - All types of write messages{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15773) Add test to cover metrics related to the BufferPool
[
https://issues.apache.org/jira/browse/CASSANDRA-15773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095691#comment-17095691
]
David Capwell commented on CASSANDRA-15773:
---
have a few things on my plate this week, if anyone else wants to review first
go ahead, else ill try to pick up Friday/Monday
> Add test to cover metrics related to the BufferPool
> ---
>
> Key: CASSANDRA-15773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15773
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Normal
>
> At this time there do not appear to be unit tests to validate
> {{BufferPoolMetrics}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15774) Improve range reads to query by endpoints instead of vnodes to reduce number of remote requests
[
https://issues.apache.org/jira/browse/CASSANDRA-15774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-15774:
--
Change Category: Performance
Complexity: Challenging
Status: Open (was: Triage Needed)
> Improve range reads to query by endpoints instead of vnodes to reduce number
> of remote requests
> ---
>
> Key: CASSANDRA-15774
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15774
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Coordination
>Reporter: ZhaoYang
>Priority: Normal
> Fix For: 4.x
>
>
> Currently, range read queries in batches, see
> {{StorageProxy.RangeCommandIterator#sendNextRequests()}}. For each batch, it
> computes a list of merged vnode ranges up to concurrency factor and query
> each merged vnode range asynchronously. (note: consecutive vnode ranges can
> be merged if they share enough replicas to satisfy consistency level
> requirement)
> This works fine in general, but when concurrency factor is high because
> returned row count is small comparing to query limit or index filtering is
> used, coordinator may send too many concurrent remote range requests in a
> batch.
> We can improve it by grouping remote range requests by endpoints where each
> endpoint will return response corresponding to multiple non-consecutive
> ranges. With endpoint grouping, number of remote range requests should
> largely reduced and it's always capped by number of nodes in the cluster
> instead of number of ranges which is capped by concurrency factor.
> Let's look at an example on a 5-node cluster with 10
> ranges(a,b,c,d,e,f,g,h,i,h) and rf3.
> Following is the range to replica mapping using round robin that should work
> well with consecutive range merger (consecutive range merger doesn't work
> well with fully random replica mapping, because it's less likely to have
> overlapping replicas for consecutive ranges)
> {code:java}
>range-a replicas: 1, 2, 3
>range-b replicas: 2, 3, 4
>range-c replicas: 3, 4, 5
>range-d replicas: 1, 4, 5
>range-e replicas: 1, 2, 5
>range-f replicas: 1, 2, 3
>range-g replicas: 2, 3, 4
>range-h replicas: 3, 4, 5
>range-i replicas: 1, 4, 5
>range-j replicas: 1, 2, 5
> {code}
> With default range read implementation and consecutive range merger, we need
> 10 replica read requests(2 for each merged range) for quorum:
> {code:java}
> range (a,b] on node [2, 3]
> range (c,d] on node [4, 5]
> range (e,f] on node [1, 2]
> range (g,h] on node [3, 4]
> range (i,j] on node [1, 5]
> {code}
> With group query by endpoints, we only need 4 replica read requests for
> quorum:
> {code:java}
> * node 1: a, d, e, f, i, j
> * node 2: a, b, e, f, g, j
> * node 3: b, c, g, h
> * node 4: c, d, h, i
> {code}
>
> Note that there are some complexities around short-read protection which
> needs to know whether replica has more rows available for current range.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15729) Jenkins Test Results Report in plaintext for ASF ML
[ https://issues.apache.org/jira/browse/CASSANDRA-15729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095686#comment-17095686 ] David Capwell commented on CASSANDRA-15729: --- Spoke in slack. I tested this out in Circle CI and found out the sed commands don't work in linux. I then tested the small change to work on linux and only a subset of the classes get changed (majority though); the xml can be found here https://1263-209217594-gh.circle-artifacts.com/0/cqlsh_tests/cqlshlib.xml. Looking at the file, it looks like test classname attributes only get modified if they are the first one on the line, multiple elements don't get modified on the same line. > Jenkins Test Results Report in plaintext for ASF ML > --- > > Key: CASSANDRA-15729 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15729 > Project: Cassandra > Issue Type: Task > Components: Build, CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Labels: Jenkins > Fix For: 4.0-beta > > > The Jenkins pipeline builds now aggregate all test reports. > For example: > - https://ci-cassandra.apache.org/job/Cassandra-trunk/68/testReport/ > - > https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-trunk/detail/Cassandra-trunk/68/tests > But Jenkins can only keep a limited amount of build history, so those links > are not permanent, can't be used as references, and don't help for bisecting > and blame on regressions (and flakey tests) over a longer period of time. > The builds@ ML can provide a permanent record of test results. > This was first brought up in these two threads: > - > https://lists.apache.org/thread.html/re8122e4fdd8629e7fbca2abf27d72054b3bc0e3690ece8b8e66f618b%40%3Cdev.cassandra.apache.org%3E > - > https://lists.apache.org/thread.html/ra5f6aeea89546825fe7ccc4a80898c62f8ed57decabf709d81d9c720%40%3Cdev.cassandra.apache.org%3E > An example plaintext report, to demonstrate feasibility, is available here: > https://lists.apache.org/thread.html/r80d13f7af706bf8dfbf2387fab46004c1fbd3917b7bc339c49e69aa8%40%3Cbuilds.cassandra.apache.org%3E > Hurdles: > - the ASF mailing lists won't accept html, attachments, or any message body > over 1MB. > - packages are used as a differentiator in the final aggregated report. The > cqlsh and dtests currently don't specify it. It needs to be added as a > "dot-separated" prefix to the testsuite and testcase name. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRASC-22) RESTEasy integration for Cassandra Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095639#comment-17095639 ] T Jake Luciani edited comment on CASSANDRASC-22 at 4/29/20, 4:47 PM: - -Hi,- -Is there a reason we need vert.x and jax-rs and resteasy?- -I think Jax-RS is more standard. since we have it and there's not much going on yet in the sidecar would you be ok switching (in a new ticket)?- My Bad. I realize vertx us using rest-easy. nevermind me :D Jake was (Author: tjake): Hi, Is there a reason we need vert.x and jax-rs and resteasy? I think Jax-RS is more standard. since we have it and there's not much going on yet in the sidecar would you be ok switching (in a new ticket)? Jake > RESTEasy integration for Cassandra Sidecar > -- > > Key: CASSANDRASC-22 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-22 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Dinesh Joshi >Assignee: Dinesh Joshi >Priority: Normal > Attachments: image-2020-04-27-22-59-40-060.png, > image-2020-04-29-01-14-11-756.png > > > Add support for JAX-RS based routing via RESTEasy to Cassandra Sidecar. This > also dynamically generates swagger documentation and adds the swagger UI. > [Branch|https://github.com/dineshjoshi/cassandra-sidecar/tree/resteasy-swagger] > [Tests|https://circleci.com/workflow-run/a7888146-a22d-45af-983a-8833b77eef59] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-22) RESTEasy integration for Cassandra Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095639#comment-17095639 ] T Jake Luciani commented on CASSANDRASC-22: --- Hi, Is there a reason we need vert.x and jax-rs and resteasy? I think Jax-RS is more standard. since we have it and there's not much going on yet in the sidecar would you be ok switching (in a new ticket)? Jake > RESTEasy integration for Cassandra Sidecar > -- > > Key: CASSANDRASC-22 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-22 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Dinesh Joshi >Assignee: Dinesh Joshi >Priority: Normal > Attachments: image-2020-04-27-22-59-40-060.png, > image-2020-04-29-01-14-11-756.png > > > Add support for JAX-RS based routing via RESTEasy to Cassandra Sidecar. This > also dynamically generates swagger documentation and adds the swagger UI. > [Branch|https://github.com/dineshjoshi/cassandra-sidecar/tree/resteasy-swagger] > [Tests|https://circleci.com/workflow-run/a7888146-a22d-45af-983a-8833b77eef59] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRASC-22) RESTEasy integration for Cassandra Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095600#comment-17095600 ] Jon Haddad edited comment on CASSANDRASC-22 at 4/29/20, 4:39 PM: - Using docker is far more problematic within docker images than with machine images. I've gone through this process before with another project, which is why I moved us to machine images a few weeks back. While the builds are quicker right now, I prefer not to lose functionality. The main issue with machine images is they start up a little slower, which will matter less when we have more tests. Another point - the race condition you found only surfaced due to machine images. Imo the more testing we have, the better. If you want to add another workflow that runs in the docker container, I'm +1 to that, but I'm -1 on removing the one that's already there that helped prevent us from committing a bug. was (Author: rustyrazorblade): Using docker is far more problematic within docker images than with machine images. I've gone through this process before with another project, which is why I moved us to machine images a few weeks back. While the builds are quicker right now, I prefer not to lose functionality. The main issue with machine images is they start up a little slower, which will matter less when we have more tests. Another second point - the race condition you found only surfaced due to machine images. Imo the more testing we have, the better. If you want to add another workflow that runs in the docker container, I'm +1 to that, but I'm -1 on removing the one that's already there that helped prevent us from committing a bug. > RESTEasy integration for Cassandra Sidecar > -- > > Key: CASSANDRASC-22 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-22 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Dinesh Joshi >Assignee: Dinesh Joshi >Priority: Normal > Attachments: image-2020-04-27-22-59-40-060.png, > image-2020-04-29-01-14-11-756.png > > > Add support for JAX-RS based routing via RESTEasy to Cassandra Sidecar. This > also dynamically generates swagger documentation and adds the swagger UI. > [Branch|https://github.com/dineshjoshi/cassandra-sidecar/tree/resteasy-swagger] > [Tests|https://circleci.com/workflow-run/a7888146-a22d-45af-983a-8833b77eef59] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRASC-22) RESTEasy integration for Cassandra Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095600#comment-17095600 ] Jon Haddad edited comment on CASSANDRASC-22 at 4/29/20, 4:39 PM: - Using docker is far more problematic within docker images than with machine images. I've gone through this process before with another project, which is why I moved us to machine images a few weeks back. While the builds are quicker right now, I prefer not to lose functionality. The main issue with machine images is they start up a little slower, which will matter less when we have more tests. Another second point - the race condition you found only surfaced due to machine images. Imo the more testing we have, the better. If you want to add another workflow that runs in the docker container, I'm +1 to that, but I'm -1 on removing the one that's already there that helped prevent us from committing a bug. was (Author: rustyrazorblade): Using docker is far more problematic within docker images than with machine images. I've gone through this process before with another project, which is why I moved us to machine images a few weeks back. While the builds are quicker right now, I prefer not to lose functionality. The main issue with machine images is they start up a little slower, which will matter less when we have more tests. > RESTEasy integration for Cassandra Sidecar > -- > > Key: CASSANDRASC-22 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-22 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Dinesh Joshi >Assignee: Dinesh Joshi >Priority: Normal > Attachments: image-2020-04-27-22-59-40-060.png, > image-2020-04-29-01-14-11-756.png > > > Add support for JAX-RS based routing via RESTEasy to Cassandra Sidecar. This > also dynamically generates swagger documentation and adds the swagger UI. > [Branch|https://github.com/dineshjoshi/cassandra-sidecar/tree/resteasy-swagger] > [Tests|https://circleci.com/workflow-run/a7888146-a22d-45af-983a-8833b77eef59] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15158) Wait for schema agreement rather then in flight schema requests when bootstrapping
[ https://issues.apache.org/jira/browse/CASSANDRA-15158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095605#comment-17095605 ] Blake Eggleston commented on CASSANDRA-15158: - Thanks [~stefan.miklosovic], I'm _should_ have some time to review next week. > Wait for schema agreement rather then in flight schema requests when > bootstrapping > -- > > Key: CASSANDRA-15158 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15158 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip, Cluster/Schema >Reporter: Vincent White >Assignee: Ben Bromhead >Priority: Normal > > Currently when a node is bootstrapping we use a set of latches > (org.apache.cassandra.service.MigrationTask#inflightTasks) to keep track of > in-flight schema pull requests, and we don't proceed with > bootstrapping/stream until all the latches are released (or we timeout > waiting for each one). One issue with this is that if we have a large schema, > or the retrieval of the schema from the other nodes was unexpectedly slow > then we have no explicit check in place to ensure we have actually received a > schema before we proceed. > While it's possible to increase "migration_task_wait_in_seconds" to force the > node to wait on each latche longer, there are cases where this doesn't help > because the callbacks for the schema pull requests have expired off the > messaging service's callback map > (org.apache.cassandra.net.MessagingService#callbacks) after > request_timeout_in_ms (default 10 seconds) before the other nodes were able > to respond to the new node. > This patch checks for schema agreement between the bootstrapping node and the > rest of the live nodes before proceeding with bootstrapping. It also adds a > check to prevent the new node from flooding existing nodes with simultaneous > schema pull requests as can happen in large clusters. > Removing the latch system should also prevent new nodes in large clusters > getting stuck for extended amounts of time as they wait > `migration_task_wait_in_seconds` on each of the latches left orphaned by the > timed out callbacks. > > ||3.11|| > |[PoC|https://github.com/apache/cassandra/compare/cassandra-3.11...vincewhite:check_for_schema]| > |[dtest|https://github.com/apache/cassandra-dtest/compare/master...vincewhite:wait_for_schema_agreement]| > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-22) RESTEasy integration for Cassandra Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095600#comment-17095600 ] Jon Haddad commented on CASSANDRASC-22: --- Using docker is far more problematic within docker images than with machine images. I've gone through this process before with another project, which is why I moved us to machine images a few weeks back. While the builds are quicker right now, I prefer not to lose functionality. The main issue with machine images is they start up a little slower, which will matter less when we have more tests. > RESTEasy integration for Cassandra Sidecar > -- > > Key: CASSANDRASC-22 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-22 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Dinesh Joshi >Assignee: Dinesh Joshi >Priority: Normal > Attachments: image-2020-04-27-22-59-40-060.png, > image-2020-04-29-01-14-11-756.png > > > Add support for JAX-RS based routing via RESTEasy to Cassandra Sidecar. This > also dynamically generates swagger documentation and adds the swagger UI. > [Branch|https://github.com/dineshjoshi/cassandra-sidecar/tree/resteasy-swagger] > [Tests|https://circleci.com/workflow-run/a7888146-a22d-45af-983a-8833b77eef59] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRASC-22) RESTEasy integration for Cassandra Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095600#comment-17095600 ] Jon Haddad edited comment on CASSANDRASC-22 at 4/29/20, 4:35 PM: - Using docker is far more problematic within docker images than with machine images. I've gone through this process before with another project, which is why I moved us to machine images a few weeks back. While the builds are quicker right now, I prefer not to lose functionality. The main issue with machine images is they start up a little slower, which will matter less when we have more tests. was (Author: rustyrazorblade): Using docker is far more problematic within docker images than with machine images. I've gone through this process before with another project, which is why I moved us to machine images a few weeks back. While the builds are quicker right now, I prefer not to lose functionality. The main issue with machine images is they start up a little slower, which will matter less when we have more tests. > RESTEasy integration for Cassandra Sidecar > -- > > Key: CASSANDRASC-22 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-22 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Dinesh Joshi >Assignee: Dinesh Joshi >Priority: Normal > Attachments: image-2020-04-27-22-59-40-060.png, > image-2020-04-29-01-14-11-756.png > > > Add support for JAX-RS based routing via RESTEasy to Cassandra Sidecar. This > also dynamically generates swagger documentation and adds the swagger UI. > [Branch|https://github.com/dineshjoshi/cassandra-sidecar/tree/resteasy-swagger] > [Tests|https://circleci.com/workflow-run/a7888146-a22d-45af-983a-8833b77eef59] -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15158) Wait for schema agreement rather then in flight schema requests when bootstrapping
[ https://issues.apache.org/jira/browse/CASSANDRA-15158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095596#comment-17095596 ] Stefan Miklosovic commented on CASSANDRA-15158: --- Hi [~bdeggleston], please review this one [https://github.com/smiklosovic/cassandra/tree/CASSANDRA-15158] Sorry for the fuss but this seems to be more problematic than I was thinking initially. I do not think that we have to _check_ that respective migration request is successful or not, we should just check it all schemas match ... The logic is based on repeated checking if schemas agree or not and only in case all schemas are equal we proceed, otherwise an exception is thrown (this might be reworked in such sense that we just log this). There is a global timeout for this check, it will be obvious from reading the code. There is a test added too, because of the nature of the test, I had to "inject" these callbacks into respective methods so I could modify their default behaviour and test their state. This is against 3.11, we need to backport this to 3.0 for our customer. > Wait for schema agreement rather then in flight schema requests when > bootstrapping > -- > > Key: CASSANDRA-15158 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15158 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Gossip, Cluster/Schema >Reporter: Vincent White >Assignee: Ben Bromhead >Priority: Normal > > Currently when a node is bootstrapping we use a set of latches > (org.apache.cassandra.service.MigrationTask#inflightTasks) to keep track of > in-flight schema pull requests, and we don't proceed with > bootstrapping/stream until all the latches are released (or we timeout > waiting for each one). One issue with this is that if we have a large schema, > or the retrieval of the schema from the other nodes was unexpectedly slow > then we have no explicit check in place to ensure we have actually received a > schema before we proceed. > While it's possible to increase "migration_task_wait_in_seconds" to force the > node to wait on each latche longer, there are cases where this doesn't help > because the callbacks for the schema pull requests have expired off the > messaging service's callback map > (org.apache.cassandra.net.MessagingService#callbacks) after > request_timeout_in_ms (default 10 seconds) before the other nodes were able > to respond to the new node. > This patch checks for schema agreement between the bootstrapping node and the > rest of the live nodes before proceeding with bootstrapping. It also adds a > check to prevent the new node from flooding existing nodes with simultaneous > schema pull requests as can happen in large clusters. > Removing the latch system should also prevent new nodes in large clusters > getting stuck for extended amounts of time as they wait > `migration_task_wait_in_seconds` on each of the latches left orphaned by the > timed out callbacks. > > ||3.11|| > |[PoC|https://github.com/apache/cassandra/compare/cassandra-3.11...vincewhite:check_for_schema]| > |[dtest|https://github.com/apache/cassandra-dtest/compare/master...vincewhite:wait_for_schema_agreement]| > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15774) Improve range reads to query by endpoints instead of vnodes to reduce number of remote requests
[
https://issues.apache.org/jira/browse/CASSANDRA-15774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ZhaoYang updated CASSANDRA-15774:
-
Fix Version/s: 4.x
> Improve range reads to query by endpoints instead of vnodes to reduce number
> of remote requests
> ---
>
> Key: CASSANDRA-15774
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15774
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Coordination
>Reporter: ZhaoYang
>Priority: Normal
> Fix For: 4.x
>
>
> Currently, range read queries in batches, see
> {{StorageProxy.RangeCommandIterator#sendNextRequests()}}. For each batch, it
> computes a list of merged vnode ranges up to concurrency factor and query
> each merged vnode range asynchronously. (note: consecutive vnode ranges can
> be merged if they share enough replicas to satisfy consistency level
> requirement)
> This works fine in general, but when concurrency factor is high because
> returned row count is small comparing to query limit or index filtering is
> used, coordinator may send too many concurrent remote range requests in a
> batch.
> We can improve it by grouping remote range requests by endpoints where each
> endpoint will return response corresponding to multiple non-consecutive
> ranges. With endpoint grouping, number of remote range requests should
> largely reduced and it's always capped by number of nodes in the cluster
> instead of number of ranges which is capped by concurrency factor.
> Let's look at an example on a 5-node cluster with 10
> ranges(a,b,c,d,e,f,g,h,i,h) and rf3.
> Following is the range to replica mapping using round robin that should work
> well with consecutive range merger (consecutive range merger doesn't work
> well with fully random replica mapping, because it's less likely to have
> overlapping replicas for consecutive ranges)
> {code:java}
>range-a replicas: 1, 2, 3
>range-b replicas: 2, 3, 4
>range-c replicas: 3, 4, 5
>range-d replicas: 1, 4, 5
>range-e replicas: 1, 2, 5
>range-f replicas: 1, 2, 3
>range-g replicas: 2, 3, 4
>range-h replicas: 3, 4, 5
>range-i replicas: 1, 4, 5
>range-j replicas: 1, 2, 5
> {code}
> With default range read implementation and consecutive range merger, we need
> 10 replica read requests(2 for each merged range) for quorum:
> {code:java}
> range (a,b] on node [2, 3]
> range (c,d] on node [4, 5]
> range (e,f] on node [1, 2]
> range (g,h] on node [3, 4]
> range (i,j] on node [1, 5]
> {code}
> With group query by endpoints, we only need 4 replica read requests for
> quorum:
> {code:java}
> * node 1: a, d, e, f, i, j
> * node 2: a, b, e, f, g, j
> * node 3: b, c, g, h
> * node 4: c, d, h, i
> {code}
>
> Note that there are some complexities around short-read protection which
> needs to know whether replica has more rows available for current range.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15774) Improve range reads to query by endpoints instead of vnodes to reduce number of remote requests
ZhaoYang created CASSANDRA-15774:
Summary: Improve range reads to query by endpoints instead of
vnodes to reduce number of remote requests
Key: CASSANDRA-15774
URL: https://issues.apache.org/jira/browse/CASSANDRA-15774
Project: Cassandra
Issue Type: Improvement
Components: Legacy/Coordination
Reporter: ZhaoYang
Currently, range read queries in batches, see
{{StorageProxy.RangeCommandIterator#sendNextRequests()}}. For each batch, it
computes a list of merged vnode ranges up to concurrency factor and query each
merged vnode range asynchronously. (note: consecutive vnode ranges can be
merged if they share enough replicas to satisfy consistency level requirement)
This works fine in general, but when concurrency factor is high because
returned row count is small comparing to query limit or index filtering is
used, coordinator may send too many concurrent remote range requests in a batch.
We can improve it by grouping remote range requests by endpoints where each
endpoint will return response corresponding to multiple non-consecutive ranges.
With endpoint grouping, number of remote range requests should largely reduced
and it's always capped by number of nodes in the cluster instead of number of
ranges which is capped by concurrency factor.
Let's look at an example on a 5-node cluster with 10
ranges(a,b,c,d,e,f,g,h,i,h) and rf3.
Following is the range to replica mapping using round robin that should work
well with consecutive range merger (consecutive range merger doesn't work well
with fully random replica mapping, because it's less likely to have overlapping
replicas for consecutive ranges)
{code:java}
range-a replicas: 1, 2, 3
range-b replicas: 2, 3, 4
range-c replicas: 3, 4, 5
range-d replicas: 1, 4, 5
range-e replicas: 1, 2, 5
range-f replicas: 1, 2, 3
range-g replicas: 2, 3, 4
range-h replicas: 3, 4, 5
range-i replicas: 1, 4, 5
range-j replicas: 1, 2, 5
{code}
With default range read implementation and consecutive range merger, we need 10
replica read requests(2 for each merged range) for quorum:
{code:java}
range (a,b] on node [2, 3]
range (c,d] on node [4, 5]
range (e,f] on node [1, 2]
range (g,h] on node [3, 4]
range (i,j] on node [1, 5]
{code}
With group query by endpoints, we only need 4 replica read requests for quorum:
{code:java}
* node 1: a, d, e, f, i, j
* node 2: a, b, e, f, g, j
* node 3: b, c, g, h
* node 4: c, d, h, i
{code}
Note that there are some complexities around short-read protection which needs
to know whether replica has more rows available for current range.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15773) Add test to cover metrics related to the BufferPool
[
https://issues.apache.org/jira/browse/CASSANDRA-15773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-15773:
-
Reviewers: Dinesh Joshi
> Add test to cover metrics related to the BufferPool
> ---
>
> Key: CASSANDRA-15773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15773
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Normal
>
> At this time there do not appear to be unit tests to validate
> {{BufferPoolMetrics}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15773) Add test to cover metrics related to the BufferPool
[
https://issues.apache.org/jira/browse/CASSANDRA-15773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-15773:
-
Status: Open (was: Triage Needed)
> Add test to cover metrics related to the BufferPool
> ---
>
> Key: CASSANDRA-15773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15773
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Normal
>
> At this time there do not appear to be unit tests to validate
> {{BufferPoolMetrics}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15773) Add test to cover metrics related to the BufferPool
[
https://issues.apache.org/jira/browse/CASSANDRA-15773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dinesh Joshi updated CASSANDRA-15773:
-
Status: Patch Available (was: Open)
> Add test to cover metrics related to the BufferPool
> ---
>
> Key: CASSANDRA-15773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15773
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Normal
>
> At this time there do not appear to be unit tests to validate
> {{BufferPoolMetrics}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15773) Add test to cover metrics related to the BufferPool
[
https://issues.apache.org/jira/browse/CASSANDRA-15773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095572#comment-17095572
]
Stephen Mallette commented on CASSANDRA-15773:
--
Please find this new test here for review:
https://github.com/apache/cassandra/compare/trunk...spmallette:CASSANDRA-15773-trunk
> Add test to cover metrics related to the BufferPool
> ---
>
> Key: CASSANDRA-15773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15773
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Normal
>
> At this time there do not appear to be unit tests to validate
> {{BufferPoolMetrics}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15773) Add test to cover metrics related to the BufferPool
[
https://issues.apache.org/jira/browse/CASSANDRA-15773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette updated CASSANDRA-15773:
-
Change Category: Quality Assurance
Complexity: Low Hanging Fruit
Test and Documentation Plan: additional unit tests
> Add test to cover metrics related to the BufferPool
> ---
>
> Key: CASSANDRA-15773
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15773
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Stephen Mallette
>Assignee: Stephen Mallette
>Priority: Normal
>
> At this time there do not appear to be unit tests to validate
> {{BufferPoolMetrics}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15582) 4.0 quality testing: metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-15582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095565#comment-17095565
]
Stephen Mallette commented on CASSANDRA-15582:
--
I just added CASSANDRA-15773 to add tests for {{BufferPoolMetrics}} - I didn't
see any tests related to those metrics.
> 4.0 quality testing: metrics
>
>
> Key: CASSANDRA-15582
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15582
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest
>Reporter: Josh McKenzie
>Assignee: Romain Hardouin
>Priority: Normal
> Fix For: 4.0-rc
>
> Attachments: Screen Shot 2020-04-07 at 5.47.17 PM.png
>
>
> In past releases we've unknowingly broken metrics integrations and introduced
> performance regressions in metrics collection and reporting. We strive in 4.0
> to not do that. Metrics should work well!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15773) Add test to cover metrics related to the BufferPool
Stephen Mallette created CASSANDRA-15773:
Summary: Add test to cover metrics related to the BufferPool
Key: CASSANDRA-15773
URL: https://issues.apache.org/jira/browse/CASSANDRA-15773
Project: Cassandra
Issue Type: Improvement
Components: Test/unit
Reporter: Stephen Mallette
Assignee: Stephen Mallette
At this time there do not appear to be unit tests to validate
{{BufferPoolMetrics}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15772) DOC - Improve tpstats documentation
[
https://issues.apache.org/jira/browse/CASSANDRA-15772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Curtis updated CASSANDRA-15772:
Description:
h2. Background
The docs for {{nodetool tpstats}} gives the user a good overview of the correct
command format, but lack an explanation of the message types.
As of Cassandra4.0 and CASSANDRA-15066 the Message types have expanded a lot so
this becomes quite overwhelming (particularly for new users).
I'd propose we offer a simple explanation of these grouping them into logical
groups (see CASSANDRA-15771 which I opened for the formatting output).
The github code for the {{Verb.java}} class does give the user some idea of
what these are but not everyone will go looking for that.
h2. Example
Code for ref
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/Verb.java]
I tried to sort some of the tpstats output into categories and made a first
attempt at an explanation here:
{code:java}
BatchesBATCH_REMOVE_REQ
BatchesBATCH_REMOVE_RSP
BatchesBATCH_STORE_REQ
BatchesBATCH_STORE_RSP
- These are batches, I'd assume the store / removes are as we add and process
them?
Counters COUNTER_MUTATION_REQ
Counters COUNTER_MUTATION_RSP
- Counter writes
Deprecated INTERNAL_RSP
Deprecated REQUEST_RSP
- Some of these are shown as deprecated in the code. Not sure what we should
add here
Gossip ECHO_REQ
Gossip ECHO_RSP
Gossip GOSSIP_DIGEST_ACK
Gossip GOSSIP_DIGEST_ACK2
Gossip GOSSIP_DIGEST_SYN
Gossip GOSSIP_SHUTDOWN
Gossip PING_REQ
Gossip PING_RSP
- Gossip, probably we'd refer to a more detailed page on gossip from here
Hints HINT_REQ
Hints HINT_RSP
- Hints!
LWTs PAXOS_COMMIT_REQ
LWTs PAXOS_COMMIT_RSP
LWTs PAXOS_PREPARE_REQ
LWTs PAXOS_PREPARE_RSP
LWTs PAXOS_PROPOSE_REQ
LWTs PAXOS_PROPOSE_RSP
- Paxos phases request / response
Migration SCHEMA_PULL_REQ
Migration SCHEMA_PULL_RSP
Migration SCHEMA_PUSH_REQ
Migration SCHEMA_PUSH_RSP
Migration SCHEMA_VERSION_REQ
Migration SCHEMA_VERSION_RSP
- Schema migration messaging (i.e. adding new tables)
Misc REPLICATION_DONE_REQ
Misc REPLICATION_DONE_RSP
Misc SNAPSHOT_MSG
Misc SNAPSHOT_REQ
Misc SNAPSHOT_RSP
- Unsure of these, could the snapshots be for simply nodetool snapshot requests
like on truncates?
Reads RANGE_REQ
Reads RANGE_RSP
Reads READ_REPAIR_REQ
Reads READ_REPAIR_RSP
Reads READ_REQ
Reads READ_RSP
- All types of read messages
Repair CLEANUP_MSG
Repair FAILED_SESSION_MSG
Repair FAILURE_RSP
Repair FINALIZE_COMMIT_MSG
Repair FINALIZE_PROMISE_MSG
Repair FINALIZE_PROPOSE_MSG
Repair PREPARE_CONSISTENT_REQ
Repair PREPARE_CONSISTENT_RSP
Repair PREPARE_MSG
Repair REPAIR_RSP
Repair STATUS_REQ
Repair STATUS_RSP
Repair SYNC_REQ
Repair SYNC_RSP
Repair VALIDATION_REQ
Repair VALIDATION_RSP
Repair ASYMMETRIC_SYNC_REQ
- Repairs, and phases, I think we'd need a bit more explanation here.
Validation, Sync etc ok. But unsure on these other types
Writes MUTATION_REQ
Writes MUTATION_RSP
Writes TRUNCATE_REQ
Writes TRUNCATE_RSP
- All types of write messages{code}
was:
h2. Background
The docs for {{nodetool tpstats}} gives the user a good overview of the correct
command format, but lack an explanation of the message types.
As of Cassandra4.0 and CASSANDRA-15066 the Message types have expanded a lot so
this becomes quite overwhelming (particularly for new users).
I'd propose we offer a simple explanation of these grouping them into logical
groups (see CASSANDRA-15771 which I opened for the formatting output).
The github code for the {{Verb.java}} class does give the user some idea of
what these are but not everyone will go looking for that.
Example
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/Verb.java]
> DOC - Improve tpstats documentation
> ---
>
> Key: CASSANDRA-15772
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15772
> Project: Cassandra
> Issue Type: Improvement
> Components:
[jira] [Updated] (CASSANDRA-15770) stop and restart fail in Debian 10 buster
[
https://issues.apache.org/jira/browse/CASSANDRA-15770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15770:
-
Fix Version/s: 3.0.21
> stop and restart fail in Debian 10 buster
> -
>
> Key: CASSANDRA-15770
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15770
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Vicente Jimenez Aguilar
>Assignee: Vicente Jimenez Aguilar
>Priority: Normal
> Labels: Debian, easyfix, patch
> Fix For: 3.0.21, 3.11.7, 4.0-alpha
>
> Attachments: 0001-Fix-init-script-for-debian-Buster.patch
>
>
> Debian 10 "buster" has an updated {{start-stop-daemon}} version that causes
> init script to fail to stop or restart Cassandra daemon. {{stop}} option do
> not stops first launched instance and depending of previous operations,
> {{restart}} and {{start}} could launch a second Cassandra daemon instance.
> {{start-stop-daemon}} since version 1.19.3 fail to stop matching only a
> pidfile that can be writen by an unprivileged (non-root) user because it is
> considered a security risk.
> Adding a second matching option (user) solved this.
> This fix does not break compatibility with older versions and does not mess
> with pidfile's mode or permissions.
> Related: CASSANDRA-15099
> https://github.com/vice/cassandra/tree/debian-buster
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15770) stop and restart fail in Debian 10 buster
[
https://issues.apache.org/jira/browse/CASSANDRA-15770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15770:
-
Fix Version/s: (was: 3.11.6)
4.0-alpha
3.11.7
> stop and restart fail in Debian 10 buster
> -
>
> Key: CASSANDRA-15770
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15770
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Vicente Jimenez Aguilar
>Assignee: Vicente Jimenez Aguilar
>Priority: Normal
> Labels: Debian, easyfix, patch
> Fix For: 3.11.7, 4.0-alpha
>
> Attachments: 0001-Fix-init-script-for-debian-Buster.patch
>
>
> Debian 10 "buster" has an updated {{start-stop-daemon}} version that causes
> init script to fail to stop or restart Cassandra daemon. {{stop}} option do
> not stops first launched instance and depending of previous operations,
> {{restart}} and {{start}} could launch a second Cassandra daemon instance.
> {{start-stop-daemon}} since version 1.19.3 fail to stop matching only a
> pidfile that can be writen by an unprivileged (non-root) user because it is
> considered a security risk.
> Adding a second matching option (user) solved this.
> This fix does not break compatibility with older versions and does not mess
> with pidfile's mode or permissions.
> Related: CASSANDRA-15099
> https://github.com/vice/cassandra/tree/debian-buster
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15770) stop and restart fail in Debian 10 buster
[
https://issues.apache.org/jira/browse/CASSANDRA-15770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15770:
-
Test and Documentation Plan: none
Status: Patch Available (was: Open)
> stop and restart fail in Debian 10 buster
> -
>
> Key: CASSANDRA-15770
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15770
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Vicente Jimenez Aguilar
>Assignee: Vicente Jimenez Aguilar
>Priority: Normal
> Labels: Debian, easyfix, patch
> Fix For: 3.11.6
>
> Attachments: 0001-Fix-init-script-for-debian-Buster.patch
>
>
> Debian 10 "buster" has an updated {{start-stop-daemon}} version that causes
> init script to fail to stop or restart Cassandra daemon. {{stop}} option do
> not stops first launched instance and depending of previous operations,
> {{restart}} and {{start}} could launch a second Cassandra daemon instance.
> {{start-stop-daemon}} since version 1.19.3 fail to stop matching only a
> pidfile that can be writen by an unprivileged (non-root) user because it is
> considered a security risk.
> Adding a second matching option (user) solved this.
> This fix does not break compatibility with older versions and does not mess
> with pidfile's mode or permissions.
> Related: CASSANDRA-15099
> https://github.com/vice/cassandra/tree/debian-buster
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15770) stop and restart fail in Debian 10 buster
[
https://issues.apache.org/jira/browse/CASSANDRA-15770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15770:
-
Reviewers: Brandon Williams, Brandon Williams (was: Brandon Williams)
Brandon Williams, Brandon Williams (was: Brandon Williams)
Status: Review In Progress (was: Patch Available)
> stop and restart fail in Debian 10 buster
> -
>
> Key: CASSANDRA-15770
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15770
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Vicente Jimenez Aguilar
>Assignee: Vicente Jimenez Aguilar
>Priority: Normal
> Labels: Debian, easyfix, patch
> Fix For: 3.11.6
>
> Attachments: 0001-Fix-init-script-for-debian-Buster.patch
>
>
> Debian 10 "buster" has an updated {{start-stop-daemon}} version that causes
> init script to fail to stop or restart Cassandra daemon. {{stop}} option do
> not stops first launched instance and depending of previous operations,
> {{restart}} and {{start}} could launch a second Cassandra daemon instance.
> {{start-stop-daemon}} since version 1.19.3 fail to stop matching only a
> pidfile that can be writen by an unprivileged (non-root) user because it is
> considered a security risk.
> Adding a second matching option (user) solved this.
> This fix does not break compatibility with older versions and does not mess
> with pidfile's mode or permissions.
> Related: CASSANDRA-15099
> https://github.com/vice/cassandra/tree/debian-buster
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15770) stop and restart fail in Debian 10 buster
[
https://issues.apache.org/jira/browse/CASSANDRA-15770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15770:
-
Bug Category: Parent values: Correctness(12982)
Complexity: Low Hanging Fruit
Component/s: Packaging
Discovered By: User Report
Reviewers: Brandon Williams
Severity: Normal
Assignee: Vicente Jimenez Aguilar
Status: Open (was: Triage Needed)
> stop and restart fail in Debian 10 buster
> -
>
> Key: CASSANDRA-15770
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15770
> Project: Cassandra
> Issue Type: Bug
> Components: Packaging
>Reporter: Vicente Jimenez Aguilar
>Assignee: Vicente Jimenez Aguilar
>Priority: Normal
> Labels: Debian, easyfix, patch
> Fix For: 3.11.6
>
> Attachments: 0001-Fix-init-script-for-debian-Buster.patch
>
>
> Debian 10 "buster" has an updated {{start-stop-daemon}} version that causes
> init script to fail to stop or restart Cassandra daemon. {{stop}} option do
> not stops first launched instance and depending of previous operations,
> {{restart}} and {{start}} could launch a second Cassandra daemon instance.
> {{start-stop-daemon}} since version 1.19.3 fail to stop matching only a
> pidfile that can be writen by an unprivileged (non-root) user because it is
> considered a security risk.
> Adding a second matching option (user) solved this.
> This fix does not break compatibility with older versions and does not mess
> with pidfile's mode or permissions.
> Related: CASSANDRA-15099
> https://github.com/vice/cassandra/tree/debian-buster
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (398760d -> 4db8d07)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. from 398760d generate docs for 338bcc26 add eac9158 Make sure the home directory in the docker container has correct permissions new 4db8d07 generate docs for eac91582 The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: Dockerfile | 17 + content/feed.xml | 2 +- docker-entrypoint.sh | 3 ++- 3 files changed, 12 insertions(+), 10 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] 01/01: generate docs for eac91582
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a commit to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git commit 4db8d079d18ba8cf50c4e4bbc63b9cefbeed2154 Author: jenkins AuthorDate: Wed Apr 29 15:23:08 2020 + generate docs for eac91582 --- content/feed.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/feed.xml b/content/feed.xml index c24297f..53b14a6 100644 --- a/content/feed.xml +++ b/content/feed.xml @@ -1,4 +1,4 @@ -http://www.w3.org/2005/Atom; >https://jekyllrb.com/; version="3.4.3">Jekyllhttp://cassandra.apache.org/feed.xml; rel="self" type="application/atom+xml" />http://cassandra.apache.org/; rel="alternate" type="text/html" />2020-04-29T15:06:48+00:00http://cassandra.apache.org/Apache Cassandra WebsiteThe Apache Cassandra databas [...] +http://www.w3.org/2005/Atom; >https://jekyllrb.com/; version="3.4.3">Jekyllhttp://cassandra.apache.org/feed.xml; rel="self" type="application/atom+xml" />http://cassandra.apache.org/; rel="alternate" type="text/html" />2020-04-29T15:22:52+00:00http://cassandra.apache.org/Apache Cassandra WebsiteThe Apache Cassandra databas [...] Even Higher Availability with 5x Faster Streaming in Cassandra 4.0http://cassandra.apache.org/blog/2019/04/09/benchmarking_streaming.html; rel="alternate" type="text/html" title="Even Higher Availability with 5x Faster Streaming in Cassandra 4.0"
[jira] [Updated] (CASSANDRA-15771) Nodetool tpstats formatting / grouping to make more logical output
[
https://issues.apache.org/jira/browse/CASSANDRA-15771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Curtis updated CASSANDRA-15771:
Fix Version/s: (was: 4.0-alpha)
> Nodetool tpstats formatting / grouping to make more logical output
> --
>
> Key: CASSANDRA-15771
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15771
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Internode
>Reporter: Mark Curtis
>Priority: Normal
> Labels: 4.0
>
> The new messaging format for Cassandra 4.0 outlined in CASSANDRA-15066
> introduces a lot more info into the output of {{nodetool tpstats}} output.
> It would be useful to output this in groups like it is listed in the enum in
> the code here:
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/Verb.java]
> At the moment (4.0-alpha5-SNAPSHOT) the output doesn't appear to be ordered.
> I did notice CASSANDRA-12035 but it seems this is only in 3.11 ?
> h3. Example output
>
> {code:java}
> Pool Name Active Pending Completed Blocked
> All time blocked
> CompactionExecutor 0 0 6811 0
> 0
> MemtableReclaimMemory 0 0 26 0
> 0
> PendingRangeCalculator 0 0 8 0
> 0
> GossipStage0 0 33919 0
> 0
> SecondaryIndexManagement 0 0 0 0
> 0
> HintsDispatcher0 0 0 0
> 0
> Repair-Task0 0 0 0
> 0
> RequestResponseStage 0 0 1 0
> 0
> MigrationStage 0 0 8 0
> 0
> MemtablePostFlush 0 0 33 0
> 0
> PerDiskMemtableFlushWriter_0 0 0 26 0
> 0
> ValidationExecutor 0 0 0 0
> 0
> Sampler0 0 0 0
> 0
> ViewBuildExecutor 0 0 0 0
> 0
> MemtableFlushWriter0 0 26 0
> 0
> CacheCleanupExecutor 0 0 0 0
> 0Message type Dropped Latency
> waiting in queue (micros)
> 50% 95%
>99% Max
> READ_RSP 0 0.00 0.00
> 0.00 0.00
> RANGE_REQ0 0.00 0.00
> 0.00 0.00
> PING_REQ 0 0.00 0.00
> 0.00 0.00
> _SAMPLE 0 0.00 0.00
> 0.00 0.00
> VALIDATION_RSP 0 0.00 0.00
> 0.00 0.00
> SCHEMA_PULL_RSP 0 0.00 0.00
> 0.00 0.00
> SYNC_RSP 0 0.00 0.00
> 0.00 0.00
> SCHEMA_VERSION_REQ 0 0.00 0.00
> 0.00 0.00
> HINT_RSP 0 0.00 0.00
> 0.00 0.00
> BATCH_REMOVE_RSP 0 0.00 0.00
> 0.00 0.00
> PAXOS_COMMIT_REQ 0 0.00 0.00
> 0.00 0.00
> SNAPSHOT_RSP 0 0.00 0.00
> 0.00 0.00
> COUNTER_MUTATION_REQ 0 0.00 0.00
> 0.00 0.00
> GOSSIP_DIGEST_SYN0 1955.67 4055.27
> 4866.32 4866.32
> PAXOS_PREPARE_REQ0 0.00 0.00
> 0.00 0.00
> PREPARE_MSG 0 0.00 0.00
> 0.00 0.00
> PAXOS_COMMIT_RSP 0 0.00 0.00
> 0.00 0.00
> HINT_REQ 0
[jira] [Updated] (CASSANDRA-15771) Nodetool tpstats formatting / grouping to make more logical output
[
https://issues.apache.org/jira/browse/CASSANDRA-15771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Curtis updated CASSANDRA-15771:
Fix Version/s: 4.0-alpha
> Nodetool tpstats formatting / grouping to make more logical output
> --
>
> Key: CASSANDRA-15771
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15771
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Internode
>Reporter: Mark Curtis
>Priority: Normal
> Labels: 4.0
> Fix For: 4.0-alpha
>
>
> The new messaging format for Cassandra 4.0 outlined in CASSANDRA-15066
> introduces a lot more info into the output of {{nodetool tpstats}} output.
> It would be useful to output this in groups like it is listed in the enum in
> the code here:
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/Verb.java]
> At the moment (4.0-alpha5-SNAPSHOT) the output doesn't appear to be ordered.
> I did notice CASSANDRA-12035 but it seems this is only in 3.11 ?
> h3. Example output
>
> {code:java}
> Pool Name Active Pending Completed Blocked
> All time blocked
> CompactionExecutor 0 0 6811 0
> 0
> MemtableReclaimMemory 0 0 26 0
> 0
> PendingRangeCalculator 0 0 8 0
> 0
> GossipStage0 0 33919 0
> 0
> SecondaryIndexManagement 0 0 0 0
> 0
> HintsDispatcher0 0 0 0
> 0
> Repair-Task0 0 0 0
> 0
> RequestResponseStage 0 0 1 0
> 0
> MigrationStage 0 0 8 0
> 0
> MemtablePostFlush 0 0 33 0
> 0
> PerDiskMemtableFlushWriter_0 0 0 26 0
> 0
> ValidationExecutor 0 0 0 0
> 0
> Sampler0 0 0 0
> 0
> ViewBuildExecutor 0 0 0 0
> 0
> MemtableFlushWriter0 0 26 0
> 0
> CacheCleanupExecutor 0 0 0 0
> 0Message type Dropped Latency
> waiting in queue (micros)
> 50% 95%
>99% Max
> READ_RSP 0 0.00 0.00
> 0.00 0.00
> RANGE_REQ0 0.00 0.00
> 0.00 0.00
> PING_REQ 0 0.00 0.00
> 0.00 0.00
> _SAMPLE 0 0.00 0.00
> 0.00 0.00
> VALIDATION_RSP 0 0.00 0.00
> 0.00 0.00
> SCHEMA_PULL_RSP 0 0.00 0.00
> 0.00 0.00
> SYNC_RSP 0 0.00 0.00
> 0.00 0.00
> SCHEMA_VERSION_REQ 0 0.00 0.00
> 0.00 0.00
> HINT_RSP 0 0.00 0.00
> 0.00 0.00
> BATCH_REMOVE_RSP 0 0.00 0.00
> 0.00 0.00
> PAXOS_COMMIT_REQ 0 0.00 0.00
> 0.00 0.00
> SNAPSHOT_RSP 0 0.00 0.00
> 0.00 0.00
> COUNTER_MUTATION_REQ 0 0.00 0.00
> 0.00 0.00
> GOSSIP_DIGEST_SYN0 1955.67 4055.27
> 4866.32 4866.32
> PAXOS_PREPARE_REQ0 0.00 0.00
> 0.00 0.00
> PREPARE_MSG 0 0.00 0.00
> 0.00 0.00
> PAXOS_COMMIT_RSP 0 0.00 0.00
> 0.00 0.00
> HINT_REQ
[jira] [Updated] (CASSANDRA-15771) Nodetool tpstats formatting / grouping to make more logical output
[
https://issues.apache.org/jira/browse/CASSANDRA-15771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Curtis updated CASSANDRA-15771:
Change Category: Operability
> Nodetool tpstats formatting / grouping to make more logical output
> --
>
> Key: CASSANDRA-15771
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15771
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Internode
>Reporter: Mark Curtis
>Priority: Normal
> Labels: 4.0
>
> The new messaging format for Cassandra 4.0 outlined in CASSANDRA-15066
> introduces a lot more info into the output of {{nodetool tpstats}} output.
> It would be useful to output this in groups like it is listed in the enum in
> the code here:
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/Verb.java]
> At the moment (4.0-alpha5-SNAPSHOT) the output doesn't appear to be ordered.
> I did notice CASSANDRA-12035 but it seems this is only in 3.11 ?
> h3. Example output
>
> {code:java}
> Pool Name Active Pending Completed Blocked
> All time blocked
> CompactionExecutor 0 0 6811 0
> 0
> MemtableReclaimMemory 0 0 26 0
> 0
> PendingRangeCalculator 0 0 8 0
> 0
> GossipStage0 0 33919 0
> 0
> SecondaryIndexManagement 0 0 0 0
> 0
> HintsDispatcher0 0 0 0
> 0
> Repair-Task0 0 0 0
> 0
> RequestResponseStage 0 0 1 0
> 0
> MigrationStage 0 0 8 0
> 0
> MemtablePostFlush 0 0 33 0
> 0
> PerDiskMemtableFlushWriter_0 0 0 26 0
> 0
> ValidationExecutor 0 0 0 0
> 0
> Sampler0 0 0 0
> 0
> ViewBuildExecutor 0 0 0 0
> 0
> MemtableFlushWriter0 0 26 0
> 0
> CacheCleanupExecutor 0 0 0 0
> 0Message type Dropped Latency
> waiting in queue (micros)
> 50% 95%
>99% Max
> READ_RSP 0 0.00 0.00
> 0.00 0.00
> RANGE_REQ0 0.00 0.00
> 0.00 0.00
> PING_REQ 0 0.00 0.00
> 0.00 0.00
> _SAMPLE 0 0.00 0.00
> 0.00 0.00
> VALIDATION_RSP 0 0.00 0.00
> 0.00 0.00
> SCHEMA_PULL_RSP 0 0.00 0.00
> 0.00 0.00
> SYNC_RSP 0 0.00 0.00
> 0.00 0.00
> SCHEMA_VERSION_REQ 0 0.00 0.00
> 0.00 0.00
> HINT_RSP 0 0.00 0.00
> 0.00 0.00
> BATCH_REMOVE_RSP 0 0.00 0.00
> 0.00 0.00
> PAXOS_COMMIT_REQ 0 0.00 0.00
> 0.00 0.00
> SNAPSHOT_RSP 0 0.00 0.00
> 0.00 0.00
> COUNTER_MUTATION_REQ 0 0.00 0.00
> 0.00 0.00
> GOSSIP_DIGEST_SYN0 1955.67 4055.27
> 4866.32 4866.32
> PAXOS_PREPARE_REQ0 0.00 0.00
> 0.00 0.00
> PREPARE_MSG 0 0.00 0.00
> 0.00 0.00
> PAXOS_COMMIT_RSP 0 0.00 0.00
> 0.00 0.00
> HINT_REQ 0 0.00
[jira] [Commented] (CASSANDRA-15732) DOC - Update details of new book "Cassandra: The Definitive Guide"
[ https://issues.apache.org/jira/browse/CASSANDRA-15732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095536#comment-17095536 ] Michael Semb Wever commented on CASSANDRA-15732: Live. > DOC - Update details of new book "Cassandra: The Definitive Guide" > -- > > Key: CASSANDRA-15732 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15732 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Erick Ramirez >Assignee: Anthony Grasso >Priority: Normal > Labels: pull-request-available > Fix For: 4.0-alpha > > Attachments: > 20200429_Apache_Cassandra_Community_page_proposed_change.png > > > There is a new edition of the book "Cassandra: The Definitive Guide" by Jeff > Carpenter and Eben Hewitt. > * 3rd edition > * updated for Cassandra 4.0 > * https://www.amazon.com/gp/product/1098115163/ > Need to update the Community page. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch master updated (398760d -> eac9158)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/cassandra-website.git. from 398760d generate docs for 338bcc26 add eac9158 Make sure the home directory in the docker container has correct permissions No new revisions were added by this update. Summary of changes: Dockerfile | 17 + docker-entrypoint.sh | 3 ++- 2 files changed, 11 insertions(+), 9 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
