[
https://issues.apache.org/jira/browse/GEODE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16709068#comment-16709068
]
Helena Bales edited comment on GEODE-47 at 12/4/18 6:15 PM:
------------------------------------------------------------
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
### It would look like the locators and servers are running in the foreground,
but the command would actually be in the foreground
### Might not survive the Gfsh process being killed or dying.
## 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 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
# How does logging get redirected to the foreground process?
# What happens if the Gfsh process is killed or dies?
was (Author: balesh2):
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)
