[JBoss JIRA] (WFCORE-3073) Handle Shutdown via TERM gracefully
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3073?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3073:
-------------------------------------
Fix Version/s: 4.0.0.Beta1
(was: 4.0.0.Alpha9)
> Handle Shutdown via TERM gracefully
> -----------------------------------
>
> Key: WFCORE-3073
> URL: https://issues.jboss.org/browse/WFCORE-3073
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Ben Parees
> Assignee: Brian Stansberry
> Fix For: 4.0.0.Beta1
>
>
> The wildfly server currently -terminates immediately- performs a standard (non-graceful) shutdown in response to a TERM signal. To achieve a -clean- graceful shutdown requires invoking the CLI tooling. This is particularly problematic in container environments like kubernetes where the container process (wildfly in this case) is going to get a TERM signal when the container needs to be moved.
> While it's possible to wrapper the process and handle the TERM and then invoke the CLI, it would be preferable for the server process itself to cleanly handle a TERM signal by waiting for in-flight requests to complete (w/ some grace period of course).
> Having this as configurable behavior would be good if there are backwards compatibility concerns about introducing this behavior change.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3019) The bin/product.conf and the org.jboss.as.product:wildfly-core module should come in via an FP
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3019?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3019:
-------------------------------------
Fix Version/s: 4.0.0.Beta1
(was: 4.0.0.Alpha9)
> The bin/product.conf and the org.jboss.as.product:wildfly-core module should come in via an FP
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-3019
> URL: https://issues.jboss.org/browse/WFCORE-3019
> Project: WildFly Core
> Issue Type: Task
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 4.0.0.Beta1
>
>
> For WFLY-4692 we moved the "product" stuff out of core-feature-pack and into dist. But this means it doesn't end up in the skinny dist produced by the "build" module. Plus it makes the "dist" a kind of FP of its own.
> The stuff in dist/src/distribution should be its own FP. That one *perhaps* depends on core-feature-pack. Then build and dist use the new FP in addition to or instead of core-feature-pack.
> So, core-feature-pack is independently usable, in other dists, but our offiical build/dist, which has our official product module, picks up the new FP.
> Whether the new "product" FP depends on core-feature-pack depends on how we want to use it; i.e. can this bin/product.conf and module be used in some other flavor of dist.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3000) Allow turning the security manager on on a per jvm basis
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3000?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3000:
-------------------------------------
Fix Version/s: 4.0.0.Beta1
(was: 4.0.0.Alpha9)
> Allow turning the security manager on on a per jvm basis
> --------------------------------------------------------
>
> Key: WFCORE-3000
> URL: https://issues.jboss.org/browse/WFCORE-3000
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Labels: domain-mode
> Fix For: 4.0.0.Beta1
>
>
> Turning on the security manager in a WildFly process is done by adding the -secmgr arg to org.jboss.modules.Main. But the jvm config settings in domain mode provide no mechanism for configuring args to Main; they only provide options for args to java. So there is no way to turn on the security manager for an individual jvm config (i.e. one or more servers) or if it is on for the HC there is no way to turn it off for a particular jvm config.
> The jvm config needs an attribute for this; default is undefined which should be documented as meaning the setting is derived from the HC's settings (i.e. the way it is now.)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-2930) Support a socket-binding-group as a child of profile
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2930?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2930:
-------------------------------------
Fix Version/s: 4.0.0.Beta1
(was: 4.0.0.Alpha9)
> Support a socket-binding-group as a child of profile
> ----------------------------------------------------
>
> Key: WFCORE-2930
> URL: https://issues.jboss.org/browse/WFCORE-2930
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
> Fix For: 4.0.0.Beta1
>
>
> Allow a single socket-binding-group resource as a child of profile, such that resolution of bindings from the subsystems are limited to the s-b-g associated with the profile.
> A server-group that uses such a profile cannot reference a socket-binding-group. And a server in that server-group cannot reference an s-b-g to override the one from the server-group/profile.
> I'm not sure how the s-b-g resource will work. Perhaps the resource would go away under 'profile' with the bindings direct children of profile. The 'default-interface' attribute then becomes an attribute of profile. Or perhaps there will be an s-b-g resource, but with a fixed name that's the same as the profile. Currently I think the latter.
> This will be necessary for resolution of config elements using the upcoming provisioning tool. The tool will not be able to do correct "feature" resolution using the complex rules we currently support.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFCORE-2830) Split testsuite/shared to distinguish things meant for sharing within the core testsuite from things usable in other projects
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2830?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2830:
-------------------------------------
Fix Version/s: 4.0.0.Beta1
(was: 4.0.0.Alpha9)
> Split testsuite/shared to distinguish things meant for sharing within the core testsuite from things usable in other projects
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2830
> URL: https://issues.jboss.org/browse/WFCORE-2830
> Project: WildFly Core
> Issue Type: Task
> Components: Test Suite
> Reporter: Brian Stansberry
> Fix For: 4.0.0.Beta1
>
>
> The testsuite/shared module includes two conceptually different types of code:
> 1) Things that are meant to be usable across different modules in core's own testsuite.
> 2) Things that we are willing to support for use in other projects that rely on WildFly Core.
> Since the two things are mixed, we are essentially supporting externally things that are not intended for use outside core. And it makes it difficult to evaluate new additions to testsuite/shared, to see whether the addition is really relevant to core and to see whether proposed external use is something we want.
> The purpose of WildFly Core is not to be a provider of testsuite utilities. For anything we expose for external use, there should be a substantial code maintenance benefit that comes from sharing it, something beyond avoiding code duplication.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months