[jira] [Updated] (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:all-tabpanel
]
Joseph Lynch updated CASSANDRA-15146:
-
Description:
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.
was:
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
[jira] [Updated] (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:all-tabpanel
]
Joseph Lynch updated CASSANDRA-15146:
-
Severity: Low
Complexity: Low Hanging Fruit
Discovered By: User Report
Bug Category: Parent values: Correctness(12982)
Status: Open (was: Triage Needed)
> 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: Local/Config
>Reporter: Joseph Lynch
>Assignee: Joseph Lynch
>Priority: Normal
>
> 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 listen for either encrypted or unencrypted|
> |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 connecitons
> (all except for the first) 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
> 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
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15146) Transitional TLS server configuration options are overly complex
[
https://issues.apache.org/jira/browse/CASSANDRA-15146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Lynch updated CASSANDRA-15146:
-
Component/s: Local/Config
> 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: Local/Config
>Reporter: Joseph Lynch
>Assignee: Joseph Lynch
>Priority: Normal
>
> 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 listen for either encrypted or unencrypted|
> |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 connecitons
> (all except for the first) 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
> 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
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15146) Transitional TLS server configuration options are overly complex
[
https://issues.apache.org/jira/browse/CASSANDRA-15146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Lynch updated CASSANDRA-15146:
-
Summary: Transitional TLS server configuration options are overly complex
(was: Transitional TLS configuration options are overly complex)
> 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
>Reporter: Joseph Lynch
>Assignee: Joseph Lynch
>Priority: Normal
>
> 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 listen for either encrypted or unencrypted|
> |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 connecitons
> (all except for the first) 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
> 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
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15146) Transitional TLS configuration options are overly complex
Joseph Lynch created CASSANDRA-15146:
Summary: Transitional TLS configuration options are overly complex
Key: CASSANDRA-15146
URL: https://issues.apache.org/jira/browse/CASSANDRA-15146
Project: Cassandra
Issue Type: Bug
Reporter: Joseph Lynch
Assignee: Joseph Lynch
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 listen for either encrypted or unencrypted|
|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 connecitons (all
>except for the first) 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
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
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15145) Error in Cassandra database
[
https://issues.apache.org/jira/browse/CASSANDRA-15145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16851807#comment-16851807
]
Pradip Kumar commented on CASSANDRA-15145:
--
Please find my inline comments for the same.
1. you got one node with keyspace replication of one ,right ?
Ans: yes
2. you insert some key into c*;
Ans: yes
3. you do some load test ? what kind of operations ?
Ans: insert & update operations
4. you do some select ,then occurs exception ? i guess you do operation through
some srping dao ? give more details ,and does the reproduce every time ? you do
this steps ? if does ,i can reproduce by myself .
Ans: first bulk records inserted in transaction_dump table and then for
processing we fetch the records from the same table and after process update
the status in the same table transaction_dump and other tables also.
> Error in Cassandra database
> ---
>
> Key: CASSANDRA-15145
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15145
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Testing
>Reporter: Pradip Kumar
>Priority: Normal
> Fix For: 3.11.x
>
>
> Dear Team,
> We are facing the problem in the Cassandra database and below the error
> message and after this error application stopped working.
> Please suggest why this issue occurred and what I have to do for resolving
> the issue?
> *Cassandra:- [cqlsh 5.0.1 | Cassandra 3.11.3 | CQL spec 3.4.4 | Native
> protocol v4]*
>
> v\:* \{behavior:url(#default#VML);} o\:* \{behavior:url(#default#VML);} w\:*
> \{behavior:url(#default#VML);} .shape \{behavior:url(#default#VML);}
> 2019-05-29 13:58:47.673 INFO 2003 — [ryBean_Worker-1]
> com.estel.common.MoneyMarkingJob : Job for Leger Management is
> strated at 2019-05-30T00:58:47.671Z time zone
> org.springframework.dao.DataAccessResourceFailureException: Cassandra failure
> during read query at consistency LOCAL_ONE (1 responses were required but
> only 0 replica responded, 1 failed); nested exception is
> com.datastax.driver.core.exceptions.ReadFailureException: Cassandra failure
> during read query at consistency LOCAL_ONE (1 responses were required but
> only 0 replica responded, 1 failed)
> at
> org.springframework.cassandra.support.CassandraExceptionTranslator.translateExceptionIfPossible(CassandraExceptionTranslator.java:163)
> at
> org.springframework.cassandra.core.CqlTemplate.potentiallyConvertRuntimeException(CqlTemplate.java:946)
> at
> org.springframework.cassandra.core.CqlTemplate.translateExceptionIfPossible(CqlTemplate.java:930)
> at
> org.springframework.cassandra.core.CqlTemplate.translateExceptionIfPossible(CqlTemplate.java:912)
> at
> org.springframework.cassandra.core.CqlTemplate.doExecute(CqlTemplate.java:278)
> at
> org.springframework.cassandra.core.CqlTemplate.doExecuteQueryReturnResultSet(CqlTemplate.java:283)
> at
> org.springframework.data.cassandra.core.CassandraTemplate.select(CassandraTemplate.java:594)
> at
> org.springframework.data.cassandra.core.CassandraTemplate.select(CassandraTemplate.java:376)
> at
> org.springframework.data.cassandra.repository.query.CassandraQueryExecution$CollectionExecution.execute(CassandraQueryExecution.java:85)
> at
> org.springframework.data.cassandra.repository.query.CassandraQueryExecution$ResultProcessingExecution.execute(CassandraQueryExecution.java:143)
> at
> org.springframework.data.cassandra.repository.query.AbstractCassandraQuery.execute(AbstractCassandraQuery.java:113)
> at
> org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.doInvoke(RepositoryFactorySupport.java:483)
> at
> org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.invoke(RepositoryFactorySupport.java:461)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.data.projection.DefaultMethodInvokingMethodInterceptor.invoke(DefaultMethodInvokingMethodInterceptor.java:56)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.data.repository.core.support.SurroundingTransactionDetectorMethodInterceptor.invoke(SurroundingTransactionDetectorMethodInterceptor.java:57)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proc
[jira] [Commented] (CASSANDRA-15145) Error in Cassandra database
[
https://issues.apache.org/jira/browse/CASSANDRA-15145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16851743#comment-16851743
]
maxwellguo commented on CASSANDRA-15145:
1. you got one node with keyspace replication of one ,right ?
2.you insert some key into c*;
3. you do some load test ? what kind of operations ?
4.you do some select ,then occurs exception ? i guess you do operation through
some srping dao ?
give more details ,and does the reproduce every time ? you do this steps ? if
does ,i can reproduce by myself .
> Error in Cassandra database
> ---
>
> Key: CASSANDRA-15145
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15145
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Testing
>Reporter: Pradip Kumar
>Priority: Normal
> Fix For: 3.11.x
>
>
> Dear Team,
> We are facing the problem in the Cassandra database and below the error
> message and after this error application stopped working.
> Please suggest why this issue occurred and what I have to do for resolving
> the issue?
> *Cassandra:- [cqlsh 5.0.1 | Cassandra 3.11.3 | CQL spec 3.4.4 | Native
> protocol v4]*
>
> v\:* \{behavior:url(#default#VML);} o\:* \{behavior:url(#default#VML);} w\:*
> \{behavior:url(#default#VML);} .shape \{behavior:url(#default#VML);}
> 2019-05-29 13:58:47.673 INFO 2003 — [ryBean_Worker-1]
> com.estel.common.MoneyMarkingJob : Job for Leger Management is
> strated at 2019-05-30T00:58:47.671Z time zone
> org.springframework.dao.DataAccessResourceFailureException: Cassandra failure
> during read query at consistency LOCAL_ONE (1 responses were required but
> only 0 replica responded, 1 failed); nested exception is
> com.datastax.driver.core.exceptions.ReadFailureException: Cassandra failure
> during read query at consistency LOCAL_ONE (1 responses were required but
> only 0 replica responded, 1 failed)
> at
> org.springframework.cassandra.support.CassandraExceptionTranslator.translateExceptionIfPossible(CassandraExceptionTranslator.java:163)
> at
> org.springframework.cassandra.core.CqlTemplate.potentiallyConvertRuntimeException(CqlTemplate.java:946)
> at
> org.springframework.cassandra.core.CqlTemplate.translateExceptionIfPossible(CqlTemplate.java:930)
> at
> org.springframework.cassandra.core.CqlTemplate.translateExceptionIfPossible(CqlTemplate.java:912)
> at
> org.springframework.cassandra.core.CqlTemplate.doExecute(CqlTemplate.java:278)
> at
> org.springframework.cassandra.core.CqlTemplate.doExecuteQueryReturnResultSet(CqlTemplate.java:283)
> at
> org.springframework.data.cassandra.core.CassandraTemplate.select(CassandraTemplate.java:594)
> at
> org.springframework.data.cassandra.core.CassandraTemplate.select(CassandraTemplate.java:376)
> at
> org.springframework.data.cassandra.repository.query.CassandraQueryExecution$CollectionExecution.execute(CassandraQueryExecution.java:85)
> at
> org.springframework.data.cassandra.repository.query.CassandraQueryExecution$ResultProcessingExecution.execute(CassandraQueryExecution.java:143)
> at
> org.springframework.data.cassandra.repository.query.AbstractCassandraQuery.execute(AbstractCassandraQuery.java:113)
> at
> org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.doInvoke(RepositoryFactorySupport.java:483)
> at
> org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.invoke(RepositoryFactorySupport.java:461)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.data.projection.DefaultMethodInvokingMethodInterceptor.invoke(DefaultMethodInvokingMethodInterceptor.java:56)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.data.repository.core.support.SurroundingTransactionDetectorMethodInterceptor.invoke(SurroundingTransactionDetectorMethodInterceptor.java:57)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:213)
> at com.sun.proxy.$Proxy66.findTransactionByDatenadStatus(Unknown
> Source)
> at
> com.estel.common.service.impl.TransactionServiceImpl.fingTransactionByDateAndSta
[jira] [Commented] (CASSANDRA-15145) Error in Cassandra database
[
https://issues.apache.org/jira/browse/CASSANDRA-15145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16851670#comment-16851670
]
Pradip Kumar commented on CASSANDRA-15145:
--
Hi Maxwell,
1- We are running Cassandra on standalone server only and there is only one
node.
2- Previously the application was running fine but at the time of Load Testing
the issue was occurred,
And even not getting the output of count the records of the big table "SELECT
COUNT (*) FROM transaction_dump;" , Table "transaction_dump" having around 2
millions records only.
But the query getting the output with limit 10 like "SELECT * FROM
transaction_dump LIMIT 10;"
Please Suggest for for the issue?
Regards,
Pradip
> Error in Cassandra database
> ---
>
> Key: CASSANDRA-15145
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15145
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Testing
>Reporter: Pradip Kumar
>Priority: Normal
> Fix For: 3.11.x
>
>
> Dear Team,
> We are facing the problem in the Cassandra database and below the error
> message and after this error application stopped working.
> Please suggest why this issue occurred and what I have to do for resolving
> the issue?
> *Cassandra:- [cqlsh 5.0.1 | Cassandra 3.11.3 | CQL spec 3.4.4 | Native
> protocol v4]*
>
> v\:* \{behavior:url(#default#VML);} o\:* \{behavior:url(#default#VML);} w\:*
> \{behavior:url(#default#VML);} .shape \{behavior:url(#default#VML);}
> 2019-05-29 13:58:47.673 INFO 2003 — [ryBean_Worker-1]
> com.estel.common.MoneyMarkingJob : Job for Leger Management is
> strated at 2019-05-30T00:58:47.671Z time zone
> org.springframework.dao.DataAccessResourceFailureException: Cassandra failure
> during read query at consistency LOCAL_ONE (1 responses were required but
> only 0 replica responded, 1 failed); nested exception is
> com.datastax.driver.core.exceptions.ReadFailureException: Cassandra failure
> during read query at consistency LOCAL_ONE (1 responses were required but
> only 0 replica responded, 1 failed)
> at
> org.springframework.cassandra.support.CassandraExceptionTranslator.translateExceptionIfPossible(CassandraExceptionTranslator.java:163)
> at
> org.springframework.cassandra.core.CqlTemplate.potentiallyConvertRuntimeException(CqlTemplate.java:946)
> at
> org.springframework.cassandra.core.CqlTemplate.translateExceptionIfPossible(CqlTemplate.java:930)
> at
> org.springframework.cassandra.core.CqlTemplate.translateExceptionIfPossible(CqlTemplate.java:912)
> at
> org.springframework.cassandra.core.CqlTemplate.doExecute(CqlTemplate.java:278)
> at
> org.springframework.cassandra.core.CqlTemplate.doExecuteQueryReturnResultSet(CqlTemplate.java:283)
> at
> org.springframework.data.cassandra.core.CassandraTemplate.select(CassandraTemplate.java:594)
> at
> org.springframework.data.cassandra.core.CassandraTemplate.select(CassandraTemplate.java:376)
> at
> org.springframework.data.cassandra.repository.query.CassandraQueryExecution$CollectionExecution.execute(CassandraQueryExecution.java:85)
> at
> org.springframework.data.cassandra.repository.query.CassandraQueryExecution$ResultProcessingExecution.execute(CassandraQueryExecution.java:143)
> at
> org.springframework.data.cassandra.repository.query.AbstractCassandraQuery.execute(AbstractCassandraQuery.java:113)
> at
> org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.doInvoke(RepositoryFactorySupport.java:483)
> at
> org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.invoke(RepositoryFactorySupport.java:461)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.data.projection.DefaultMethodInvokingMethodInterceptor.invoke(DefaultMethodInvokingMethodInterceptor.java:56)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.data.repository.core.support.SurroundingTransactionDetectorMethodInterceptor.invoke(SurroundingTransactionDetectorMethodInterceptor.java:57)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.ja
[jira] [Commented] (CASSANDRA-15145) Error in Cassandra database
[
https://issues.apache.org/jira/browse/CASSANDRA-15145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16851610#comment-16851610
]
maxwellguo commented on CASSANDRA-15145:
1.are you sure all your nodes are up ? you can use nodetools status to show the
status of the cluster; 2. can you show the steps of how to this sutation
happen ? just some stack is useless. thx
> Error in Cassandra database
> ---
>
> Key: CASSANDRA-15145
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15145
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Testing
>Reporter: Pradip Kumar
>Priority: Normal
> Fix For: 3.11.x
>
>
> Dear Team,
> We are facing the problem in the Cassandra database and below the error
> message and after this error application stopped working.
> Please suggest why this issue occurred and what I have to do for resolving
> the issue?
> *Cassandra:- [cqlsh 5.0.1 | Cassandra 3.11.3 | CQL spec 3.4.4 | Native
> protocol v4]*
>
> v\:* \{behavior:url(#default#VML);} o\:* \{behavior:url(#default#VML);} w\:*
> \{behavior:url(#default#VML);} .shape \{behavior:url(#default#VML);}
> 2019-05-29 13:58:47.673 INFO 2003 — [ryBean_Worker-1]
> com.estel.common.MoneyMarkingJob : Job for Leger Management is
> strated at 2019-05-30T00:58:47.671Z time zone
> org.springframework.dao.DataAccessResourceFailureException: Cassandra failure
> during read query at consistency LOCAL_ONE (1 responses were required but
> only 0 replica responded, 1 failed); nested exception is
> com.datastax.driver.core.exceptions.ReadFailureException: Cassandra failure
> during read query at consistency LOCAL_ONE (1 responses were required but
> only 0 replica responded, 1 failed)
> at
> org.springframework.cassandra.support.CassandraExceptionTranslator.translateExceptionIfPossible(CassandraExceptionTranslator.java:163)
> at
> org.springframework.cassandra.core.CqlTemplate.potentiallyConvertRuntimeException(CqlTemplate.java:946)
> at
> org.springframework.cassandra.core.CqlTemplate.translateExceptionIfPossible(CqlTemplate.java:930)
> at
> org.springframework.cassandra.core.CqlTemplate.translateExceptionIfPossible(CqlTemplate.java:912)
> at
> org.springframework.cassandra.core.CqlTemplate.doExecute(CqlTemplate.java:278)
> at
> org.springframework.cassandra.core.CqlTemplate.doExecuteQueryReturnResultSet(CqlTemplate.java:283)
> at
> org.springframework.data.cassandra.core.CassandraTemplate.select(CassandraTemplate.java:594)
> at
> org.springframework.data.cassandra.core.CassandraTemplate.select(CassandraTemplate.java:376)
> at
> org.springframework.data.cassandra.repository.query.CassandraQueryExecution$CollectionExecution.execute(CassandraQueryExecution.java:85)
> at
> org.springframework.data.cassandra.repository.query.CassandraQueryExecution$ResultProcessingExecution.execute(CassandraQueryExecution.java:143)
> at
> org.springframework.data.cassandra.repository.query.AbstractCassandraQuery.execute(AbstractCassandraQuery.java:113)
> at
> org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.doInvoke(RepositoryFactorySupport.java:483)
> at
> org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.invoke(RepositoryFactorySupport.java:461)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.data.projection.DefaultMethodInvokingMethodInterceptor.invoke(DefaultMethodInvokingMethodInterceptor.java:56)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.data.repository.core.support.SurroundingTransactionDetectorMethodInterceptor.invoke(SurroundingTransactionDetectorMethodInterceptor.java:57)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:213)
> at com.sun.proxy.$Proxy66.findTransactionByDatenadStatus(Unknown
> Source)
> at
> com.estel.common.service.impl.TransactionServiceImpl.fingTransactionByDateAndStatus(TransactionServiceImpl.java:47)
> at com.estel.common.MoneyMarkingJob.execute(MoneyMarkingJob.java:101)
> at org.quartz.core.JobRunShell.ru
