[
https://issues.apache.org/jira/browse/CASSANDRA-19902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18009545#comment-18009545
]
Stefan Miklosovic edited comment on CASSANDRA-19902 at 7/24/25 11:30 AM:
-------------------------------------------------------------------------
Let's see how CI will look like. Very curious what it breaks.
Also, for example here (1), there is
{code}
private volatile Mode operationMode = Mode.STARTING;
{code}
removed from StorageService. It was used in isDecommissioned() /
isDecommissioning in StorageService but that patch started to do
{code}
public boolean isDecommissioned()
{
return operationMode() == DECOMMISSIONED;
}
{code}
where operationMode() is the method we are discussing above. So, basically, if
you called "isDecommissioned" while node was executing initServer() (I know it
is weird to call it during that, just for the sake of argument), it would
returned "STARTING", which would evalute whole method correctly by returning
false as it is not equal to DECOMMISSIONED but it does not derive that mode
from TCM's NodeState as it should but it is deriving it from the fact that
initServer() is not finished yet which is quite strange ...
(1) https://github.com/apache/cassandra/pull/3646/files
was (Author: smiklosovic):
Let's see how CI will look like. Very curious what it breaks.
Also, for example here (1), there is
{code}
private volatile Mode operationMode = Mode.STARTING;
{code}
removed from StorageService. It was used in isDecommissioned() /
isDecommissioning in StorageService but that patch started to do
{code}
public boolean isDecommissioned()
{
return operationMode() == DECOMMISSIONED;
}
{code}
where operationMode() is the method we are discussing above. So, basically, if
you called "isDecommissioned" while node was executing initServer(), it would
returned "STARTING", which would evalute whole method correctly by returning
false as it is not equal to DECOMMISSIONED but it does not derive that mode
from TCM's NodeState as it should but it is deriving it from the fact that
initServer() is not finished yet which is quite strange ...
(1) https://github.com/apache/cassandra/pull/3646/files
> 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
> Fix For: 5.0.x, 5.x
>
> Time Spent: 1h 50m
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
