[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
