Mario Salazar de Torres created GEODE-9478:
----------------------------------------------
Summary: Fix member status logic when directory specified
Key: GEODE-9478
URL: https://issues.apache.org/jira/browse/GEODE-9478
Project: Geode
Issue Type: Bug
Components: core
Reporter: Mario Salazar de Torres
As result of doing some tests with the status GFSH command in a cloud native
environment, it has been noticed that when --dir option, the internal logic, if
API attachment is enabled, tries to access the JMX interface to query the
server status.
And in order to obtain the JMX URL, the logic tries to attach to the member
with its PID. But, the thing is that in the problematic use case, both the
member and Gfsh/equivalent app using Gfsh API are in different containers, and
such containers do not share the PID namespace.
When both member and the status requesting application have different PIDs the
request fails given that the requesting application can't locate the member PID
on its namespace, sending a SIGQUIT (in a unix-like env) and throwing an
exception stating "no such process...". And if the internal logic notices that
the process couldn't be found, instead of failing over the
FileProcessController, it propagates the exception, causing the status request
to fail.
Additionally it has been observed that with the current logic, the status
command success if and only if the PID of the application executing the status
command, and the PID of the member are the same. I.E: PID 1
The reason for that apparently is that there is some check in the JVM
attachment API that verifies if the PID of the JVM you are trying to attach is
the same as yours. If that's the case, it supposes that you are trying to
attach to yourself and throws an exception.
In that case, the exception is catched by the internal logic and the status
request failovers to the FileProcessController.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
