[JBoss JIRA] (WFLY-9913) Balancer fails to balance requests according to load provided by custom load metric
by Jan Kašík (JIRA)
[ https://issues.jboss.org/browse/WFLY-9913?page=com.atlassian.jira.plugin.... ]
Jan Kašík updated WFLY-9913:
----------------------------
Affects Version/s: 12.0.0.Beta1
> Balancer fails to balance requests according to load provided by custom load metric
> -----------------------------------------------------------------------------------
>
> Key: WFLY-9913
> URL: https://issues.jboss.org/browse/WFLY-9913
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster, Web (Undertow)
> Affects Versions: 12.0.0.Beta1
> Reporter: Jan Kašík
> Assignee: Radoslav Husar
>
> When balancer uses load provided by custom load metric, it intermittently fails to redirect requests to expected workers. We use following scenario in our test with EAP 7.1.1 nodes:
> # Prepare one balancer and three workers with custom load metric which has these attribute values:
> {{history: 0, decay: 0, capacity: 1000}} and uses implementation from \[1\].
> # The implementation takes dummy load values from files in local filesystem. So the values in files are set then.
> # The verification, that expected load factor is loaded is made by running {{"/subsystem=undertow/configuration=filter/mod-cluster=modcluster:read-resource(include-runtime=true, recursive=true, recursive-depth=100)}}.
> # 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
> # It is verified, that expected amount of request went to each node according to load factor.
> # Load values in files are changes and verification, that they were loaded is made again.
> # 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
> # After the requests were made, the verification, that all went according to expectations is made. In this step, the verification sometimes fails, because there were unexpected count of requests on each node.
> [1]: https://github.com/Karm/mod_cluster-custom-load-metric
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9854) jgroups-channel cannot use name which is already used by jgroups/stacks
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-9854?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-9854:
------------------------------------
[~eduda] +1 for addressing this in documentation.
> jgroups-channel cannot use name which is already used by jgroups/stacks
> -----------------------------------------------------------------------
>
> Key: WFLY-9854
> URL: https://issues.jboss.org/browse/WFLY-9854
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, JMS
> Affects Versions: 12.0.0.Beta1
> Reporter: Erich Duda
> Assignee: Paul Ferraro
> Priority: Blocker
>
> The configuration \[1\] results to an error \[2\]. This is backward compatibility issue since the configuration works with previous releases of Wildfly.
> \[1\]
> {code:xml}
> <broadcast-group name="bg-group1" jgroups-stack="udp" jgroups-channel="udp" broadcast-period="2000" connectors="connector"/>
> {code}
> \[2\]
> {code}
> 10:52:29,982 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 15) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "jgroups"),
> ("channel" => "udp")
> ]) - failure description: "WFLYCTL0436: Cannot register capability 'org.wildfly.clustering.jgroups.channel-factory.udp' at location '[
> (\"subsystem\" => \"jgroups\"),
> (\"channel\" => \"udp\")
> ]' as it is already registered in context 'global' at location(s) '[[
> (\"subsystem\" => \"jgroups\"),
> (\"stack\" => \"udp\")
> ]]'"
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9913) Balancer fails to balance requests according to load provided by custom load metric
by Jan Kašík (JIRA)
[ https://issues.jboss.org/browse/WFLY-9913?page=com.atlassian.jira.plugin.... ]
Jan Kašík updated WFLY-9913:
----------------------------
Description:
When balancer uses load provided by custom load metric, it intermittently fails to redirect requests to expected workers. We use following scenario in our test with EAP 7.1.1 nodes:
# Prepare one balancer and three workers with custom load metric which has these attribute values:
{{history: 0, decay: 0, capacity: 1000}} and uses implementation from \[1\].
# The implementation takes dummy load values from files in local filesystem. So the values in files are set then.
# The verification, that expected load factor is loaded is made by running {{"/subsystem=undertow/configuration=filter/mod-cluster=modcluster:read-resource(include-runtime=true, recursive=true, recursive-depth=100)}}.
# 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
# It is verified, that expected amount of request went to each node according to load factor.
# Load values in files are changes and verification, that they were loaded is made again.
# 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
# After the requests were made, the verification, that all went according to expectations is made. In this step, the verification sometimes fails, because there were unexpected count of requests on each node.
[1]: https://github.com/Karm/mod_cluster-custom-load-metric
was:
When balancer uses load provided by custom load metric, it intermittently fails to redirect requests to expected workers. We use following scenario in our test with EAP 7.1.1 nodes:
# Prepare one balancer and three workers with custom load metric which has these attribute values:
{{history: 0, decay: 0, capacity: 1000}} and uses implementation from \[1\].
# The implementation takes dummy load values from files in local filesystem. So the values in files are set then.
# The verification, that expected load factor is loaded is made by running {{"/subsystem=undertow/configuration=filter/mod-cluster=modcluster:read-resource(include-runtime=true, recursive=true, recursive-depth=100)}}.
# 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
# It is verified, that expected amount of request went to each node according to load factor.
# Load values in files are changes and varification, that they were loaded is made again.
# 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
# After the requests were made, the verification, that all went according to expectations is made. In this step, the verification sometimes fails, because there were unexpected count of requests on each node.
[1]: https://github.com/Karm/mod_cluster-custom-load-metric
> Balancer fails to balance requests according to load provided by custom load metric
> -----------------------------------------------------------------------------------
>
> Key: WFLY-9913
> URL: https://issues.jboss.org/browse/WFLY-9913
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster, Web (Undertow)
> Reporter: Jan Kašík
> Assignee: Radoslav Husar
>
> When balancer uses load provided by custom load metric, it intermittently fails to redirect requests to expected workers. We use following scenario in our test with EAP 7.1.1 nodes:
> # Prepare one balancer and three workers with custom load metric which has these attribute values:
> {{history: 0, decay: 0, capacity: 1000}} and uses implementation from \[1\].
> # The implementation takes dummy load values from files in local filesystem. So the values in files are set then.
> # The verification, that expected load factor is loaded is made by running {{"/subsystem=undertow/configuration=filter/mod-cluster=modcluster:read-resource(include-runtime=true, recursive=true, recursive-depth=100)}}.
> # 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
> # It is verified, that expected amount of request went to each node according to load factor.
> # Load values in files are changes and verification, that they were loaded is made again.
> # 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
> # After the requests were made, the verification, that all went according to expectations is made. In this step, the verification sometimes fails, because there were unexpected count of requests on each node.
> [1]: https://github.com/Karm/mod_cluster-custom-load-metric
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9913) Balancer fails to balance requests according to load provided by custom load metric
by Jan Kašík (JIRA)
[ https://issues.jboss.org/browse/WFLY-9913?page=com.atlassian.jira.plugin.... ]
Jan Kašík updated WFLY-9913:
----------------------------
Description:
When balancer uses load provided by custom load metric, it intermittently fails to redirect requests to expected workers. We use following scenario in our test with EAP 7.1.1 nodes:
# Prepare one balancer and three workers with custom load metric which has these attribute values:
{{history: 0, decay: 0, capacity: 1000}} and uses implementation from \[1\].
# The implementation takes dummy load values from files in local filesystem. So the values in files are set then.
# The verification, that expected load factor is loaded is made by running {{"/subsystem=undertow/configuration=filter/mod-cluster=modcluster:read-resource(include-runtime=true, recursive=true, recursive-depth=100)}}.
# 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
# It is verified, that expected amount of request went to each node according to load factor.
# Load values in files are changes and varification, that they were loaded is made again.
# 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
# After the requests were made, the verification, that all went according to expectations is made. In this step, the verification sometimes fails, because there were unexpected count of requests on each node.
[1]: https://github.com/Karm/mod_cluster-custom-load-metric
was:
When balancer uses load provided by custom load metric, it intermittently fails to redirect requests to expected workers. We use following scenario in our test:
# Prepare one balancer and three workers with custom load metric which has these attribute values:
{{history: 0, decay: 0, capacity: 1000}} and uses implementation from \[1\].
# The implementation takes dummy load values from files in local filesystem. So the values in files are set then.
# The verification, that expected load factor is loaded is made by running {{"/subsystem=undertow/configuration=filter/mod-cluster=modcluster:read-resource(include-runtime=true, recursive=true, recursive-depth=100)}}.
# 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
# It is verified, that expected amount of request went to each node according to load factor.
# Load values in files are changes and varification, that they were loaded is made again.
# 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
# After the requests were made, the verification, that all went according to expectations is made. In this step, the verification sometimes fails, because there were unexpected count of requests on each node.
[1]: https://github.com/Karm/mod_cluster-custom-load-metric
> Balancer fails to balance requests according to load provided by custom load metric
> -----------------------------------------------------------------------------------
>
> Key: WFLY-9913
> URL: https://issues.jboss.org/browse/WFLY-9913
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster, Web (Undertow)
> Reporter: Jan Kašík
> Assignee: Radoslav Husar
>
> When balancer uses load provided by custom load metric, it intermittently fails to redirect requests to expected workers. We use following scenario in our test with EAP 7.1.1 nodes:
> # Prepare one balancer and three workers with custom load metric which has these attribute values:
> {{history: 0, decay: 0, capacity: 1000}} and uses implementation from \[1\].
> # The implementation takes dummy load values from files in local filesystem. So the values in files are set then.
> # The verification, that expected load factor is loaded is made by running {{"/subsystem=undertow/configuration=filter/mod-cluster=modcluster:read-resource(include-runtime=true, recursive=true, recursive-depth=100)}}.
> # 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
> # It is verified, that expected amount of request went to each node according to load factor.
> # Load values in files are changes and varification, that they were loaded is made again.
> # 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
> # After the requests were made, the verification, that all went according to expectations is made. In this step, the verification sometimes fails, because there were unexpected count of requests on each node.
> [1]: https://github.com/Karm/mod_cluster-custom-load-metric
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9913) Balancer fails to balance requests according to load provided by custom load metric
by Jan Kašík (JIRA)
[ https://issues.jboss.org/browse/WFLY-9913?page=com.atlassian.jira.plugin.... ]
Jan Kašík updated WFLY-9913:
----------------------------
Affects Version/s: (was: 12.0.0.Beta1)
> Balancer fails to balance requests according to load provided by custom load metric
> -----------------------------------------------------------------------------------
>
> Key: WFLY-9913
> URL: https://issues.jboss.org/browse/WFLY-9913
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster, Web (Undertow)
> Reporter: Jan Kašík
> Assignee: Radoslav Husar
>
> When balancer uses load provided by custom load metric, it intermittently fails to redirect requests to expected workers. We use following scenario in our test:
> # Prepare one balancer and three workers with custom load metric which has these attribute values:
> {{history: 0, decay: 0, capacity: 1000}} and uses implementation from \[1\].
> # The implementation takes dummy load values from files in local filesystem. So the values in files are set then.
> # The verification, that expected load factor is loaded is made by running {{"/subsystem=undertow/configuration=filter/mod-cluster=modcluster:read-resource(include-runtime=true, recursive=true, recursive-depth=100)}}.
> # 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
> # It is verified, that expected amount of request went to each node according to load factor.
> # Load values in files are changes and varification, that they were loaded is made again.
> # 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
> # After the requests were made, the verification, that all went according to expectations is made. In this step, the verification sometimes fails, because there were unexpected count of requests on each node.
> [1]: https://github.com/Karm/mod_cluster-custom-load-metric
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9913) Balancer fails to balance requests according to load provided by custom load metric
by Jan Kašík (JIRA)
Jan Kašík created WFLY-9913:
-------------------------------
Summary: Balancer fails to balance requests according to load provided by custom load metric
Key: WFLY-9913
URL: https://issues.jboss.org/browse/WFLY-9913
Project: WildFly
Issue Type: Bug
Components: mod_cluster, Web (Undertow)
Affects Versions: 12.0.0.Beta1
Reporter: Jan Kašík
Assignee: Radoslav Husar
When balancer uses load provided by custom load metric, it intermittently fails to redirect requests to expected workers. We use following scenario in our test:
# Prepare one balancer and three workers with custom load metric which has these attribute values:
{{history: 0, decay: 0, capacity: 1000}} and uses implementation from \[1\].
# The implementation takes dummy load values from files in local filesystem. So the values in files are set then.
# The verification, that expected load factor is loaded is made by running {{"/subsystem=undertow/configuration=filter/mod-cluster=modcluster:read-resource(include-runtime=true, recursive=true, recursive-depth=100)}}.
# 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
# It is verified, that expected amount of request went to each node according to load factor.
# Load values in files are changes and varification, that they were loaded is made again.
# 1000+ requests is made on balancer and for each request, the JVM route of handling node is noted.
# After the requests were made, the verification, that all went according to expectations is made. In this step, the verification sometimes fails, because there were unexpected count of requests on each node.
[1]: https://github.com/Karm/mod_cluster-custom-load-metric
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFCORE-695) OutOfMemoryErrors when adding large deployment with audit logging enabled
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-695?page=com.atlassian.jira.plugin... ]
Jean-Francois Denise commented on WFCORE-695:
---------------------------------------------
This problem has been fixed by this refactoring of deploy command.
> OutOfMemoryErrors when adding large deployment with audit logging enabled
> -------------------------------------------------------------------------
>
> Key: WFCORE-695
> URL: https://issues.jboss.org/browse/WFCORE-695
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Affects Versions: 1.0.0.CR4
> Reporter: James Livingston
> Assignee: Jean-Francois Denise
>
> When performing a deployment operation, audit logging will include the deployment content in the audit record (serialised as text). Since JsonAuditLogItemFormatter.createRecordText() creates the string in memory, large deployment will lead to an OutOfMemoryError such as
> java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:2367) [rt.jar:1.7.0_71]
> at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:130) [rt.jar:1.7.0_71]
> at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:114) [rt.jar:1.7.0_71]
> at java.lang.AbstractStringBuilder.appendCodePoint(AbstractStringBuilder.java:730) [rt.jar:1.7.0_71]
> at java.lang.StringBuilder.appendCodePoint(StringBuilder.java:242) [rt.jar:1.7.0_71]
> at org.jboss.dmr.ModelValue.jsonEscape(ModelValue.java:212) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.BytesModelValue.formatAsJSON(BytesModelValue.java:144) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ListModelValue.formatAsJSON(ListModelValue.java:251) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.formatAsJSON(ModelNode.java:1520) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ObjectModelValue.formatAsJSON(ObjectModelValue.java:247) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelValue.writeJSONString(ModelValue.java:351) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelValue.toJSONString(ModelValue.java:340) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.dmr.ModelNode.toJSONString(ModelNode.java:1350) [jboss-dmr-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.as.controller.audit.JsonAuditLogItemFormatter.createRecordText(JsonAuditLogItemFormatter.java:135) [jboss-as-controller-7.4.2.Final-redhat-2.jar:7.4.2.Final-redhat-2]
> A work-around is increasing the controller heap size, but it would be good if that was not required. If including the deployment content in the record is desired, perhaps there is a way to make it stream the record rather than building the entire string in memory at once.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFCORE-3652) insufficient privileges with security manager causes tests to fail
by Scott Marlow (JIRA)
Scott Marlow created WFCORE-3652:
------------------------------------
Summary: insufficient privileges with security manager causes tests to fail
Key: WFCORE-3652
URL: https://issues.jboss.org/browse/WFCORE-3652
Project: WildFly Core
Issue Type: Task
Components: Remoting
Reporter: Scott Marlow
Assignee: David Lloyd
Fix For: 4.0.0.CR1
Please address below failure that we get during testing:
{code}
Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessDeclaredMembers")" in code source "(vfs:/content/ejb3_sec_permsxml.ear/ejb3_sec_permsxml_client.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.ejb3_sec_permsxml.ear.ejb3_sec_permsxml_client.jar" from Service Module Loader")
\u001b[0m\u001b[0m11:18:48,855 INFO [stdout] (Thread-189) at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:295)
\u001b[0m\u001b[0m11:18:48,855 INFO [stdout] (Thread-189) at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:192)
\u001b[0m\u001b[0m11:18:48,855 INFO [stdout] (Thread-189) at java.lang.Class.checkMemberAccess(Class.java:2348)
\u001b[0m\u001b[0m11:18:48,856 INFO [stdout] (Thread-189) at java.lang.Class.getDeclaredField(Class.java:2067)
\u001b[0m\u001b[0m11:18:48,856 INFO [stdout] (Thread-189) at org.jboss.marshalling.river.RiverUnmarshaller.<clinit>(RiverUnmarshaller.java:106)
\u001b[0m\u001b[0m11:18:48,856 INFO [stdout] (Thread-189) ... 40 more
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months