[JBoss JIRA] (LOGMGR-161) AsyncHandler is always creating a stacktrace dump
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-161?page=com.atlassian.jira.plugin... ]
James Perkins reassigned LOGMGR-161:
------------------------------------
Assignee: James Perkins
> AsyncHandler is always creating a stacktrace dump
> -------------------------------------------------
>
> Key: LOGMGR-161
> URL: https://issues.jboss.org/browse/LOGMGR-161
> Project: JBoss Log Manager
> Issue Type: Enhancement
> Components: core
> Affects Versions: 2.1.0.Alpha1
> Reporter: Koen Janssens
> Assignee: James Perkins
>
> I have noticed that when introducing an AsyncHandler for logging, all log statement are copied before being put on the queue and as part of that copy a complete stack dump is done.
> This might be useful if the stack info is used by a downstream formatter (eg for line number identification), but even if the line numbers are not used anywhere, this still happens.
> I think this behavior should be at least optional.
> Source Location: org.jboss.logmanager.ExtLogRecord#copyAll
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months
[JBoss JIRA] (WFCORE-3073) Handle TERM gracefully
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3073?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3073:
-------------------------------------
Summary: Handle TERM gracefully (was: Handle TERM cleanly)
> Handle 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.Alpha1
>
>
> The wildfly server currently terminates immediately in response to a TERM signal. To achieve a clean 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.2.3#72005)
7 years, 6 months
[JBoss JIRA] (WFCORE-3124) Handle TERM gracefully
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3124:
----------------------------------------
Summary: Handle TERM gracefully
Key: WFCORE-3124
URL: https://issues.jboss.org/browse/WFCORE-3124
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Reporter: Ben Parees
Assignee: Brian Stansberry
Fix For: 4.0.0.Alpha1
The wildfly server currently terminates immediately in response to a TERM signal. To achieve a clean 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.2.3#72005)
7 years, 6 months
[JBoss JIRA] (ELY-1312) Further Scoping and Caching Enhancements to the SpnegoAuthenticationMechanism
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1312?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse commented on ELY-1312:
---------------------------------------
We could even take this slightly further and allow these options to apply to other mechanisms - e.g. FORM authentication could use an alternative SCOPE, e.g. specify SSL Scope and without an SSLSession FORM authentication is not possible.
This could mean if your connection is clear mechanisms such as Digest or SCRAM are possible but until an SSLSession is established FORM authentication is not possible. It could potentially become a simple form of SSO where a common SSLSession is used across multiple applications.
> Further Scoping and Caching Enhancements to the SpnegoAuthenticationMechanism
> -----------------------------------------------------------------------------
>
> Key: ELY-1312
> URL: https://issues.jboss.org/browse/ELY-1312
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: HTTP
> Environment: #
> Reporter: Darran Lofthouse
> Fix For: 1.2.0.Beta1
>
>
> Currently the SpnegoAuthenticationMechanism caches against the connection scope and uses the cached GssContext to recreate the identity.
> We should consider the following: -
> # Using the same cached identity mechanism as is used by FORM authentication.
> # Adding configuration to specify which scope to cache against.
> # Add an option to disable caching entirely, this would need to take into account cases where continuation is required as that would become unsupported.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months
[JBoss JIRA] (ELY-1312) Further Scoping and Caching Enhancements to the SpnegoAuthenticationMechanism
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-1312:
-------------------------------------
Summary: Further Scoping and Caching Enhancements to the SpnegoAuthenticationMechanism
Key: ELY-1312
URL: https://issues.jboss.org/browse/ELY-1312
Project: WildFly Elytron
Issue Type: Enhancement
Components: HTTP
Environment: #
Reporter: Darran Lofthouse
Fix For: 1.2.0.Beta1
Currently the SpnegoAuthenticationMechanism caches against the connection scope and uses the cached GssContext to recreate the identity.
We should consider the following: -
# Using the same cached identity mechanism as is used by FORM authentication.
# Adding configuration to specify which scope to cache against.
# Add an option to disable caching entirely, this would need to take into account cases where continuation is required as that would become unsupported.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 6 months