[
https://issues.apache.org/jira/browse/GEODE-9478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18031511#comment-18031511
]
ASF subversion and git services commented on GEODE-9478:
--------------------------------------------------------
Commit a80762516f55b91b5967e722b7a5fbb5755744f6 in geode's branch
refs/heads/develop from Mario Salazar de Torres
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a80762516f ]
GEODE-9478: Fix status --dir to use file controller (#6737)
* GEODE-9478: Fix status --dir to use file controller
- Previously when you only specified --dir option the PID was read from
the member workDir and the status request was attempted to solved by
using the attachment API, and after that JMX interface.
But given only --dir was specified the controller resolving the
request should be FileProcessController instead.
- Logic has been changed for both servers and locators to always use
FileProcessConroller whenever only --dir flag is specified.
- Added an UT to verify new code.
- Modified several ITs to verify the new behaviour.
- Deleted the following ITs which no longer apply with the new logic:
* statusWithEmptyPidFileThrowsIllegalArgumentException
* statusWithEmptyWorkingDirectoryReturnsNotRespondingWithDetails
* statusWithStalePidFileReturnsNotResponding
* GEODE-9478: Revision 1
- Removed throws in javadoc given new constructors doesn't have any PID
---------
Co-authored-by: Mario Salazar de Torres <[email protected]>
> 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
> Assignee: Mario Salazar de Torres
> Priority: Minor
> Labels: pull-request-available
>
> 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.20.10#820010)
