[jira] [Updated] (GEODE-9478) Fix member status logic when directory specified
[ https://issues.apache.org/jira/browse/GEODE-9478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9478: -- Labels: pull-request-available (was: ) > 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.3.4#803005)
[jira] [Updated] (GEODE-9478) Fix member status logic when directory specified
[ https://issues.apache.org/jira/browse/GEODE-9478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres updated GEODE-9478: --- Priority: Minor (was: Major) > 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 > > 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)
