[jira] [Commented] (CASSANDRA-15248) Upgrade Guava to latest on master branch
[ https://issues.apache.org/jira/browse/CASSANDRA-15248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741198#comment-17741198 ] Abhijit Sarkar commented on CASSANDRA-15248: [~e.dimitrova] You closed an issue that's 4 years old as duplicate to an identical ticket created merely hours ago. That's not how it works. I see what you did here, this looks good on a manager report because you're able to close a very old ticket without doing anything. > Upgrade Guava to latest on master branch > > > Key: CASSANDRA-15248 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15248 > Project: Cassandra > Issue Type: Task > Components: Build, Dependencies, Packaging >Reporter: Abhijit Sarkar >Priority: Normal > Time Spent: 1h 20m > Remaining Estimate: 0h > > Upgrade Guava to latest on master branch. See > https://issues.apache.org/jira/browse/CASSANDRA-15245. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15267) Client error metrics not updated when no host is available
[ https://issues.apache.org/jira/browse/CASSANDRA-15267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903620#comment-16903620 ] Abhijit Sarkar commented on CASSANDRA-15267: Filed https://datastax-oss.atlassian.net/browse/JAVA-2388 > Client error metrics not updated when no host is available > -- > > Key: CASSANDRA-15267 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15267 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Membership, Observability/Metrics >Reporter: Abhijit Sarkar >Priority: Normal > > None of the client error metrics are updated when > {{NoHostAvailableException}} is thrown. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15267) Client error metrics not updated when no host is available
[ https://issues.apache.org/jira/browse/CASSANDRA-15267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903457#comment-16903457 ] Abhijit Sarkar edited comment on CASSANDRA-15267 at 8/9/19 1:08 AM: [~cnlwsu] the ticket clearly mentions client metrics. More specifically, I'm looking at https://github.com/datastax/java-driver/blob/3.5.x/driver-core/src/main/java/com/datastax/driver/core/Metrics.java#L43 was (Author: sarkara1): [~cnlwsu] the ticket clearly mentions client metrics. More specifically, https://github.com/tfredrich/cassandra-java-driver/blob/master/driver-core/src/main/java/com/datastax/driver/core/Metrics.java#L44 > Client error metrics not updated when no host is available > -- > > Key: CASSANDRA-15267 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15267 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Membership, Observability/Metrics >Reporter: Abhijit Sarkar >Priority: Normal > > None of the client error metrics are updated when > {{NoHostAvailableException}} is thrown. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15267) Client error metrics not updated when no host is available
[ https://issues.apache.org/jira/browse/CASSANDRA-15267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903457#comment-16903457 ] Abhijit Sarkar commented on CASSANDRA-15267: [~cnlwsu] the ticket clearly mentions client metrics. More specifically, https://github.com/tfredrich/cassandra-java-driver/blob/master/driver-core/src/main/java/com/datastax/driver/core/Metrics.java#L44 > Client error metrics not updated when no host is available > -- > > Key: CASSANDRA-15267 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15267 > Project: Cassandra > Issue Type: Bug > Components: Cluster/Membership, Observability/Metrics >Reporter: Abhijit Sarkar >Priority: Normal > > None of the client error metrics are updated when > {{NoHostAvailableException}} is thrown. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15267) Client error metrics not updated when no host is available
Abhijit Sarkar created CASSANDRA-15267: -- Summary: Client error metrics not updated when no host is available Key: CASSANDRA-15267 URL: https://issues.apache.org/jira/browse/CASSANDRA-15267 Project: Cassandra Issue Type: Bug Components: Cluster/Membership, Observability/Metrics Reporter: Abhijit Sarkar None of the client error metrics are updated when {{NoHostAvailableException}} is thrown. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15248) Upgrade Guava to latest on master branch
[ https://issues.apache.org/jira/browse/CASSANDRA-15248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16894333#comment-16894333 ] Abhijit Sarkar commented on CASSANDRA-15248: If you're unable to upgrade a dependency in a major release, you must be doing something wrong. > Upgrade Guava to latest on master branch > > > Key: CASSANDRA-15248 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15248 > Project: Cassandra > Issue Type: Task > Components: Build, Dependencies, Packaging >Reporter: Abhijit Sarkar >Priority: Normal > > Upgrade Guava to latest on master branch. See > https://issues.apache.org/jira/browse/CASSANDRA-15245. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15248) Upgrade Guava to latest on master branch
Abhijit Sarkar created CASSANDRA-15248: -- Summary: Upgrade Guava to latest on master branch Key: CASSANDRA-15248 URL: https://issues.apache.org/jira/browse/CASSANDRA-15248 Project: Cassandra Issue Type: Task Components: Build, Dependencies, Packaging Reporter: Abhijit Sarkar Upgrade Guava to latest on master branch. See https://issues.apache.org/jira/browse/CASSANDRA-15245. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15245) cassandra-all| library uses non-existent Guava classes
[ https://issues.apache.org/jira/browse/CASSANDRA-15245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16892907#comment-16892907 ] Abhijit Sarkar commented on CASSANDRA-15245: [~cnlwsu] Filed task https://issues.apache.org/jira/browse/CASSANDRA-15248 > cassandra-all| library uses non-existent Guava classes > -- > > Key: CASSANDRA-15245 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15245 > Project: Cassandra > Issue Type: Bug > Components: Build, Dependencies, Packaging >Reporter: Abhijit Sarkar >Priority: Normal > > The > [cassandra-all|https://search.maven.org/artifact/org.apache.cassandra/cassandra-all/3.11.4/jar] > library references classes that have been removed from Guava, for example > {{com.google.common.base.CharMatcher.DIGIT}}. This causes runtime errors like > {code} > java.lang.NoClassDefFoundError: Could not initialize class > org.apache.cassandra.io.sstable.format.SSTableFormat$Type > {code} -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15245) cassandra-all| library uses non-existent Guava classes
[ https://issues.apache.org/jira/browse/CASSANDRA-15245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16892539#comment-16892539 ] Abhijit Sarkar commented on CASSANDRA-15245: [~zznate] Guava v23.3-jre in master does remove {{DIGIT}} but as far as compatibility with latest code is concerned, is almost 2 years old. Latest is 28.0-jre. I'm not sure about your comment about upgrading within a stable major release; as long as no API is changed, there's nothing in [SEMVER|https://semver.org] that says transitive dependencies would have to be frozen. > cassandra-all| library uses non-existent Guava classes > -- > > Key: CASSANDRA-15245 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15245 > Project: Cassandra > Issue Type: Bug > Components: Build, Dependencies, Packaging >Reporter: Abhijit Sarkar >Priority: Normal > > The > [cassandra-all|https://search.maven.org/artifact/org.apache.cassandra/cassandra-all/3.11.4/jar] > library references classes that have been removed from Guava, for example > {{com.google.common.base.CharMatcher.DIGIT}}. This causes runtime errors like > {code} > java.lang.NoClassDefFoundError: Could not initialize class > org.apache.cassandra.io.sstable.format.SSTableFormat$Type > {code} -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15245) cassandra-all| library uses non-existent Guava classes
[ https://issues.apache.org/jira/browse/CASSANDRA-15245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16892311#comment-16892311 ] Abhijit Sarkar commented on CASSANDRA-15245: [~zznate] I think you completely missed the point of this ticket. DIGIT is not present in the latest Guava. You are using version 18, which is very old, and this ticket is for you to upgrade to the latest or close. What you’re asking is the rest of the world to stick to a deprecated library just because you’re. Please reopen this ticket as it’s a valid problem. > cassandra-all| library uses non-existent Guava classes > -- > > Key: CASSANDRA-15245 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15245 > Project: Cassandra > Issue Type: Bug > Components: Build, Dependencies, Packaging >Reporter: Abhijit Sarkar >Priority: Normal > > The > [cassandra-all|https://search.maven.org/artifact/org.apache.cassandra/cassandra-all/3.11.4/jar] > library references classes that have been removed from Guava, for example > {{com.google.common.base.CharMatcher.DIGIT}}. This causes runtime errors like > {code} > java.lang.NoClassDefFoundError: Could not initialize class > org.apache.cassandra.io.sstable.format.SSTableFormat$Type > {code} -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15245) cassandra-all| library uses non-existent Guava classes
Abhijit Sarkar created CASSANDRA-15245: -- Summary: cassandra-all| library uses non-existent Guava classes Key: CASSANDRA-15245 URL: https://issues.apache.org/jira/browse/CASSANDRA-15245 Project: Cassandra Issue Type: Bug Components: Build, Dependencies, Packaging Reporter: Abhijit Sarkar The [cassandra-all|https://search.maven.org/artifact/org.apache.cassandra/cassandra-all/3.11.4/jar] library references classes that have been removed from Guava, for example {{com.google.common.base.CharMatcher.DIGIT}}. This causes runtime errors like {code} java.lang.NoClassDefFoundError: Could not initialize class org.apache.cassandra.io.sstable.format.SSTableFormat$Type {code} -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15154) Add console log to indicate the node is ready to accept requests
[ https://issues.apache.org/jira/browse/CASSANDRA-15154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861734#comment-16861734 ] Abhijit Sarkar edited comment on CASSANDRA-15154 at 6/12/19 3:58 AM: - [~mshuler] I'm sure something in the logs can be dug out that'd tell an experienced Cassandra user that the node is ready; however, the point of this ticket is to make that very obvious. Even in the snippet you posted, "Starting listening for CQL clients" isn't necessarily the same as "I'm ready". It can easily be presumed that the node might have more to do after it had started listening for CQL clients. BTW, this ticket is filed as an improvement, not a bug. "Not a bug" doesn't apply; "Won't do because we don't feel like it" might, but isn't one of the goals of good software is to be more intuitive to use? was (Author: socialguy): [~mshuler] I'm sure something in the logs can be dug out that'd tell an experienced Cassandra user that the node is ready; however, the point of this ticket is to make that very obvious. Even in the snippet you posted, "Starting listening for CQL clients" isn't necessarily the same as "I'm ready". It can easily be presumed that the node might have more to do after it had started listening for CQL clients. > Add console log to indicate the node is ready to accept requests > > > Key: CASSANDRA-15154 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15154 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Membership, Local/Startup and Shutdown, > Observability/Logging >Reporter: Abhijit Sarkar >Priority: Normal > > Depending on whether a cluster is initialized the first time, or a node is > restarted, the last message on the console varies. In either case, there's no > indication that the cluster/node is ready to accept requests. > For example, when I create a new Cassandra Docker container locally: > {code} > $ docker run --name cas -p 9042:9042 -p 9091:9091 -e CASSANDRA_DC=dev > cassandra > ... > INFO [OptionalTasks:1] 2019-06-11 23:31:35,527 CassandraRoleManager.java:356 > - Created default superuser role 'cassandra' > {code} > After shutting it down (CTRL + C), and restarting: > {code} > $ docker start cas > ... > INFO [main] 2019-06-11 23:32:57,980 CassandraDaemon.java:556 - Not starting > RPC server as requested. Use JMX (StorageService->startRPCServer()) or > nodetool (enablethrift) to start it > {code} > In either of the above cases, how is a regular user, whose full time job is > not working with Cassandra, expected to know whether the server is ready? We > have a new member in the team who previously was an iOS developer. He left > the server running overnight, assuming the node hadn't finished > initialization; the next morning, the last message was still "Created default > superuser role 'cassandra'". > Please add a simple log statement with basic information like node IPs in the > cluster indicating the node is ready. For example, this is what Spring Boot > does: > {code} > 2019-06-11 16:37:28.295 INFO [my-app,,,] 17392 --- [ main] > o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat started on port(s): 11900 > (http) with context path '' > 2019-06-11 16:37:28.299 INFO [my-app,,,] 17392 --- [ main] > mypackage.MyApp : Started MyApp in 5.279 seconds (JVM running for 5.916) > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15154) Add console log to indicate the node is ready to accept requests
[ https://issues.apache.org/jira/browse/CASSANDRA-15154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16861734#comment-16861734 ] Abhijit Sarkar commented on CASSANDRA-15154: [~mshuler] I'm sure something in the logs can be dug out that'd tell an experienced Cassandra user that the node is ready; however, the point of this ticket is to make that very obvious. Even in the snippet you posted, "Starting listening for CQL clients" isn't necessarily the same as "I'm ready". It can easily be presumed that the node might have more to do after it had started listening for CQL clients. > Add console log to indicate the node is ready to accept requests > > > Key: CASSANDRA-15154 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15154 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Membership, Local/Startup and Shutdown, > Observability/Logging >Reporter: Abhijit Sarkar >Priority: Normal > > Depending on whether a cluster is initialized the first time, or a node is > restarted, the last message on the console varies. In either case, there's no > indication that the cluster/node is ready to accept requests. > For example, when I create a new Cassandra Docker container locally: > {code} > $ docker run --name cas -p 9042:9042 -p 9091:9091 -e CASSANDRA_DC=dev > cassandra > ... > INFO [OptionalTasks:1] 2019-06-11 23:31:35,527 CassandraRoleManager.java:356 > - Created default superuser role 'cassandra' > {code} > After shutting it down (CTRL + C), and restarting: > {code} > $ docker start cas > ... > INFO [main] 2019-06-11 23:32:57,980 CassandraDaemon.java:556 - Not starting > RPC server as requested. Use JMX (StorageService->startRPCServer()) or > nodetool (enablethrift) to start it > {code} > In either of the above cases, how is a regular user, whose full time job is > not working with Cassandra, expected to know whether the server is ready? We > have a new member in the team who previously was an iOS developer. He left > the server running overnight, assuming the node hadn't finished > initialization; the next morning, the last message was still "Created default > superuser role 'cassandra'". > Please add a simple log statement with basic information like node IPs in the > cluster indicating the node is ready. For example, this is what Spring Boot > does: > {code} > 2019-06-11 16:37:28.295 INFO [my-app,,,] 17392 --- [ main] > o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat started on port(s): 11900 > (http) with context path '' > 2019-06-11 16:37:28.299 INFO [my-app,,,] 17392 --- [ main] > mypackage.MyApp : Started MyApp in 5.279 seconds (JVM running for 5.916) > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15154) Add console log to indicate the node is ready to accept requests
[ https://issues.apache.org/jira/browse/CASSANDRA-15154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhijit Sarkar updated CASSANDRA-15154: --- Description: Depending on whether a cluster is initialized the first time, or a node is restarted, the last message on the console varies. In either case, there's no indication that the cluster/node is ready to accept requests. For example, when I create a new Cassandra Docker container locally: {code} $ docker run --name cas -p 9042:9042 -p 9091:9091 -e CASSANDRA_DC=dev cassandra ... INFO [OptionalTasks:1] 2019-06-11 23:31:35,527 CassandraRoleManager.java:356 - Created default superuser role 'cassandra' {code} After shutting it down (CTRL + C), and restarting: {code} $ docker start cas ... INFO [main] 2019-06-11 23:32:57,980 CassandraDaemon.java:556 - Not starting RPC server as requested. Use JMX (StorageService->startRPCServer()) or nodetool (enablethrift) to start it {code} In either of the above cases, how is a regular user, whose full time job is not working with Cassandra, expected to know whether the server is ready? We have a new member in the team who previously was an iOS developer. He left the server running overnight, assuming the node hadn't finished initialization; the next morning, the last message was still "Created default superuser role 'cassandra'". Please add a simple log statement with basic information like node IPs in the cluster indicating the node is ready. For example, this is what Spring Boot does: {code} 2019-06-11 16:37:28.295 INFO [my-app,,,] 17392 --- [ main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat started on port(s): 11900 (http) with context path '' 2019-06-11 16:37:28.299 INFO [my-app,,,] 17392 --- [ main] mypackage.MyApp : Started MyApp in 5.279 seconds (JVM running for 5.916) {code} was: Depending on whether a cluster is initialized the first time, or a node is restarted, the last message on the console varies. In either case, there's no indication that the cluster/node is ready to accept requests. For example, when I create a new Cassandra Docker container locally: {code} $ docker run --name cas -p 9042:9042 -p 9091:9091 -e CASSANDRA_DC=dev cassandra ... INFO [OptionalTasks:1] 2019-06-11 23:31:35,527 CassandraRoleManager.java:356 - Created default superuser role 'cassandra' {code} After shutting it down (CTRL + C), and restarting: {code} $ docker start cas ... INFO [main] 2019-06-11 23:32:57,980 CassandraDaemon.java:556 - Not starting RPC server as requested. Use JMX (StorageService->startRPCServer()) or nodetool (enablethrift) to start it {code} In either of the above cases, how is a regular user, whose full time job is not working with Cassandra, expected to know whether the server is ready? We have a new member in the team who previously was an iOS developer. He left the server running overnight, assuming the node hadn't finished initialization; the next morning, the last message was still "Created default superuser role 'cassandra'". Please add a simple log statement with basic information like node IPs in the cluster indicating the node is ready. For example, this is what Spring Boot does: {code} 2019-06-11 16:37:28.295 INFO [place-mapping,,,] 17392 --- [ main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat started on port(s): 11900 (http) with context path '' 2019-06-11 16:37:28.299 INFO [place-mapping,,,] 17392 --- [ main] c.n.dcs.content.placemapping.PlacesApp : Started PlacesApp in 5.279 seconds (JVM running for 5.916) {code} > Add console log to indicate the node is ready to accept requests > > > Key: CASSANDRA-15154 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15154 > Project: Cassandra > Issue Type: Improvement > Components: Cluster/Membership, Local/Startup and Shutdown, > Observability/Logging >Reporter: Abhijit Sarkar >Priority: Normal > > Depending on whether a cluster is initialized the first time, or a node is > restarted, the last message on the console varies. In either case, there's no > indication that the cluster/node is ready to accept requests. > For example, when I create a new Cassandra Docker container locally: > {code} > $ docker run --name cas -p 9042:9042 -p 9091:9091 -e CASSANDRA_DC=dev > cassandra > ... > INFO [OptionalTasks:1] 2019-06-11 23:31:35,527 CassandraRoleManager.java:356 > - Created default superuser role 'cassandra' > {code} > After shutting it down (CTRL + C), and restarting: > {code} > $ docker start cas > ... > INFO [main] 2019-06-11 23:32:57,980 CassandraDaemon.java:556 - Not starting > RPC server as requested. Use JMX (StorageService->startRPCServer()) or > nodetool (enablethrift) to start it > {code} > In either of the above
[jira] [Created] (CASSANDRA-15154) Add console log to indicate the node is ready to accept requests
Abhijit Sarkar created CASSANDRA-15154: -- Summary: Add console log to indicate the node is ready to accept requests Key: CASSANDRA-15154 URL: https://issues.apache.org/jira/browse/CASSANDRA-15154 Project: Cassandra Issue Type: Improvement Components: Cluster/Membership, Local/Startup and Shutdown, Observability/Logging Reporter: Abhijit Sarkar Depending on whether a cluster is initialized the first time, or a node is restarted, the last message on the console varies. In either case, there's no indication that the cluster/node is ready to accept requests. For example, when I create a new Cassandra Docker container locally: {code} $ docker run --name cas -p 9042:9042 -p 9091:9091 -e CASSANDRA_DC=dev cassandra ... INFO [OptionalTasks:1] 2019-06-11 23:31:35,527 CassandraRoleManager.java:356 - Created default superuser role 'cassandra' {code} After shutting it down (CTRL + C), and restarting: {code} $ docker start cas ... INFO [main] 2019-06-11 23:32:57,980 CassandraDaemon.java:556 - Not starting RPC server as requested. Use JMX (StorageService->startRPCServer()) or nodetool (enablethrift) to start it {code} In either of the above cases, how is a regular user, whose full time job is not working with Cassandra, expected to know whether the server is ready? We have a new member in the team who previously was an iOS developer. He left the server running overnight, assuming the node hadn't finished initialization; the next morning, the last message was still "Created default superuser role 'cassandra'". Please add a simple log statement with basic information like node IPs in the cluster indicating the node is ready. For example, this is what Spring Boot does: {code} 2019-06-11 16:37:28.295 INFO [place-mapping,,,] 17392 --- [ main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat started on port(s): 11900 (http) with context path '' 2019-06-11 16:37:28.299 INFO [place-mapping,,,] 17392 --- [ main] c.n.dcs.content.placemapping.PlacesApp : Started PlacesApp in 5.279 seconds (JVM running for 5.916) {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org