[JBoss JIRA] (WFCORE-200) Ability to launch server instances under different Linux cgroups
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-200?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-200:
-----------------------------------------
I'm not too keen on platform specific stuff as it puts us in the mode of having to deal with the fact that things provided by external parties over which we have no control may no longer work. For example, recently I've had to waste a fair amount of time dealing with the fact that "permgen" is no longer a useful concept in the server VM configuration.
Granted, the same situation applies for any project we integrate via a subsystem, but typically before shipping a subsystem as part of WildFly, and even more so for EAP, we have a decent sense that we'll be able to compatibly manage that subsystem.
> Ability to launch server instances under different Linux cgroups
> ----------------------------------------------------------------
>
> Key: WFCORE-200
> URL: https://issues.jboss.org/browse/WFCORE-200
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Server
> Environment: Linux specific
> Reporter: James Livingston
> Assignee: Jason Greene
>
> Linux supports 'cgroups' which allows certain limitations to be applied to a group of processes, such as binding to specific CPU cores or apply CPU usage limits. It would be nice to be able to have a server group or specific server to be launched under a different cgroup so that more fine grained limits can be applied than to the whole host. Obviously this would be Linux specific.
> If the cgexec command is available, using "cgexec -g cpu:groupname java ..." rather than "java ..." allows the running of the process under a different cpu cgroup. It should be possible to do this now by pointing it to a shell script rather than the actual java executable, and having the script identify the server from arguments, and then invoking the real java executable via cgexec.
> The 'cgexec' tool uses the native code cglib, but I believe that if we just need to put processes under a control group, it is very simple -
> just write the process ID to /sys/fs/cgroup/HIERARCHY/GROUPNAME/tasks (where HIERARCHY is 'cpu', 'cpu,cpuacct' or other appropriate thing).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5890) Default mod_cluster load metric cpu (AverageSystemLoadMetric) is not supported on Windows
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5890?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-5890:
---------------------------------
Priority: Major (was: Critical)
> Default mod_cluster load metric cpu (AverageSystemLoadMetric) is not supported on Windows
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-5890
> URL: https://issues.jboss.org/browse/WFLY-5890
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Reporter: Michal Karm Babacek
> Assignee: Radoslav Husar
> Labels: ux
>
> h3. Problem
> Wildfly 10's default load metric changed from *busyness* to *cpu*. Although otherwise fine, this change has a one major drawback: It doesn't work on Windows JDKs: MODCLUSTER-234. This fact has been known and acknowledged since 2011.
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:2.0">
> <mod-cluster-config advertise-socket="modcluster" connector="ajp">
> <dynamic-load-provider>
> <load-metric type="cpu"/>
> </dynamic-load-provider>
> </mod-cluster-config>
> </subsystem>
> {code}
> Instead of a valid Load value, subsystem returns 0 and prints: {{MODCLUSTER000045: AverageSystemLoadMetric is not supported on this system and will be disabled.}}
> h3. Example
> {code}
> C:\Users\Administrator>groovy https://gist.githubusercontent.com/Karm/be36292ae52ded419b46/raw/addd6abf...
> load: -1.0
> avail. processors: 4
> {code}
> {code}
> mbabacek@localhost:~$ groovy https://gist.githubusercontent.com/Karm/be36292ae52ded419b46/raw/addd6abf...
> load: 0.67
> avail. processors: 4
> {code}
> h3. Call to action
> IMHO, this is a Major user experience failure, the default should provide meaningful values on all major platforms.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5890) Default mod_cluster load metric cpu (AverageSystemLoadMetric) is not supported on Windows
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5890?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-5890:
---------------------------------
Priority: Critical (was: Major)
> Default mod_cluster load metric cpu (AverageSystemLoadMetric) is not supported on Windows
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-5890
> URL: https://issues.jboss.org/browse/WFLY-5890
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Reporter: Michal Karm Babacek
> Assignee: Radoslav Husar
> Priority: Critical
> Labels: ux
>
> h3. Problem
> Wildfly 10's default load metric changed from *busyness* to *cpu*. Although otherwise fine, this change has a one major drawback: It doesn't work on Windows JDKs: MODCLUSTER-234. This fact has been known and acknowledged since 2011.
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:2.0">
> <mod-cluster-config advertise-socket="modcluster" connector="ajp">
> <dynamic-load-provider>
> <load-metric type="cpu"/>
> </dynamic-load-provider>
> </mod-cluster-config>
> </subsystem>
> {code}
> Instead of a valid Load value, subsystem returns 0 and prints: {{MODCLUSTER000045: AverageSystemLoadMetric is not supported on this system and will be disabled.}}
> h3. Example
> {code}
> C:\Users\Administrator>groovy https://gist.githubusercontent.com/Karm/be36292ae52ded419b46/raw/addd6abf...
> load: -1.0
> avail. processors: 4
> {code}
> {code}
> mbabacek@localhost:~$ groovy https://gist.githubusercontent.com/Karm/be36292ae52ded419b46/raw/addd6abf...
> load: 0.67
> avail. processors: 4
> {code}
> h3. Call to action
> IMHO, this is a Major user experience failure, the default should provide meaningful values on all major platforms.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5890) Default mod_cluster load metric cpu (AverageSystemLoadMetric) is not supported on Windows
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5890?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-5890:
--------------------------------------
I agree, we need a metric that works by default everywhere.
The other reason for why cpu might not be an ideal metric is that in the typical virtualized deployment, the cpu might be reflecting the virtualized hardware, which can be far from reality to what was actually available to the VM.
Also let me remind that the reason why business metric went away was switch to undertow which no longer has 1 client = 1 thread concept that made this metric easy to use.
> Default mod_cluster load metric cpu (AverageSystemLoadMetric) is not supported on Windows
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-5890
> URL: https://issues.jboss.org/browse/WFLY-5890
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Reporter: Michal Karm Babacek
> Assignee: Radoslav Husar
> Labels: ux
>
> h3. Problem
> Wildfly 10's default load metric changed from *busyness* to *cpu*. Although otherwise fine, this change has a one major drawback: It doesn't work on Windows JDKs: MODCLUSTER-234. This fact has been known and acknowledged since 2011.
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:2.0">
> <mod-cluster-config advertise-socket="modcluster" connector="ajp">
> <dynamic-load-provider>
> <load-metric type="cpu"/>
> </dynamic-load-provider>
> </mod-cluster-config>
> </subsystem>
> {code}
> Instead of a valid Load value, subsystem returns 0 and prints: {{MODCLUSTER000045: AverageSystemLoadMetric is not supported on this system and will be disabled.}}
> h3. Example
> {code}
> C:\Users\Administrator>groovy https://gist.githubusercontent.com/Karm/be36292ae52ded419b46/raw/addd6abf...
> load: -1.0
> avail. processors: 4
> {code}
> {code}
> mbabacek@localhost:~$ groovy https://gist.githubusercontent.com/Karm/be36292ae52ded419b46/raw/addd6abf...
> load: 0.67
> avail. processors: 4
> {code}
> h3. Call to action
> IMHO, this is a Major user experience failure, the default should provide meaningful values on all major platforms.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5890) Default mod_cluster load metric cpu (AverageSystemLoadMetric) is not supported on Windows
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5890?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-5890:
---------------------------------
Summary: Default mod_cluster load metric cpu (AverageSystemLoadMetric) is not supported on Windows (was: Wildfly10's default mod_cluster load metric cpu (AverageSystemLoadMetric) is not supported on Windows)
> Default mod_cluster load metric cpu (AverageSystemLoadMetric) is not supported on Windows
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-5890
> URL: https://issues.jboss.org/browse/WFLY-5890
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Reporter: Michal Karm Babacek
> Assignee: Radoslav Husar
> Labels: ux
>
> h3. Problem
> Wildfly 10's default load metric changed from *busyness* to *cpu*. Although otherwise fine, this change has a one major drawback: It doesn't work on Windows JDKs: MODCLUSTER-234. This fact has been known and acknowledged since 2011.
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:2.0">
> <mod-cluster-config advertise-socket="modcluster" connector="ajp">
> <dynamic-load-provider>
> <load-metric type="cpu"/>
> </dynamic-load-provider>
> </mod-cluster-config>
> </subsystem>
> {code}
> Instead of a valid Load value, subsystem returns 0 and prints: {{MODCLUSTER000045: AverageSystemLoadMetric is not supported on this system and will be disabled.}}
> h3. Example
> {code}
> C:\Users\Administrator>groovy https://gist.githubusercontent.com/Karm/be36292ae52ded419b46/raw/addd6abf...
> load: -1.0
> avail. processors: 4
> {code}
> {code}
> mbabacek@localhost:~$ groovy https://gist.githubusercontent.com/Karm/be36292ae52ded419b46/raw/addd6abf...
> load: 0.67
> avail. processors: 4
> {code}
> h3. Call to action
> IMHO, this is a Major user experience failure, the default should provide meaningful values on all major platforms.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-2907) Trinidad applications runs fine on JBoss AS 7, but on AS 8 generates error
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2907?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-2907:
-----------------------------------
Issue Type: Bug (was: Feature Request)
Component/s: JSF
> Trinidad applications runs fine on JBoss AS 7, but on AS 8 generates error
> --------------------------------------------------------------------------
>
> Key: WFLY-2907
> URL: https://issues.jboss.org/browse/WFLY-2907
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Environment: Trinidad 2
> Reporter: deepak vohra
>
> A Trinidad 2 UI page generates following exception. Application runs fine on JBoss AS 8.
> {noformat}
> java.lang.NullPointerException
> at com.sun.el.ValueExpressionLiteral.getValue(ValueExpressionLiteral.java:79) [javax.el-3.0-b07.jar:3.0-b07]
> at org.apache.jasper.el.JspValueExpression.getValue(JspValueExpression.java:101) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
> at org.apache.myfaces.trinidad.webapp.UIXComponentELTag.setProperty(UIXComponentELTag.java:109) [trinidad-api-2.0.1.jar:2.0.1]
> at org.apache.myfaces.trinidadinternal.taglib.core.nav.CoreCommandLinkTag.setProperties(CoreCommandLinkTag.java:251) [trinidad-impl-2.0.1.jar:2.0.1]
> at org.apache.myfaces.trinidad.webapp.UIXComponentELTag.setProperties(UIXComponentELTag.java:96) [trinidad-api-2.0.1.jar:2.0.1]
> at javax.faces.webapp.UIComponentELTag.createComponent(UIComponentELTag.java:230) [jboss-jsf-api_2.2_spec-2.2.4.jar:2.2.4]
> at javax.faces.webapp.UIComponentClassicTagBase.createChild(UIComponentClassicTagBase.java:504) [jboss-jsf-api_2.2_spec-2.2.4.jar:2.2.4]
> at javax.faces.webapp.UIComponentClassicTagBase.findComponent(UIComponentClassicTagBase.java:742) [jboss-jsf-api_2.2_spec-2.2.4.jar:2.2.4]
> at javax.faces.webapp.UIComponentClassicTagBase.doStartTag(UIComponentClassicTagBase.java:1309) [jboss-jsf-api_2.2_spec-2.2.4.jar:2.2.4]
> at org.apache.myfaces.trinidad.webapp.UIXComponentELTag.doStartTag(UIXComponentELTag.java:67) [trinidad-api-2.0.1.jar:2.0.1]
> at org.apache.jsp.index_jsp._jspx_meth_tr_005fcommandLink_005f0(index_jsp.java:252)
> at org.apache.jsp.index_jsp._jspx_meth_tr_005fform_005f0(index_jsp.java:208)
> at org.apache.jsp.index_jsp._jspx_meth_tr_005fdocument_005f0(index_jsp.java:161)
> at org.apache.jsp.index_jsp._jspx_meth_f_005fview_005f0(index_jsp.java:118)
> at org.apache.jsp.index_jsp._jspService(index_jsp.java:80)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:366) [jastow-1.0.0.CR1.jar:1.0.0.CR1]
> ... 54 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-1255) ugly style allowing to start multiple servers refer to the same server-config file
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1255?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1255:
------------------------------------------
JEPS 102 (http://openjdk.java.net/jeps/102) may make it feasible to do something meaningful about this (i.e. drop a PID in a file in the data dir and fail boot if there's already such a file and the process with that pid is still alive.)
> ugly style allowing to start multiple servers refer to the same server-config file
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-1255
> URL: https://issues.jboss.org/browse/WFCORE-1255
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Server
> Reporter: Jay Wu
> Assignee: Jason Greene
>
> {color:red}
> WildFly allows to start multiple servers refer to the same server-config as following
> {color}
> {noformat}
> standalone.bat -server-config=standalone.xml -Djboss.node.name=node1
> {noformat}
> {noformat}
> standalone.bat -server-config=standalone.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=node2
> {noformat}
> {noformat}
> standalone.bat -server-config=standalone.xml -Djboss.socket.binding.port-offset=200 -Djboss.node.name=node3
> {noformat}
> {color:red}
> the three nodes do not share the modification， but the later will overwrite the former in the standalone.xml.
> {color}
> {quote}
> for example
> (1) create datasource "ds4node1" to node1 which created above.
> and ds4node1 is written into standalone.xml.
> ↓
> (2) careate datasource "ds4node2" to node2
> and ds4node1 which was created in step(1) is deleted from standalone.xml,
> ds4node2 is written into standalone.xml.
> ↓
> (3) careate datasource "ds4node3" to node3
> and ds4node2 which was created in step(2) is deleted from standalone.xml,
> ds4node3 is written into standalone.xml.
> {quote}
> {color:red}
> after restarting the three nodes, the three nodes refers to standalone.xml, and share the last created datasource "ds4node3"。
> {color}
> {color:red}
> the above style may confuse users.
> if it is a style flaw, is there any plan to improve it.
> {color}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-1255) ugly style allowing to start multiple servers refer to the same server-config file
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1255?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved WFLY-1682 to WFCORE-1255:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1255 (was: WFLY-1682)
Component/s: Server
(was: Server)
Affects Version/s: (was: 8.0.0.Alpha2)
> ugly style allowing to start multiple servers refer to the same server-config file
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-1255
> URL: https://issues.jboss.org/browse/WFCORE-1255
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Server
> Reporter: Jay Wu
> Assignee: Jason Greene
>
> {color:red}
> WildFly allows to start multiple servers refer to the same server-config as following
> {color}
> {noformat}
> standalone.bat -server-config=standalone.xml -Djboss.node.name=node1
> {noformat}
> {noformat}
> standalone.bat -server-config=standalone.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=node2
> {noformat}
> {noformat}
> standalone.bat -server-config=standalone.xml -Djboss.socket.binding.port-offset=200 -Djboss.node.name=node3
> {noformat}
> {color:red}
> the three nodes do not share the modification， but the later will overwrite the former in the standalone.xml.
> {color}
> {quote}
> for example
> (1) create datasource "ds4node1" to node1 which created above.
> and ds4node1 is written into standalone.xml.
> ↓
> (2) careate datasource "ds4node2" to node2
> and ds4node1 which was created in step(1) is deleted from standalone.xml,
> ds4node2 is written into standalone.xml.
> ↓
> (3) careate datasource "ds4node3" to node3
> and ds4node2 which was created in step(2) is deleted from standalone.xml,
> ds4node3 is written into standalone.xml.
> {quote}
> {color:red}
> after restarting the three nodes, the three nodes refers to standalone.xml, and share the last created datasource "ds4node3"。
> {color}
> {color:red}
> the above style may confuse users.
> if it is a style flaw, is there any plan to improve it.
> {color}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months