[JBoss JIRA] (WFCORE-1642) Fix domain mode for configuration changes
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1642?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet moved JBEAP-5172 to WFCORE-1642:
--------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1642 (was: JBEAP-5172)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
(was: Domain Management)
Affects Version/s: 3.0.0.Alpha3
(was: 7.0.0.GA)
> Fix domain mode for configuration changes
> -----------------------------------------
>
> Key: WFCORE-1642
> URL: https://issues.jboss.org/browse/WFCORE-1642
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha3
> Reporter: ehsavoie Hugonnet
> Assignee: Brian Stansberry
>
> The configuration changes feature is broken in domain mode: the propagation to managed servers / slaves HC doesn't work properly. Once set it will fail on restarting the DC. So we need a clean refactoring of the feature to have a usable domain mode.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFCORE-1642) Fix domain mode for configuration changes
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1642?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet reassigned WFCORE-1642:
-----------------------------------------
Assignee: ehsavoie Hugonnet (was: Brian Stansberry)
> Fix domain mode for configuration changes
> -----------------------------------------
>
> Key: WFCORE-1642
> URL: https://issues.jboss.org/browse/WFCORE-1642
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha3
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
>
> The configuration changes feature is broken in domain mode: the propagation to managed servers / slaves HC doesn't work properly. Once set it will fail on restarting the DC. So we need a clean refactoring of the feature to have a usable domain mode.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-6808) DistributableSession validate method throw misleading exception message
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6808?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-6808:
-------------------------------
Fix Version/s: 10.1.0.Final
> DistributableSession validate method throw misleading exception message
> -----------------------------------------------------------------------
>
> Key: WFLY-6808
> URL: https://issues.jboss.org/browse/WFLY-6808
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Mathieu Lachance
> Assignee: Paul Ferraro
> Fix For: 10.1.0.Final
>
>
> In DistributableSession the validate method is getting called for any underlying undertow session access to make sure we are not touching an already invalidated session (which totally make sense):
> {code}
> public class DistributableSession implements io.undertow.server.session.Session {
> private static void validate(Session<LocalSessionContext> session) {
> if (!session.isValid()) {
> throw UndertowMessages.MESSAGES.sessionNotFound(session.getId());
> }
> }
> }
> {code}
> The problem though is the exception message that is thrown is really misleading because in reality the session actually exists but is currently invalid and/or getting invalidated. This can happen especially when running in optimistic mode where we can have many differents threads accessing the very same session.
> I would recommend we do instead:
> {code}
> if (!session.isValid()) {
> throw UndertowMessages.MESSAGES.sessionAlreadyInvalidated();
> }
> {code}
> or even better:
> {code}
> if (!session.isValid()) {
> throw UndertowMessages.MESSAGES.sessionAlreadyInvalidated(session.getId());
> }
> {code}
> but it will require also a change in Undertow to actually template/parametize the sessionAlreadyInvalidated message.
> Thanks,
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFCORE-1637) headers in Operation and Command are not properly completed
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1637?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise updated WFCORE-1637:
-----------------------------------------
Description:
For example:
1) ls --headers {allow-resource-service-restart <TAB>
doesn't give you the '='
2) ls --headers {allow-resource-service-restart=true; <TAB>
list you the commands one can type...not at al an header.
3) NPE caused by WFCORE-1617
ls --headers {allow-resource-service-restart=t<TAB> ==> NPE
Completion should properly complete each header.
was:
For example:
1) ls --headers {allow-resource-service-restart <TAB>
doesn't give you the '='
2) ls --headers {allow-resource-service-restart=true; <TAB>
list you the commands one can type...not at al an header.
Completion should properly complete each header.
> headers in Operation and Command are not properly completed
> -----------------------------------------------------------
>
> Key: WFCORE-1637
> URL: https://issues.jboss.org/browse/WFCORE-1637
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> For example:
> 1) ls --headers {allow-resource-service-restart <TAB>
> doesn't give you the '='
> 2) ls --headers {allow-resource-service-restart=true; <TAB>
> list you the commands one can type...not at al an header.
> 3) NPE caused by WFCORE-1617
> ls --headers {allow-resource-service-restart=t<TAB> ==> NPE
> Completion should properly complete each header.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months