[jira] [Commented] (GEODE-47) GFSH can't start servers in foreground

["Helena Bales (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GEODE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16709068#comment-16709068 ] 

Helena Bales commented on GEODE-47:
-----------------------------------

Summary of findings so far:
Locators and Servers should be able to start in the foreground through gfsh. When running in the foreground, the server and locator processes should respond to SIGINT by shutting down. 

There should be a command line option in Gfsh (--foreground) on the `start server` and `start locator` commands. This option should cause the process to stay alive in the foreground and not return to Gfsh.

Logs should be redirected to the foreground by default instead of to a file when the --foreground option is used. If the user provides a property file that specifies a file to log to, that property should be respected.

The locators and servers should be able to be started in the foreground using either of the following commands:
{noformat}
$> gfsh start <locator/server> --foreground [other options]
{noformat}
{noformat}
$> gfsh
gfsh> start <locator/server> --foreground [other options]
{noformat}

When a server or locator is started directly (as in the first command), receiving SIGINT should cause the server/locator process to terminate and control should be returned to the caller.
When a gfsh console is started first (as in the second command), receiving SIGINT should cause the locator/server process to terminate and control to be returned to Gfsh.

Implementation details/questions:
# Which process should be in the foreground?
## The `start locator/server` command process
### Simplest implementation, loops at the end of the start command until the server is killed or SIGINT is received
### SIGINT results in the `start locator/server` process being terminated, not the actual server or locator that was started
### The user would have to stop the member after the foreground process has returned
### Still unclear how logging would work for this implementation
### It would look like the locators and servers are running in the foreground, but the command would actually be in the foreground
### What would happen to the server if the Gfsh process were killed?
## The LocatorLauncher or ServerLauncher process
### More complicated implementation
### start locator/server command would have to return then the locator/server process would be in the foreground
### SIGINT results in the server or member being killed
### Still unclear how logging would work
### Still unclear how LocatorLauncher and ServerLauncher end up in the foreground
### Could probably survive the Gfsh process being killed
### More technically correct; the locators and servers would actually be the foreground processes

> GFSH can't start servers in foreground
> --------------------------------------
>
>                 Key: GEODE-47
>                 URL: https://issues.apache.org/jira/browse/GEODE-47
>             Project: Geode
>          Issue Type: Improvement
>          Components: gfsh
>            Reporter: William Markito Oliveira
>            Assignee: Helena Bales
>            Priority: Minor
>              Labels: EaseOfUse, SmallFeature, StartLocatorCommand, StartServerCommand, gfsh, gsoc2016, pull-request-available
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> There are certain cases where users may want to use gfsh and start members (locator or servers) in foreground.
> In old scripts there was an alternative to have servers started in foreground but that's not available anymore. 



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