[jira] [Updated] (CASSANDRA-10789) Allow DBAs to kill individual client sessions without bouncing JVM
[ https://issues.apache.org/jira/browse/CASSANDRA-10789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damien Stevenson updated CASSANDRA-10789: - Attachment: 10789-trunk-dtest.txt > Allow DBAs to kill individual client sessions without bouncing JVM > -- > > Key: CASSANDRA-10789 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10789 > Project: Cassandra > Issue Type: Improvement > Components: Coordination >Reporter: Wei Deng >Assignee: Damien Stevenson >Priority: Major > Fix For: 4.x > > Attachments: 10789-trunk-dtest.txt, 10789-trunk.txt > > > In production, there could be hundreds of clients connected to a Cassandra > cluster (maybe even from different applications), and if they use DataStax > Java Driver, each client will establish at least one TCP connection to a > Cassandra server (see > https://datastax.github.io/java-driver/2.1.9/features/pooling/). This is all > normal and at any given time, you can indeed see hundreds of ESTABLISHED > connections to port 9042 on a C* server (from netstat -na). The problem is > that sometimes when a C* cluster is under heavy load, when the DBA identifies > some client session that sends abusive amount of traffic to the C* server and > would like to stop it, they would like a lightweight approach rather than > shutting down the JVM or rolling restart the whole cluster to kill all > hundreds of connections in order to kill a single client session. If the DBA > had root privilege, they would have been able to do something at the OS > network level to achieve the same goal but oftentimes enterprise DBA role is > separate from OS sysadmin role, so the DBAs usually don't have that privilege. > This is especially helpful when you have a multi-tenant C* cluster and you > want to have the impact for handling such client to be minimal to the other > applications. This feature (killing individual session) seems to be a common > feature in other databases (regardless of whether the client has some > reconnect logic or not). It could be implemented as a JMX MBean method and > exposed through nodetool to the DBAs. -- 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-10789) Allow DBAs to kill individual client sessions without bouncing JVM
[ https://issues.apache.org/jira/browse/CASSANDRA-10789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damien Stevenson updated CASSANDRA-10789: - Attachment: 10789-trunk.txt > Allow DBAs to kill individual client sessions without bouncing JVM > -- > > Key: CASSANDRA-10789 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10789 > Project: Cassandra > Issue Type: Improvement > Components: Coordination >Reporter: Wei Deng >Assignee: Damien Stevenson >Priority: Major > Fix For: 4.x > > Attachments: 10789-trunk.txt > > > In production, there could be hundreds of clients connected to a Cassandra > cluster (maybe even from different applications), and if they use DataStax > Java Driver, each client will establish at least one TCP connection to a > Cassandra server (see > https://datastax.github.io/java-driver/2.1.9/features/pooling/). This is all > normal and at any given time, you can indeed see hundreds of ESTABLISHED > connections to port 9042 on a C* server (from netstat -na). The problem is > that sometimes when a C* cluster is under heavy load, when the DBA identifies > some client session that sends abusive amount of traffic to the C* server and > would like to stop it, they would like a lightweight approach rather than > shutting down the JVM or rolling restart the whole cluster to kill all > hundreds of connections in order to kill a single client session. If the DBA > had root privilege, they would have been able to do something at the OS > network level to achieve the same goal but oftentimes enterprise DBA role is > separate from OS sysadmin role, so the DBAs usually don't have that privilege. > This is especially helpful when you have a multi-tenant C* cluster and you > want to have the impact for handling such client to be minimal to the other > applications. This feature (killing individual session) seems to be a common > feature in other databases (regardless of whether the client has some > reconnect logic or not). It could be implemented as a JMX MBean method and > exposed through nodetool to the DBAs. -- 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-14437) SSTableLoader does not work when "internode_encryption : all" is set
[
https://issues.apache.org/jira/browse/CASSANDRA-14437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466914#comment-16466914
]
Kurt Greaves commented on CASSANDRA-14437:
--
This seems like you don't have internode encryption enabled on your nodes. You
need to have (more or less) the same internode_encryption settings for
sstableloader and your nodes. {{none}} shouldn't work with {{all}} or vice
versa.
> SSTableLoader does not work when "internode_encryption : all" is set
>
>
> Key: CASSANDRA-14437
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14437
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Paul Cheon
>Priority: Major
> Fix For: 3.11.2
>
>
> I am trying to use sstableloader to restore snapshot.
> If "internode_encryption : all" is set, then it does not work and complain
> with below error messages. I initiated sstableloader from 10.1.10.203
> (yvr-paul-cas003), so 10.1.10.203 worked fine, but the the other two nodes
> (10.1.10.201 & 10.1.10.202 failed)
> {noformat}
> pcheon@yvr-paul-cas003:~/t$ sstableloader -v -d 10.1.10.203 office_audit/log/
> -f /etc/cassandra/cassandra.yaml -u pcheon -pw `cat .secret`
> WARN 17:23:45,166 Small commitlog volume detected at
> /var/lib/cassandra/commitlog; setting commitlog_total_space_in_mb to 2316.
> You can override this in cassandra.yaml
> WARN 17:23:45,170 Small cdc volume detected at /var/lib/cassandra/cdc_raw;
> setting cdc_total_space_in_mb to 1158. You can override this in
> cassandra.yaml
> WARN 17:23:45,285 Only 5.318GiB free across all data volumes. Consider
> adding more capacity to your cluster or removing obsolete snapshots
> Established connection to initial hosts
> Opening sstables and calculating sections to stream
> Streaming relevant part of
> /home/pcheon/t/office_audit/log/mc-1083-big-Data.db
> /home/pcheon/t/office_audit/log/mc-1100-big-Data.db
> /home/pcheon/t/office_audit/log/mc-1101-big-Data.db
> /home/pcheon/t/office_audit/log/mc-257-big-Data.db
> /home/pcheon/t/office_audit/log/mc-984-big-Data.db to [/10.1.10.201,
> /10.1.10.203, /10.1.10.202]
> ERROR 17:23:49,460 [Stream #938baee0-4e2d-11e8-9be0-ebc69ba4b87f] Streaming
> error occurred on session with peer 10.1.10.201
> java.net.SocketException: Invalid argument or cannot assign requested address
> at java.net.PlainSocketImpl.socketConnect(Native Method) ~[na:1.8.0_112]
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> ~[na:1.8.0_112]
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> ~[na:1.8.0_112]
> at
> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> ~[na:1.8.0_112]
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> ~[na:1.8.0_112]
> at java.net.Socket.connect(Socket.java:589) ~[na:1.8.0_112]
> at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:668)
> ~[na:1.8.0_112]
> at sun.security.ssl.SSLSocketImpl.(SSLSocketImpl.java:495)
> ~[na:1.8.0_112]
> at
> sun.security.ssl.SSLSocketFactoryImpl.createSocket(SSLSocketFactoryImpl.java:169)
> ~[na:1.8.0_112]
> at
> org.apache.cassandra.security.SSLFactory.getSocket(SSLFactory.java:81)
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at
> org.apache.cassandra.tools.BulkLoadConnectionFactory.createConnection(BulkLoadConnectionFactory.java:56)
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at
> org.apache.cassandra.streaming.StreamSession.createConnection(StreamSession.java:282)
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at
> org.apache.cassandra.streaming.ConnectionHandler.initiate(ConnectionHandler.java:86)
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at
> org.apache.cassandra.streaming.StreamSession.start(StreamSession.java:269)
> ~[apache-cassandra-3.11.2.jar:3.11.2]
> at
> org.apache.cassandra.streaming.StreamCoordinator$StreamSessionConnector.run(StreamCoordinator.java:263)
> [apache-cassandra-3.11.2.jar:3.11.2]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_112]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_112]
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
> [apache-cassandra-3.11.2.jar:3.11.2]
> at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_112]
> ERROR 17:23:49,458 [Stream #938baee0-4e2d-11e8-9be0-ebc69ba4b87f] Streaming
> error occurred on session with peer 10.1.10.202
> java.net.SocketException: Invalid argument or cannot assign requested address
> at java.net.PlainSocketImpl.socketConnect(Native
[jira] [Commented] (CASSANDRA-12151) Audit logging for database activity
[ https://issues.apache.org/jira/browse/CASSANDRA-12151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466880#comment-16466880 ] Jason Brown commented on CASSANDRA-12151: - bq. Would it not make sense to maintain audit whitelist permissions next to all other permissions in Cassandra? This is an intersting idea. However, I'm reticent to introduce CQL grammar changes this late into this ticket. As a followup, I think this could be worth exploring. bq. would it make sense to use the existing Permission type (SELECT, MODIFY, CREATE...) and IResource (Data, Role, Function...)? While there's some conceptual overlap, I don't think it's a good idea to try to force the concepts of 'audit logging' and 'auth' onto one another here. [~eperott]'s other comments I agree with. > Audit logging for database activity > --- > > Key: CASSANDRA-12151 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12151 > Project: Cassandra > Issue Type: New Feature >Reporter: stefan setyadi >Assignee: Vinay Chella >Priority: Major > Fix For: 4.x > > Attachments: 12151.txt, CASSANDRA_12151-benchmark.html, > DesignProposal_AuditingFeature_ApacheCassandra_v1.docx > > > we would like a way to enable cassandra to log database activity being done > on our server. > It should show username, remote address, timestamp, action type, keyspace, > column family, and the query statement. > it should also be able to log connection attempt and changes to the > user/roles. > I was thinking of making a new keyspace and insert an entry for every > activity that occurs. > Then It would be possible to query for specific activity or a query targeting > a specific keyspace and column family. -- 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-12271) NonSystemKeyspaces jmx attribute needs to return jre list
[
https://issues.apache.org/jira/browse/CASSANDRA-12271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466859#comment-16466859
]
mck commented on CASSANDRA-12271:
-
[~eribeiro] and [~cnlwsu], can you check that the patch is applied correctly
and the CHANGES.txt is accurate?
With that and green builds I'll commit it.
> NonSystemKeyspaces jmx attribute needs to return jre list
> -
>
> Key: CASSANDRA-12271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12271
> Project: Cassandra
> Issue Type: Bug
>Reporter: Chris Lohfink
>Assignee: Edward Ribeiro
>Priority: Major
> Labels: lhf
> Fix For: 4.0, 3.11.3
>
> Attachments: CASSANDRA-12271.patch, screenshot-1.png, screenshot-2.png
>
>
> If you dont have right guava in classpath you cant query the
> NonSystemKeyspaces attribute. i.e. jconsole. can reproduce using Swiss java
> knife:
> {code}
> # java -jar sjk.jar mx -s localhost:7199 -mg -b
> "org.apache.cassandra.db:type=StorageService" -f NonSystemKeyspaces
> org.apache.cassandra.db:type=StorageService
> java.rmi.UnmarshalException: error unmarshalling return; nested exception is:
> java.lang.ClassNotFoundException:
> com.google.common.collect.ImmutableList$SerializedForm (no security manager:
> RMI class loader disabled)
> {code}
> If return a ArrayList or LinkedList or anything in JRE this will be fixed
--
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-12271) NonSystemKeyspaces jmx attribute needs to return jre list
[
https://issues.apache.org/jira/browse/CASSANDRA-12271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
mck updated CASSANDRA-12271:
Fix Version/s: (was: 3.11.x)
3.11.3
4.0
> NonSystemKeyspaces jmx attribute needs to return jre list
> -
>
> Key: CASSANDRA-12271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12271
> Project: Cassandra
> Issue Type: Bug
>Reporter: Chris Lohfink
>Assignee: Edward Ribeiro
>Priority: Major
> Labels: lhf
> Fix For: 4.0, 3.11.3
>
> Attachments: CASSANDRA-12271.patch, screenshot-1.png, screenshot-2.png
>
>
> If you dont have right guava in classpath you cant query the
> NonSystemKeyspaces attribute. i.e. jconsole. can reproduce using Swiss java
> knife:
> {code}
> # java -jar sjk.jar mx -s localhost:7199 -mg -b
> "org.apache.cassandra.db:type=StorageService" -f NonSystemKeyspaces
> org.apache.cassandra.db:type=StorageService
> java.rmi.UnmarshalException: error unmarshalling return; nested exception is:
> java.lang.ClassNotFoundException:
> com.google.common.collect.ImmutableList$SerializedForm (no security manager:
> RMI class loader disabled)
> {code}
> If return a ArrayList or LinkedList or anything in JRE this will be fixed
--
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-12271) NonSystemKeyspaces jmx attribute needs to return jre list
[
https://issues.apache.org/jira/browse/CASSANDRA-12271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466855#comment-16466855
]
mck commented on CASSANDRA-12271:
-
|| Branch || uTest || aTest || dTest ||
|[cassandra-3.11_12271|https://github.com/thelastpickle/cassandra/tree/mck/cassandra-3.11_12271]|[!https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Fcassandra-3.11_12271.svg?style=svg!|https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Fcassandra-3.11_12271]|
https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/17/
|
https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/546/
|
|[trunk_12244|https://github.com/thelastpickle/cassandra/tree/mck/trunk_12271]|[!https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Ftrunk_12271.svg?style=svg!|https://circleci.com/gh/thelastpickle/cassandra/tree/mck%2Ftrunk_12271]|
https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-testall/18/
|
https://builds.apache.org/view/A-D/view/Cassandra/job/Cassandra-devbranch-dtest/547/
|
> NonSystemKeyspaces jmx attribute needs to return jre list
> -
>
> Key: CASSANDRA-12271
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12271
> Project: Cassandra
> Issue Type: Bug
>Reporter: Chris Lohfink
>Assignee: Edward Ribeiro
>Priority: Major
> Labels: lhf
> Fix For: 3.11.x
>
> Attachments: CASSANDRA-12271.patch, screenshot-1.png, screenshot-2.png
>
>
> If you dont have right guava in classpath you cant query the
> NonSystemKeyspaces attribute. i.e. jconsole. can reproduce using Swiss java
> knife:
> {code}
> # java -jar sjk.jar mx -s localhost:7199 -mg -b
> "org.apache.cassandra.db:type=StorageService" -f NonSystemKeyspaces
> org.apache.cassandra.db:type=StorageService
> java.rmi.UnmarshalException: error unmarshalling return; nested exception is:
> java.lang.ClassNotFoundException:
> com.google.common.collect.ImmutableList$SerializedForm (no security manager:
> RMI class loader disabled)
> {code}
> If return a ArrayList or LinkedList or anything in JRE this will be fixed
--
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] [Assigned] (CASSANDRA-14145) Detecting data resurrection during read
[ https://issues.apache.org/jira/browse/CASSANDRA-14145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] C. Scott Andreas reassigned CASSANDRA-14145: Assignee: Sam Tunnicliffe > Detecting data resurrection during read > > > Key: CASSANDRA-14145 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14145 > Project: Cassandra > Issue Type: Improvement >Reporter: sankalp kohli >Assignee: Sam Tunnicliffe >Priority: Minor > > We have seen several bugs in which deleted data gets resurrected. We should > try to see if we can detect this on the read path and possibly fix it. Here > are a few examples which brought back data > A replica lost an sstable on startup which caused one replica to lose the > tombstone and not the data. This tombstone was past gc grace which means this > could resurrect data. We can detect such invalid states by looking at other > replicas. > If we are running incremental repair, Cassandra will keep repaired and > non-repaired data separate. Every-time incremental repair will run, it will > move the data from non-repaired to repaired. Repaired data across all > replicas should be 100% consistent. > Here is an example of how we can detect and mitigate the issue in most cases. > Say we have 3 machines, A,B and C. All these machines will have data split > b/w repaired and non-repaired. > 1. Machine A due to some bug bring backs data D. This data D is in repaired > dataset. All other replicas will have data D and tombstone T > 2. Read for data D comes from application which involve replicas A and B. The > data being read involves data which is in repaired state. A will respond > back to co-ordinator with data D and B will send nothing as tombstone is past > gc grace. This will cause digest mismatch. > 3. This patch will only kick in when there is a digest mismatch. Co-ordinator > will ask both replicas to send back all data like we do today but with this > patch, replicas will respond back what data it is returning is coming from > repaired vs non-repaired. If data coming from repaired does not match, we > know there is a something wrong!! At this time, co-ordinator cannot determine > if replica A has resurrected some data or replica B has lost some data. We > can still log error in the logs saying we hit an invalid state. > 4. Besides the log, we can take this further and even correct the response to > the query. After logging an invalid state, we can ask replica A and B (and > also C if alive) to send back all data for this including gcable tombstones. > If any machine returns a tombstone which is after this data, we know we > cannot return this data. This way we can avoid returning data which has been > deleted. > Some Challenges with this > 1. When data will be moved from non-repaired to repaired, there could be a > race here. We can look at which incremental repairs have promoted things on > which replica to avoid false positives. > 2. If the third replica is down and live replica does not have any tombstone, > we wont be able to break the tie in deciding whether data was actually > deleted or resurrected. > 3. If the read is for latest data only, we wont be able to detect it as the > read will be served from non-repaired data. > 4. If the replica where we lose a tombstone is the last replica to compact > the tombstone, we wont be able to decide if data is coming back or rest of > the replicas has lost that data. But we will still detect something is wrong. > 5. We wont affect 99.9% of the read queries as we only do extra work during > digest mismatch. > 6. CL.ONE reads will not be able to detect this. -- 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-12151) Audit logging for database activity
[ https://issues.apache.org/jira/browse/CASSANDRA-12151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466440#comment-16466440 ] Per Otterström commented on CASSANDRA-12151: I've been following this ticket with some interest. Spent some time to review the patch, didn't try things out yet. When using logback as backend, would it make sense to mark audit records with a specific appender name such as "AUDIT" rather than "FileAuditLoggerAppender". That way we can easily tell regular log messages from audit log messages. Having audit include/exclude filters in the yaml file seem a bit impractical when you want to update it. I believe there are quite a few similarities with the permissions-on-resources model in Cassandra. Would it not make sense to maintain audit whitelist permissions next to all other permissions in Cassandra? Example "GRANT NOAUDIT ON KEYSPACE myks TO myuser". I've been experimenting with a similar approach (storing white-lists in the role option field) in our internal audit log plugin and it looks promising. On a similar topic, rather than creating the AuditLogEntryCategory type, the mapping in AuditLogEntryType and the kespace/scope of (I)AuditLogContext, would it make sense to use the existing Permission type (SELECT, MODIFY, CREATE...) and IResource (Data, Role, Function...). We could create a new resource type to represent Connections (like connection/native, connection/thrift, connection/jmx) which could be used for managing white-lists for authentication. Why always mute audit logs for the system keyspaces? IMO, we should make less assumptions on the use cases and let this be configurable like all other keyspaces. The AuditLogManager contain a few redundant null checks and isAuditintEnabled()-checks. The BinLogAuditLogger declare "LoggerFactory.getLogger(FullQueryLogger.class)" > Audit logging for database activity > --- > > Key: CASSANDRA-12151 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12151 > Project: Cassandra > Issue Type: New Feature >Reporter: stefan setyadi >Assignee: Vinay Chella >Priority: Major > Fix For: 4.x > > Attachments: 12151.txt, CASSANDRA_12151-benchmark.html, > DesignProposal_AuditingFeature_ApacheCassandra_v1.docx > > > we would like a way to enable cassandra to log database activity being done > on our server. > It should show username, remote address, timestamp, action type, keyspace, > column family, and the query statement. > it should also be able to log connection attempt and changes to the > user/roles. > I was thinking of making a new keyspace and insert an entry for every > activity that occurs. > Then It would be possible to query for specific activity or a query targeting > a specific keyspace and column family. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14438) Issue with FailureDetector.java:456 in the debug.log
[ https://issues.apache.org/jira/browse/CASSANDRA-14438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466160#comment-16466160 ] Jeff Jirsa edited comment on CASSANDRA-14438 at 5/7/18 4:52 PM: There's no parameter that will get rid of the log. It's a [log message on two different branches of a conditional|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/gms/FailureDetector.java#L449-L457] - no matter what you do, you'll get one of them. Nothing's wrong, it's just giving information. It was noted in 3.0.15 or so that this is noisy, so it was [changed to trace|https://github.com/apache/cassandra/commit/9ac01baef5c8f689e96307da9b29314bc0672462] was (Author: jjirsa): There's no parameter that will get rid of the log. It's a [log message on two different branches of a conditional|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/gms/FailureDetector.java#L449-L457] - no matter what you do, you'll get one of them. Nothing's wrong, it's just giving information. > Issue with FailureDetector.java:456 in the debug.log > > > Key: CASSANDRA-14438 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14438 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging >Reporter: Rama Krishna Akkenapally >Priority: Major > Fix For: 3.0.x > > > Team, > > we are doing POC on open source cassandra for one of our critical application > . we do see the below error hitting every second in debug.log , could you > please help us to over come the error message . > Component : Apache cassandra > Version : Cassandra 3.0.14 > > please let us if you need any additional information . > > DEBUG [GossipStage:1] 2018-05-07 11:37:37,645 FailureDetector.java:456 - > Ignoring interval time of 3121506694 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:37,646 FailureDetector.java:456 - > Ignoring interval time of 3043323658 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:37,646 FailureDetector.java:456 - > Ignoring interval time of 2793436516 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:37,853 FailureDetector.java:456 - > Ignoring interval time of 3000475949 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:37,853 FailureDetector.java:456 - > Ignoring interval time of 3000661616 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:37,853 FailureDetector.java:456 - > Ignoring interval time of 2000404942 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:38,372 FailureDetector.java:456 - > Ignoring interval time of 2006601883 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:38,372 FailureDetector.java:456 - > Ignoring interval time of 3520254134 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:38,373 FailureDetector.java:456 - > Ignoring interval time of 2006610253 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:38,373 FailureDetector.java:456 - > Ignoring interval time of 2006711620 for /hostname > > Thanks, > RK. -- 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-14438) Issue with FailureDetector.java:456 in the debug.log
[ https://issues.apache.org/jira/browse/CASSANDRA-14438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466160#comment-16466160 ] Jeff Jirsa commented on CASSANDRA-14438: There's no parameter that will get rid of the log. It's a [log message on two different branches of a conditional|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/gms/FailureDetector.java#L449-L457] - no matter what you do, you'll get one of them. Nothing's wrong, it's just giving information. > Issue with FailureDetector.java:456 in the debug.log > > > Key: CASSANDRA-14438 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14438 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging >Reporter: Rama Krishna Akkenapally >Priority: Major > Fix For: 3.0.x > > > Team, > > we are doing POC on open source cassandra for one of our critical application > . we do see the below error hitting every second in debug.log , could you > please help us to over come the error message . > Component : Apache cassandra > Version : Cassandra 3.0.14 > > please let us if you need any additional information . > > DEBUG [GossipStage:1] 2018-05-07 11:37:37,645 FailureDetector.java:456 - > Ignoring interval time of 3121506694 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:37,646 FailureDetector.java:456 - > Ignoring interval time of 3043323658 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:37,646 FailureDetector.java:456 - > Ignoring interval time of 2793436516 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:37,853 FailureDetector.java:456 - > Ignoring interval time of 3000475949 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:37,853 FailureDetector.java:456 - > Ignoring interval time of 3000661616 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:37,853 FailureDetector.java:456 - > Ignoring interval time of 2000404942 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:38,372 FailureDetector.java:456 - > Ignoring interval time of 2006601883 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:38,372 FailureDetector.java:456 - > Ignoring interval time of 3520254134 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:38,373 FailureDetector.java:456 - > Ignoring interval time of 2006610253 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:38,373 FailureDetector.java:456 - > Ignoring interval time of 2006711620 for /hostname > > Thanks, > RK. -- 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-14438) Issue with FailureDetector.java:456 in the debug.log
[ https://issues.apache.org/jira/browse/CASSANDRA-14438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16466118#comment-16466118 ] Rama Krishna Akkenapally commented on CASSANDRA-14438: -- Thanks Jeff, really appreciate your help on this. Yes , i want to debug this error message , is this related to some parameter setting in the yaml or logback.xml ? i want to get rid of this message from debug.log. Thanks, RK. > Issue with FailureDetector.java:456 in the debug.log > > > Key: CASSANDRA-14438 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14438 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging >Reporter: Rama Krishna Akkenapally >Priority: Major > Fix For: 3.0.x > > > Team, > > we are doing POC on open source cassandra for one of our critical application > . we do see the below error hitting every second in debug.log , could you > please help us to over come the error message . > Component : Apache cassandra > Version : Cassandra 3.0.14 > > please let us if you need any additional information . > > DEBUG [GossipStage:1] 2018-05-07 11:37:37,645 FailureDetector.java:456 - > Ignoring interval time of 3121506694 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:37,646 FailureDetector.java:456 - > Ignoring interval time of 3043323658 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:37,646 FailureDetector.java:456 - > Ignoring interval time of 2793436516 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:37,853 FailureDetector.java:456 - > Ignoring interval time of 3000475949 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:37,853 FailureDetector.java:456 - > Ignoring interval time of 3000661616 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:37,853 FailureDetector.java:456 - > Ignoring interval time of 2000404942 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:38,372 FailureDetector.java:456 - > Ignoring interval time of 2006601883 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:38,372 FailureDetector.java:456 - > Ignoring interval time of 3520254134 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:38,373 FailureDetector.java:456 - > Ignoring interval time of 2006610253 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:38,373 FailureDetector.java:456 - > Ignoring interval time of 2006711620 for /hostname > > Thanks, > RK. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Resolved] (CASSANDRA-14438) Issue with FailureDetector.java:456 in the debug.log
[ https://issues.apache.org/jira/browse/CASSANDRA-14438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Jirsa resolved CASSANDRA-14438. Resolution: Not A Bug This isn't a bug, and there's nothing wrong here to investigate. The debug log has a lot of information in it meant for debugging - if you're not actively debugging an issue related to the failure detector, please ignore it. > Issue with FailureDetector.java:456 in the debug.log > > > Key: CASSANDRA-14438 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14438 > Project: Cassandra > Issue Type: Bug > Components: Streaming and Messaging >Reporter: Rama Krishna Akkenapally >Priority: Major > Fix For: 3.0.x > > > Team, > > we are doing POC on open source cassandra for one of our critical application > . we do see the below error hitting every second in debug.log , could you > please help us to over come the error message . > Component : Apache cassandra > Version : Cassandra 3.0.14 > > please let us if you need any additional information . > > DEBUG [GossipStage:1] 2018-05-07 11:37:37,645 FailureDetector.java:456 - > Ignoring interval time of 3121506694 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:37,646 FailureDetector.java:456 - > Ignoring interval time of 3043323658 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:37,646 FailureDetector.java:456 - > Ignoring interval time of 2793436516 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:37,853 FailureDetector.java:456 - > Ignoring interval time of 3000475949 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:37,853 FailureDetector.java:456 - > Ignoring interval time of 3000661616 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:37,853 FailureDetector.java:456 - > Ignoring interval time of 2000404942 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:38,372 FailureDetector.java:456 - > Ignoring interval time of 2006601883 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:38,372 FailureDetector.java:456 - > Ignoring interval time of 3520254134 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:38,373 FailureDetector.java:456 - > Ignoring interval time of 2006610253 for /hostname > DEBUG [GossipStage:1] 2018-05-07 11:37:38,373 FailureDetector.java:456 - > Ignoring interval time of 2006711620 for /hostname > > Thanks, > RK. -- 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-14438) Issue with FailureDetector.java:456 in the debug.log
Rama Krishna Akkenapally created CASSANDRA-14438: Summary: Issue with FailureDetector.java:456 in the debug.log Key: CASSANDRA-14438 URL: https://issues.apache.org/jira/browse/CASSANDRA-14438 Project: Cassandra Issue Type: Bug Components: Streaming and Messaging Reporter: Rama Krishna Akkenapally Fix For: 3.0.x Team, we are doing POC on open source cassandra for one of our critical application . we do see the below error hitting every second in debug.log , could you please help us to over come the error message . Component : Apache cassandra Version : Cassandra 3.0.14 please let us if you need any additional information . DEBUG [GossipStage:1] 2018-05-07 11:37:37,645 FailureDetector.java:456 - Ignoring interval time of 3121506694 for /hostname DEBUG [GossipStage:1] 2018-05-07 11:37:37,646 FailureDetector.java:456 - Ignoring interval time of 3043323658 for /hostname DEBUG [GossipStage:1] 2018-05-07 11:37:37,646 FailureDetector.java:456 - Ignoring interval time of 2793436516 for /hostname DEBUG [GossipStage:1] 2018-05-07 11:37:37,853 FailureDetector.java:456 - Ignoring interval time of 3000475949 for /hostname DEBUG [GossipStage:1] 2018-05-07 11:37:37,853 FailureDetector.java:456 - Ignoring interval time of 3000661616 for /hostname DEBUG [GossipStage:1] 2018-05-07 11:37:37,853 FailureDetector.java:456 - Ignoring interval time of 2000404942 for /hostname DEBUG [GossipStage:1] 2018-05-07 11:37:38,372 FailureDetector.java:456 - Ignoring interval time of 2006601883 for /hostname DEBUG [GossipStage:1] 2018-05-07 11:37:38,372 FailureDetector.java:456 - Ignoring interval time of 3520254134 for /hostname DEBUG [GossipStage:1] 2018-05-07 11:37:38,373 FailureDetector.java:456 - Ignoring interval time of 2006610253 for /hostname DEBUG [GossipStage:1] 2018-05-07 11:37:38,373 FailureDetector.java:456 - Ignoring interval time of 2006711620 for /hostname Thanks, RK. -- 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-14304) DELETE after INSERT IF NOT EXISTS does not work
[
https://issues.apache.org/jira/browse/CASSANDRA-14304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16465912#comment-16465912
]
Jacques-Henri Berthemet commented on CASSANDRA-14304:
-
It looks like setting defaultTimestamp at statement level didn't work however
using
ServerSideTimestampGenerator.INSTANCE when building the session worked.
I think a warning should be written in docs around the LWT in CQL doc:
[http://cassandra.apache.org/doc/latest/cql/dml.html?#insert|http://cassandra.apache.org/doc/latest/cql/dml.html#insert]
Or it would be even better to have a dedicated chapter about LWT.
> DELETE after INSERT IF NOT EXISTS does not work
> ---
>
> Key: CASSANDRA-14304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14304
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Julien
>Assignee: Vinay Chella
>Priority: Major
> Attachments: debug.log, system.log
>
>
> DELETE a row immediately after INSERT IF NOT EXISTS does not work.
> Can be reproduced with this CQL script:
> {code:java}
> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> CREATE TABLE ks.ta ( id text PRIMARY KEY, col text );
> INSERT INTO ks.ta (id, col) VALUES ('myId', 'myCol') IF NOT EXISTS;
> DELETE FROM ks.ta WHERE id = 'myId';
> SELECT * FROM ks.ta WHERE id='myId';
> {code}
> {code:java}
> [cqlsh 5.0.1 | Cassandra 3.11.2 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> WARNING: pyreadline dependency missing. Install to enable tab completion.
> cqlsh> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> cqlsh> CREATE TABLE ks.ta ( id text PRIMARY KEY, col text );
> cqlsh> INSERT INTO ks.ta (id, col) VALUES ('myId', 'myCol') IF NOT EXISTS;
> [applied]
> ---
> True
> cqlsh> DELETE FROM ks.ta WHERE id = 'myId';
> cqlsh> SELECT * FROM ks.ta WHERE id='myId';
> id | col
> --+---
> myId | myCol
> {code}
> * Only happens if the client is on a different host (works as expected on
> the same host)
> * Works as expected without IF NOT EXISTS
> * A ~500 ms delay between INSERT and DELETE fixes the issue.
> Logs attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12151) Audit logging for database activity
[
https://issues.apache.org/jira/browse/CASSANDRA-12151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16465523#comment-16465523
]
Vinay Chella commented on CASSANDRA-12151:
--
Hi [~jasobrown],
Thanks for the changes. Yes, extracting `BinLogAuditLogger` is a cleaner way to
do this.
Updated changeset with minor fixes to pass tests, moved the {{category}} in
AuditLogEntryType to enum.
Filtered unintended messages to FQL.
{quote}Why did you remove the reloadFilters functionality?
{quote}
Updated documentation regarding "ReloadFilters" functionality.
Yes, circleci utests are green, trying to get paid account to run dtests.
\\
||*Branch*||*PR*||*uTest*||
|[trunk_CASSANDRA-12151|https://github.com/vinaykumarchella/cassandra/tree/trunk_CASSANDRA-12151]|[PR
for
trunk|https://github.com/vinaykumarchella/cassandra/pull/2/commits]|[!https://circleci.com/gh/vinaykumarchella/cassandra/tree/trunk_CASSANDRA-12151.svg?style=svg!|https://circleci.com/gh/vinaykumarchella/cassandra/tree/trunk_CASSANDRA-12151]|
> Audit logging for database activity
> ---
>
> Key: CASSANDRA-12151
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12151
> Project: Cassandra
> Issue Type: New Feature
>Reporter: stefan setyadi
>Assignee: Vinay Chella
>Priority: Major
> Fix For: 4.x
>
> Attachments: 12151.txt, CASSANDRA_12151-benchmark.html,
> DesignProposal_AuditingFeature_ApacheCassandra_v1.docx
>
>
> we would like a way to enable cassandra to log database activity being done
> on our server.
> It should show username, remote address, timestamp, action type, keyspace,
> column family, and the query statement.
> it should also be able to log connection attempt and changes to the
> user/roles.
> I was thinking of making a new keyspace and insert an entry for every
> activity that occurs.
> Then It would be possible to query for specific activity or a query targeting
> a specific keyspace and column family.
--
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
