You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Dave Barnes (JIRA)" <ji...@apache.org> on 2018/02/27 00:12:00 UTC

[jira] [Assigned] (GEODE-4101) Replace Redirection Sytem Properties by --redirect-output flag in GFSH commands

     [ https://issues.apache.org/jira/browse/GEODE-4101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dave Barnes reassigned GEODE-4101:
----------------------------------

    Assignee: Dave Barnes  (was: Kenneth Howe)

> Replace Redirection Sytem Properties by --redirect-output flag in GFSH commands
> -------------------------------------------------------------------------------
>
>                 Key: GEODE-4101
>                 URL: https://issues.apache.org/jira/browse/GEODE-4101
>             Project: Geode
>          Issue Type: Bug
>          Components: docs, gfsh
>            Reporter: Juan José Ramos Cassella
>            Assignee: Dave Barnes
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 1.5.0
>
>
> Currently GEODE is "swallowing" all output sent to stdout and stderr by default and there's no way of changing this behavior when starting members through gfsh.
> This, between other things, prevents users from playing around with {{System.out.println()}} during development phases, there could even be certain scenarios where some critical piece of information that comes out through stdout somehow bypassed all the logging frameworks. Not only that, but this also prevents the user from getting thread dumps by executing a plain {{kill -3}} or {{kill -QUIT}} using the processId, which is critical in troubleshooting.
> Currently there are two internal flags that can be used to prevent this default behavior, both have to be used at the same time and both are very counterintuitive {{gemfire.OSProcess.ENABLE_OUTPUT_REDIRECTION=true}} and {{gemfire.OSProcess.DISABLE_OUTPUT_REDIRECTION=false}}. These flags, however, don't work at all when starting members through {{gfsh}}, and that's because the relevant commands wrongly assume that the flags are already part of the system properties too early in the lifecylce execution of the command:
> {code:title=StartLocatorCommand.java|borderStyle=solid}
> @CliCommand(value = CliStrings.START_LOCATOR, help = CliStrings.START_LOCATOR__HELP)
> @CliMetaData(shellOnly = true, relatedTopic = {CliStrings.TOPIC_GEODE_LOCATOR, CliStrings.TOPIC_GEODE_LIFECYCLE})
> public Result startLocator(...) throws Exception {
> 	(...)
> 	final boolean redirectOutput = Boolean.getBoolean(OSProcess.ENABLE_OUTPUT_REDIRECTION_PROPERTY);
> 	LocatorLauncher.Builder locatorLauncherBuilder =
> 		new LocatorLauncher.Builder()
>             .setRedirectOutput(redirectOutput)
> 	(...)
> }
> {code}
> {code:title=StartServerCommand.java|borderStyle=solid}
> @CliCommand(value = CliStrings.START_SERVER, help = CliStrings.START_SERVER__HELP)
> @CliMetaData(shellOnly = true, relatedTopic = {CliStrings.TOPIC_GEODE_SERVER, CliStrings.TOPIC_GEODE_LIFECYCLE})
> public Result startServer(...) throws Exception {
> 	(...)
> 	final boolean redirectOutput = Boolean.getBoolean(OSProcess.ENABLE_OUTPUT_REDIRECTION_PROPERTY);
>     ServerLauncher.Builder serverLauncherBuilder = 
>     	new ServerLauncher.Builder()
>         .setRedirectOutput(redirectOutput)
> 	(...)
> {code}
> At this stage during the execution, the system properties used when starting the members haven't been fully parsed yet and the flags only present within the {{sun.java.command}} system property, so {{Boolean.getBoolean(OSProcess.ENABLE_OUTPUT_REDIRECTION_PROPERTY)}} will always return {{false}}.
> The goal of the current JIRA is to add a {{--redirect-ouput}} flag to the start commands in {{GFSH}} and deprecate the properties {{OSProcess.DISABLE_OUTPUT_REDIRECTION}} and {{OSProcess.ENABLE_OUTPUT_REDIRECTION}}; unfortunately they can't be directly deleted because, even when they are internal, they've been referenced several times in external articles to workaround older issues.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)