[JBoss JIRA] (WFCORE-43) Clarify the meaning of the 'server-state' and 'host-state' attributes
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-43?page=com.atlassian.jira.plugin.... ]
Ken Wills commented on WFCORE-43:
---------------------------------
I think OK is the winner, shows the user everything is fine.
> Clarify the meaning of the 'server-state' and 'host-state' attributes
> ---------------------------------------------------------------------
>
> Key: WFCORE-43
> URL: https://issues.jboss.org/browse/WFCORE-43
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Ken Wills
> Fix For: 3.0.0.Beta1
>
>
> This JIRA is to implement what I described in the dev list discussion around the various states a server can be in for graceful shutdown (http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002360.html)
> "I do think these are orthogonal and should not be combined.
> The existing attribute is fundamentally about how the state of the
> runtime services relates to the persistent configuration.
> STARTING == out of sync due to still getting in sync during start
> RUNNING == in sync
> RELOAD_REQUIRED = out of sync, needs a reload to get in sync
> RESTART_REQUIRED = out of sync, needs a full process restart to get in sync
> There are two problems though with the existing attribute that exposes this:
> 1) It's named "server-state" on a server and "host-state" on a Host
> Controller. Really crappy name; way too broad.
> That's fixable by creating a new attribute and making the old one an
> alias for compatibility purposes.
> 2) The RUNNING state is really poorly named.
> The could perhaps be fixed by coming up with a new name and translating
> it back to "RUNNING" in the handlers for the legacy "server-state" and
> "host-state" attributes."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-43) Clarify the meaning of the 'server-state' and 'host-state' attributes
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-43?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFCORE-43:
----------------------------------------
Re: SYNCED -- when a process is admin-only but started and functioning normally, the runtime state isn't *synced* with the config, but it is OK or NORMAL. So I prefer those.
runtime-configuration-state sounds ok.
> Clarify the meaning of the 'server-state' and 'host-state' attributes
> ---------------------------------------------------------------------
>
> Key: WFCORE-43
> URL: https://issues.jboss.org/browse/WFCORE-43
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Ken Wills
> Fix For: 3.0.0.Beta1
>
>
> This JIRA is to implement what I described in the dev list discussion around the various states a server can be in for graceful shutdown (http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002360.html)
> "I do think these are orthogonal and should not be combined.
> The existing attribute is fundamentally about how the state of the
> runtime services relates to the persistent configuration.
> STARTING == out of sync due to still getting in sync during start
> RUNNING == in sync
> RELOAD_REQUIRED = out of sync, needs a reload to get in sync
> RESTART_REQUIRED = out of sync, needs a full process restart to get in sync
> There are two problems though with the existing attribute that exposes this:
> 1) It's named "server-state" on a server and "host-state" on a Host
> Controller. Really crappy name; way too broad.
> That's fixable by creating a new attribute and making the old one an
> alias for compatibility purposes.
> 2) The RUNNING state is really poorly named.
> The could perhaps be fixed by coming up with a new name and translating
> it back to "RUNNING" in the handlers for the legacy "server-state" and
> "host-state" attributes."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-5332) Allow configure max-threads and core-threads independently. Allow idle thread reusage.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-5332?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-5332:
-----------------------------------------------
Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1255494|https://bugzilla.redhat.com/show_bug.cgi?id=1255494] from POST to CLOSED
> Allow configure max-threads and core-threads independently. Allow idle thread reusage.
> --------------------------------------------------------------------------------------
>
> Key: WFLY-5332
> URL: https://issues.jboss.org/browse/WFLY-5332
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Reporter: Panagiotis Sotiropoulos
> Assignee: Panagiotis Sotiropoulos
> Attachments: JBossThreadPoolExecutor.jpg, JBossThreadPoolReuseIdleThreadsExecutor.jpg, ModifiedJBossThreadPoolExecutorStateDiagram.jpg
>
>
> Description of problem:
> It looks like the ejb3 subsystem thread pool configuration is hard coded to create an unbounded thread pool, where it it looks like max-threads = core-threads, and thus the threads will increase up to the max-threads configured and then remain there. The keep-alive setting which appears in many of the docs & default configurations is ineffective since max=core.
> ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemRootResourceDefinition.java
> I tried defining a different thread pool in the threads subsystem and tried to reference it from the ejb3 subsystem, however it looks like the ejb3 subsystem only looks for thread pools configured in the ejb3 subsystem.
> Additional desired functionality according to PRODMGT-1401:
> "the desired functionality is to, when a new request arrives
> and there is an idle thread, use that thread instead of creating a new
> thread [up until max-threads]."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-43) Clarify the meaning of the 'server-state' and 'host-state' attributes
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-43?page=com.atlassian.jira.plugin.... ]
Ken Wills edited comment on WFCORE-43 at 3/24/16 6:58 PM:
----------------------------------------------------------
runtime-configuration-state = SYNCED | SYNCHRONIZED("Up to date") | OK | NORMAL | CURRENT
configuration-state
persistent-configuration-state
persistent-runtime-configuration-state
I'm leaning towards 'runtime-configuration-state,' as its specific.
For the value itself, perhaps OK or SYNCED.
edit: don't like ACTIVE.
was (Author: luck3y):
runtime-configuration-state = SYNCED | SYNCHRONIZED("Up to date") | OK | NORMAL | CURRENT
configuration-state
persistent-configuration-state
persistent-runtime-configuration-state
I'm leaning towards 'runtime-configuration-state,' as its specific.
For the value itself, perhaps OK, ACTIVE or SYNCED.
> Clarify the meaning of the 'server-state' and 'host-state' attributes
> ---------------------------------------------------------------------
>
> Key: WFCORE-43
> URL: https://issues.jboss.org/browse/WFCORE-43
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Ken Wills
> Fix For: 3.0.0.Beta1
>
>
> This JIRA is to implement what I described in the dev list discussion around the various states a server can be in for graceful shutdown (http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002360.html)
> "I do think these are orthogonal and should not be combined.
> The existing attribute is fundamentally about how the state of the
> runtime services relates to the persistent configuration.
> STARTING == out of sync due to still getting in sync during start
> RUNNING == in sync
> RELOAD_REQUIRED = out of sync, needs a reload to get in sync
> RESTART_REQUIRED = out of sync, needs a full process restart to get in sync
> There are two problems though with the existing attribute that exposes this:
> 1) It's named "server-state" on a server and "host-state" on a Host
> Controller. Really crappy name; way too broad.
> That's fixable by creating a new attribute and making the old one an
> alias for compatibility purposes.
> 2) The RUNNING state is really poorly named.
> The could perhaps be fixed by coming up with a new name and translating
> it back to "RUNNING" in the handlers for the legacy "server-state" and
> "host-state" attributes."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-43) Clarify the meaning of the 'server-state' and 'host-state' attributes
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-43?page=com.atlassian.jira.plugin.... ]
Ken Wills commented on WFCORE-43:
---------------------------------
runtime-configuration-state = SYNCED | SYNCHRONIZED("Up to date") | OK | NORMAL | CURRENT
configuration-state
persistent-configuration-state
persistent-runtime-configuration-state
I'm leaning towards 'runtime-configuration-state,' as its specific.
For the value itself, perhaps OK, ACTIVE or SYNCED.
> Clarify the meaning of the 'server-state' and 'host-state' attributes
> ---------------------------------------------------------------------
>
> Key: WFCORE-43
> URL: https://issues.jboss.org/browse/WFCORE-43
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Ken Wills
> Fix For: 3.0.0.Beta1
>
>
> This JIRA is to implement what I described in the dev list discussion around the various states a server can be in for graceful shutdown (http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002360.html)
> "I do think these are orthogonal and should not be combined.
> The existing attribute is fundamentally about how the state of the
> runtime services relates to the persistent configuration.
> STARTING == out of sync due to still getting in sync during start
> RUNNING == in sync
> RELOAD_REQUIRED = out of sync, needs a reload to get in sync
> RESTART_REQUIRED = out of sync, needs a full process restart to get in sync
> There are two problems though with the existing attribute that exposes this:
> 1) It's named "server-state" on a server and "host-state" on a Host
> Controller. Really crappy name; way too broad.
> That's fixable by creating a new attribute and making the old one an
> alias for compatibility purposes.
> 2) The RUNNING state is really poorly named.
> The could perhaps be fixed by coming up with a new name and translating
> it back to "RUNNING" in the handlers for the legacy "server-state" and
> "host-state" attributes."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-273) ServerInventory#reconnectServer should take auto-start into account
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-273?page=com.atlassian.jira.plugin... ]
Ken Wills commented on WFCORE-273:
----------------------------------
After doing quite a bit of testing on this, the bug has either been fixed by one of the other changes in this area, or I'm just not seeing it. A server marked with auto-start="false" that is started, is shown stopped and shown as disabled after HC reload and disconnect / reconnect of the HC and various other combinations, both on the master HC and slaves.
It appears the attribute update-auto-start-with-server-status was added to track the running states across reloads, and with this enabled the last running state is reflected correctly (auto-start=false / update-auto-start-with-server-status = true and server = RUNNING, after a HC reload the server is correctly restarted).
[~bstansberry] Do you happen to remember anything else about this bug?
> ServerInventory#reconnectServer should take auto-start into account
> -------------------------------------------------------------------
>
> Key: WFCORE-273
> URL: https://issues.jboss.org/browse/WFCORE-273
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Emanuel Muckenhuber
> Assignee: Ken Wills
> Fix For: 3.0.0.Alpha1
>
>
> When reconnecting to stopped (but not removed) servers, the ServerInventory should take the auto-start property into account. Otherwise the process will just get removed, however started with the next :reload of the HC.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-43) Clarify the meaning of the 'server-state' and 'host-state' attributes
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-43?page=com.atlassian.jira.plugin.... ]
Ken Wills commented on WFCORE-43:
---------------------------------
(Obvious aside: Only 2 hard problems in CS, naming things, cache-invalidation and off by one errors).
The placeholder I'm using is actually called IN_SYNC ... I will confess to not being a huge fan of the boy-band, but maybe it will help me to appear to be more hip and "with it" ;)
Going to noodle a bit more and update this.
> Clarify the meaning of the 'server-state' and 'host-state' attributes
> ---------------------------------------------------------------------
>
> Key: WFCORE-43
> URL: https://issues.jboss.org/browse/WFCORE-43
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Ken Wills
> Fix For: 3.0.0.Beta1
>
>
> This JIRA is to implement what I described in the dev list discussion around the various states a server can be in for graceful shutdown (http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002360.html)
> "I do think these are orthogonal and should not be combined.
> The existing attribute is fundamentally about how the state of the
> runtime services relates to the persistent configuration.
> STARTING == out of sync due to still getting in sync during start
> RUNNING == in sync
> RELOAD_REQUIRED = out of sync, needs a reload to get in sync
> RESTART_REQUIRED = out of sync, needs a full process restart to get in sync
> There are two problems though with the existing attribute that exposes this:
> 1) It's named "server-state" on a server and "host-state" on a Host
> Controller. Really crappy name; way too broad.
> That's fixable by creating a new attribute and making the old one an
> alias for compatibility purposes.
> 2) The RUNNING state is really poorly named.
> The could perhaps be fixed by coming up with a new name and translating
> it back to "RUNNING" in the handlers for the legacy "server-state" and
> "host-state" attributes."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-43) Clarify the meaning of the 'server-state' and 'host-state' attributes
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-43?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFCORE-43:
----------------------------------------
BTW, once we reach some conclusions on this, please add a post to the thread linked in the description giving everyone an update on what will happen.
> Clarify the meaning of the 'server-state' and 'host-state' attributes
> ---------------------------------------------------------------------
>
> Key: WFCORE-43
> URL: https://issues.jboss.org/browse/WFCORE-43
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Ken Wills
> Fix For: 3.0.0.Beta1
>
>
> This JIRA is to implement what I described in the dev list discussion around the various states a server can be in for graceful shutdown (http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002360.html)
> "I do think these are orthogonal and should not be combined.
> The existing attribute is fundamentally about how the state of the
> runtime services relates to the persistent configuration.
> STARTING == out of sync due to still getting in sync during start
> RUNNING == in sync
> RELOAD_REQUIRED = out of sync, needs a reload to get in sync
> RESTART_REQUIRED = out of sync, needs a full process restart to get in sync
> There are two problems though with the existing attribute that exposes this:
> 1) It's named "server-state" on a server and "host-state" on a Host
> Controller. Really crappy name; way too broad.
> That's fixable by creating a new attribute and making the old one an
> alias for compatibility purposes.
> 2) The RUNNING state is really poorly named.
> The could perhaps be fixed by coming up with a new name and translating
> it back to "RUNNING" in the handlers for the legacy "server-state" and
> "host-state" attributes."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-43) Clarify the meaning of the 'server-state' and 'host-state' attributes
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-43?page=com.atlassian.jira.plugin.... ]
Brian Stansberry edited comment on WFCORE-43 at 3/24/16 5:53 PM:
-----------------------------------------------------------------
[~luck3y]
For (2) how about NORMAL?
For WFCORE-1106 for internal use I ended up need a different enum that covered the same concept and I ended up using 'NORMAL'
https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO...
That's not definitive or anything; ^^^ is an internal enum and TBH I didn't think that hard about the NORMAL name. ;)
"SYNCHRONIZED" is valid; agree it's a bit heavy though. "IN_SYNC"? Do you like boy bands? Or hearing lots of boy band jokes? ;)
Re: 1) this is the more important question. A simple value like "NORMAL" is only ok if the name of the attribute makes it pretty clear what it is that's normal. So, not 'process-state'. We already have a 'running-mode' for --admin-only vs not. 'run-state' seems too vague too. Brainstorming I come up with 'configuration-sync' but I'm not going to pretend that's good.
Maybe 'configuration-state"? That's still a bit weird but this is all about the state of the runtime with respect to the persistent configuration.
A main goal is to come up with something where if we add some new feature and need to describe some state, we don't get a name conflict again.
Haha, now I remember why this issue is 21 months old!
was (Author: brian.stansberry):
For (2) how about NORMAL?
For WFCORE-1106 for internal use I ended up need a different enum that covered the same concept and I ended up using 'NORMAL'
https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCO...
That's not definitive or anything; ^^^ is an internal enum and TBH I didn't think that hard about the NORMAL name. ;)
"SYNCHRONIZED" is valid; agree it's a bit heavy though. "IN_SYNC"? Do you like boy bands? Or hearing lots of boy band jokes? ;)
Re: 1) this is the more important question. A simple value like "NORMAL" is only ok if the name of the attribute makes it pretty clear what it is that's normal. So, not 'process-state'. We already have a 'running-mode' for --admin-only vs not. 'run-state' seems too vague too. Brainstorming I come up with 'configuration-sync' but I'm not going to pretend that's good.
Maybe 'configuration-state"? That's still a bit weird but this is all about the state of the runtime with respect to the persistent configuration.
A main goal is to come up with something where if we add some new feature and need to describe some state, we don't get a name conflict again.
Haha, now I remember why this issue is 21 months old!
> Clarify the meaning of the 'server-state' and 'host-state' attributes
> ---------------------------------------------------------------------
>
> Key: WFCORE-43
> URL: https://issues.jboss.org/browse/WFCORE-43
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Ken Wills
> Fix For: 3.0.0.Beta1
>
>
> This JIRA is to implement what I described in the dev list discussion around the various states a server can be in for graceful shutdown (http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002360.html)
> "I do think these are orthogonal and should not be combined.
> The existing attribute is fundamentally about how the state of the
> runtime services relates to the persistent configuration.
> STARTING == out of sync due to still getting in sync during start
> RUNNING == in sync
> RELOAD_REQUIRED = out of sync, needs a reload to get in sync
> RESTART_REQUIRED = out of sync, needs a full process restart to get in sync
> There are two problems though with the existing attribute that exposes this:
> 1) It's named "server-state" on a server and "host-state" on a Host
> Controller. Really crappy name; way too broad.
> That's fixable by creating a new attribute and making the old one an
> alias for compatibility purposes.
> 2) The RUNNING state is really poorly named.
> The could perhaps be fixed by coming up with a new name and translating
> it back to "RUNNING" in the handlers for the legacy "server-state" and
> "host-state" attributes."
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month