[
https://issues.apache.org/jira/browse/CASSANDRA-19902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17906023#comment-17906023
]
Stefan Miklosovic edited comment on CASSANDRA-19902 at 12/16/24 1:08 PM:
-------------------------------------------------------------------------
Looks good on paper, I am just trying to understand what happens when
StorageService is indeed available during bootstrap and e.g. various nodetool
commands are executed, proceeding just happily because StorageService is there,
but StorageService might return meaningless / not accurate results back to
nodetool which will try to parse what StorageService returned and for some
weird reason it will not be able to.
Now it returns something like this:
{code:java}
$ ./bin/nodetool status
error: No nodes present in the cluster. Has this node finished starting up?
-- StackTrace --
java.lang.RuntimeException: No nodes present in the cluster. Has this node
finished starting up?
at
org.apache.cassandra.dht.Murmur3Partitioner.describeOwnership(Murmur3Partitioner.java:309)
at
org.apache.cassandra.service.StorageService.getEffectiveOwnership(StorageService.java:4066)
at
org.apache.cassandra.service.StorageService.effectiveOwnershipWithPort(StorageService.java:4098)
at
org.apache.cassandra.service.StorageService.effectiveOwnershipWithPort(StorageService.java:264)
{code}
which makes sense (albeit I would get rid of that stacktrace), but I am not
sure every command is prepared for cases when StorageService is available,
while the node has not boostrapped fully yet.
We would need to check that every operation in storage service makes sense to
be executed even node is not bootstrapped fully and if it is not then we would
need to throw like above.
This also means that we can invoke StorageServiceMBean methods before the node
is fully bootstrapped / up. Is not this opening us to various potential
problems when we are able to set something prematurely?
was (Author: smiklosovic):
Looks good on paper, I am just trying to understand what happens when
StorageService is indeed available during bootstrap and e.g. various nodetool
commands are executed, proceeding just happily because StorageService is there,
but StorageService might return meaningless / not accurate results back to
nodetool which will try to parse what StorageService returned and for some
weird reason it will not be able to.
Now it returns something like this:
{code:java}
$ ./bin/nodetool status
error: No nodes present in the cluster. Has this node finished starting up?
-- StackTrace --
java.lang.RuntimeException: No nodes present in the cluster. Has this node
finished starting up?
at
org.apache.cassandra.dht.Murmur3Partitioner.describeOwnership(Murmur3Partitioner.java:309)
at
org.apache.cassandra.service.StorageService.getEffectiveOwnership(StorageService.java:4066)
at
org.apache.cassandra.service.StorageService.effectiveOwnershipWithPort(StorageService.java:4098)
at
org.apache.cassandra.service.StorageService.effectiveOwnershipWithPort(StorageService.java:264)
{code}
which makes sense (albeit I would get rid of that stacktrace), but I am not
sure every command is prepared for cases when StorageService is available,
while the node has not boostrapped fully yet.
We would need to check that every operation in storage service makes sense to
be executed even node is not bootstrapped fully and if it is not then we would
need to throw like above.
> StorageService JMX mbean is not available during bootstrap
> ----------------------------------------------------------
>
> Key: CASSANDRA-19902
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19902
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
> Reporter: Paulo Motta
> Assignee: Paulo Motta
> Priority: Normal
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Looks like the seemingly harmless cosmetic patch from CASSANDRA-11537 causes
> the StorageServiceMBean to not be available during bootstrap. This causes
> commands like "nodetool nestats/status/etc" to not be available on the
> boostrapping node with the following error:
> {code:none}
> - StackTrace --
> javax.management.InstanceNotFoundException:
> org.apache.cassandra.db:type=StorageService
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1083)
> at
> java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:637)
> {code}
> This ticket is just to revert CASSANDRA-11537, we can re-add the improvement
> of that ticket later.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
