October 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3311) embedded server --std-out=discard still causes log output to be shown

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3311?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3311: ------------------------------------- Comment: was deleted (was: Reopening in case there was more work planned.) > embedded server --std-out=discard still causes log output to be shown > --------------------------------------------------------------------- > > Key: WFCORE-3311 > URL: https://issues.jboss.org/browse/WFCORE-3311 > Project: WildFly Core > Issue Type: Bug > Reporter: Ken Wills > Assignee: James Perkins > Fix For: 4.0.0.Alpha1 > > > [disconnected /] embed-server --std-out=discard > 10:27:43,671 INFO [org.jboss.modules] (CLI command executor) JBoss Modules version 1.6.1.Final > 10:27:43,698 INFO [org.jboss.as] (MSC service thread 2-8) WFLYSRV0049: WildFly Core 4.0.0.Alpha1-SNAPSHOT "Kenny" starting > ... etc -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2235) Intermittent module loading failure in InterdependentDeploymentTestCase

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2235?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-2235: ---------------------------------------- Assignee: Richard Opalka [~ropalka] I'm assigning this to you since per our chats you've got this fixed in MSC and an MSC upgrade will take care of it. When the upgrade comes in https://github.com/wildfly/wildfly-core/pull/2871 should be reverted. That PR was an alternative to putting @Ignore on the test, one that should make the failures with the current code rare without completely losing coverage. > Intermittent module loading failure in InterdependentDeploymentTestCase > ----------------------------------------------------------------------- > > Key: WFCORE-2235 > URL: https://issues.jboss.org/browse/WFCORE-2235 > Project: WildFly Core > Issue Type: Bug > Components: Modules, Server > Affects Versions: 3.0.0.Alpha22 > Reporter: Brian Stansberry > Assignee: Richard Opalka > Attachments: WFCORE-2235svcdump.txt > > > InterdependentDeploymentTestCase tests deployment handling of a set of interdependent deployments, where some of the dependencies are optional. > The test intermittently fails due to a ModuleLoadException while deploying one of the modules: > https://ci.wildfly.org/viewLog.html?buildId=42957&buildTypeId=WildFlyCore... > The most notable bit of info in the log is: > {code} > 17:32:08,639 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.module.service."deployment.interrelated-c.jar".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.interrelated-c.jar".main: WFLYSRV0179: Failed to load module: deployment.interrelated-c.jar > at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at org.jboss.msc.service.MSCExecutor$1.run(MSCExecutor.java:77) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.jboss.modules.ModuleNotFoundException: deployment.interrelated-c.jar > at org.jboss.modules.ModuleLoader$FutureModule.getModule(ModuleLoader.java:834) > at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:472) > at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:457) > at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:370) > at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:147) > at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:387) > at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:282) > at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:270) > at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:68) > ... 6 more > {code} > The interrelated-c.jar deployment depends (*not optionally*) on interrelated-a.jar.The failure occurs during execution of a management op that redeploys interrelated-a.jar. FWIW, another deployment in the set, interrelated-f.jar, does depend optionally on interrelated-c.jar. > The full stdout output for the failed test in the above linked CI run also includes a dump of all MSC services following the failure. Note though that the failure does not result in MSC not obtaining stability. Inability to reach stability was the initial problem that led to the introduction of this test (see https://github.com/wildfly/wildfly-core/pull/2099.) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3335) Allow read-resource users to specify that attrbutes should be organized by attribute group

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3335: ---------------------------------------- Summary: Allow read-resource users to specify that attrbutes should be organized by attribute group Key: WFCORE-3335 URL: https://issues.jboss.org/browse/WFCORE-3335 Project: WildFly Core Issue Type: Feature Request Components: Domain Management Reporter: Brian Stansberry Priority: Minor Currently the read-resource output reports all attributes in a flat list, so the relationship between any attributes that are in an attribute-group is lost.[1] But, the output of read-resource an already be customized in various ways via operations parameters, so I see no reason we couldn't add a param to customize the representation of attributes. An 'attributes-by-group' param could be used to trigger moving away from the flat list. Ungrouped attributes would appear first, followed by the groups. Then there is a node named "attribute-group", the children of which are the group names, and the children of each group name are its attributes. This somewhat makes the term "attribute-group" a reserved word. To help mitigate that, if any ungrouped attribute or resource child type is named "attribute-group" (unlikely but possible), then the attributes for that resource will not be reported in grouped manner the response includes a warning header stating this. A transformer would need to be used with mixed domain. I think it would have to reject the op (or perhaps add a response warning header), as I don't see how we could reliably transform an unsorted response from a slave that didn't understand this param. The DC would not have reliable information to know what the groups are on the slave (which may have a different model than the DC.) THE VERY FIRST STEP ON THIS MUST BE SORTING OUT THE MIXED DOMAIN QUESTION. If we can't sort that in an acceptable manner, we won't implement this. Conceptually the same kind of thing could be applied to read-resource-description, but that is *not* in the scope of this RFE. The r-r-d already reports the attribute-group info for each attribute, so the value is less, while including r-r-d would basically be doubling the amount of work involved. [1] I believe the sorting of the flat list is currently by group, but since the group names are not shown that representation is not visually clear, and there's a JIRA to fix the resulting confusing output by always sorting alphabetically. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9420) Cluster partitions can take up to cca 2 minutes to merge

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9420?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-9420: --------------------------------- Summary: Cluster partitions can take up to cca 2 minutes to merge (was: Cluster partitions can take cca 2 minutes to merge) > Cluster partitions can take up to cca 2 minutes to merge > -------------------------------------------------------- > > Key: WFLY-9420 > URL: https://issues.jboss.org/browse/WFLY-9420 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 11.0.0.CR1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Labels: partition_handling > > Using the {{MERGE3}} protocol, it can take significantly longer than {{max_interval}} for merge to happen. > The info sender interval is up to 45 seconds > {code:java} > public long nextInterval() { > return Math.max(min_interval, Util.random(max_interval) + max_interval/2); > } > {code} > and the view consistency checker interval is 48 seconds > {code:java} > protected long computeCheckInterval() { > return (long)(max_interval * 1.6); > } > {code} > which depending on the timing can take significant amount of time. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9420) Cluster partitions can take cca 2 minutes to merge

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9420?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-9420: --------------------------------- Summary: Cluster partitions can take cca 2 minutes to merge (was: Cluster partitions can take up to 2 minutes to merge) > Cluster partitions can take cca 2 minutes to merge > -------------------------------------------------- > > Key: WFLY-9420 > URL: https://issues.jboss.org/browse/WFLY-9420 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 11.0.0.CR1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Labels: partition_handling > > Using the {{MERGE3}} protocol, it can take significantly longer than {{max_interval}} for merge to happen. > The info sender interval is up to 45 seconds > {code:java} > public long nextInterval() { > return Math.max(min_interval, Util.random(max_interval) + max_interval/2); > } > {code} > and the view consistency checker interval is 48 seconds > {code:java} > protected long computeCheckInterval() { > return (long)(max_interval * 1.6); > } > {code} > which depending on the timing can take significant amount of time. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3311) embedded server --std-out=discard still causes log output to be shown

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3311?page=com.atlassian.jira.plugi... ] Brian Stansberry reopened WFCORE-3311: -------------------------------------- Reopening in case there was more work wanted. > embedded server --std-out=discard still causes log output to be shown > --------------------------------------------------------------------- > > Key: WFCORE-3311 > URL: https://issues.jboss.org/browse/WFCORE-3311 > Project: WildFly Core > Issue Type: Bug > Reporter: Ken Wills > Assignee: James Perkins > Fix For: 4.0.0.Alpha1 > > > [disconnected /] embed-server --std-out=discard > 10:27:43,671 INFO [org.jboss.modules] (CLI command executor) JBoss Modules version 1.6.1.Final > 10:27:43,698 INFO [org.jboss.as] (MSC service thread 2-8) WFLYSRV0049: WildFly Core 4.0.0.Alpha1-SNAPSHOT "Kenny" starting > ... etc -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3311) embedded server --std-out=discard still causes log output to be shown

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3311?page=com.atlassian.jira.plugi... ] Brian Stansberry edited comment on WFCORE-3311 at 10/5/17 11:28 AM: -------------------------------------------------------------------- Reopening in case there was more work planned. was (Author: brian.stansberry): Reopening in case there was more work wanted. > embedded server --std-out=discard still causes log output to be shown > --------------------------------------------------------------------- > > Key: WFCORE-3311 > URL: https://issues.jboss.org/browse/WFCORE-3311 > Project: WildFly Core > Issue Type: Bug > Reporter: Ken Wills > Assignee: James Perkins > Fix For: 4.0.0.Alpha1 > > > [disconnected /] embed-server --std-out=discard > 10:27:43,671 INFO [org.jboss.modules] (CLI command executor) JBoss Modules version 1.6.1.Final > 10:27:43,698 INFO [org.jboss.as] (MSC service thread 2-8) WFLYSRV0049: WildFly Core 4.0.0.Alpha1-SNAPSHOT "Kenny" starting > ... etc -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3311) embedded server --std-out=discard still causes log output to be shown

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3311?page=com.atlassian.jira.plugi... ] Brian Stansberry resolved WFCORE-3311. -------------------------------------- Fix Version/s: 4.0.0.Alpha1 Resolution: Done [~jamezp] I assumed this could be resolved with the logging upgrade. > embedded server --std-out=discard still causes log output to be shown > --------------------------------------------------------------------- > > Key: WFCORE-3311 > URL: https://issues.jboss.org/browse/WFCORE-3311 > Project: WildFly Core > Issue Type: Bug > Reporter: Ken Wills > Assignee: James Perkins > Fix For: 4.0.0.Alpha1 > > > [disconnected /] embed-server --std-out=discard > 10:27:43,671 INFO [org.jboss.modules] (CLI command executor) JBoss Modules version 1.6.1.Final > 10:27:43,698 INFO [org.jboss.as] (MSC service thread 2-8) WFLYSRV0049: WildFly Core 4.0.0.Alpha1-SNAPSHOT "Kenny" starting > ... etc -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9420) Partitions can take up to 2 minutes to merge

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9420?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-9420: --------------------------------- Description: Using the {{MERGE3}} protocol, it can take significantly longer than {{max_interval}} for merge to happen. The info sender interval is up to 45 seconds {code:java} public long nextInterval() { return Math.max(min_interval, Util.random(max_interval) + max_interval/2); } {code} and the view consistency checker interval is 48 seconds {code:java} protected long computeCheckInterval() { return (long)(max_interval * 1.6); } {code} which depending on the timing can take significant amount of time. was: Using the {{MERGE3}} protocol, it can take significantly longer than {{max_interval}} for merge to happen. The info sender interval is up to 45 seconds {code} public long nextInterval() { return Math.max(min_interval, Util.random(max_interval) + max_interval/2); } {code} and the view consistency checker interval is 48 seconds {code} protected long computeCheckInterval() { return (long)(max_interval * 1.6); } {code} which depending on the timing can take significant amount of time. > Partitions can take up to 2 minutes to merge > -------------------------------------------- > > Key: WFLY-9420 > URL: https://issues.jboss.org/browse/WFLY-9420 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 11.0.0.CR1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Labels: partition_handling > > Using the {{MERGE3}} protocol, it can take significantly longer than {{max_interval}} for merge to happen. > The info sender interval is up to 45 seconds > {code:java} > public long nextInterval() { > return Math.max(min_interval, Util.random(max_interval) + max_interval/2); > } > {code} > and the view consistency checker interval is 48 seconds > {code:java} > protected long computeCheckInterval() { > return (long)(max_interval * 1.6); > } > {code} > which depending on the timing can take significant amount of time. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9420) Cluster partitions can take up to 2 minutes to merge

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9420?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-9420: --------------------------------- Summary: Cluster partitions can take up to 2 minutes to merge (was: Partitions can take up to 2 minutes to merge) > Cluster partitions can take up to 2 minutes to merge > ---------------------------------------------------- > > Key: WFLY-9420 > URL: https://issues.jboss.org/browse/WFLY-9420 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 11.0.0.CR1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Labels: partition_handling > > Using the {{MERGE3}} protocol, it can take significantly longer than {{max_interval}} for merge to happen. > The info sender interval is up to 45 seconds > {code:java} > public long nextInterval() { > return Math.max(min_interval, Util.random(max_interval) + max_interval/2); > } > {code} > and the view consistency checker interval is 48 seconds > {code:java} > protected long computeCheckInterval() { > return (long)(max_interval * 1.6); > } > {code} > which depending on the timing can take significant amount of time. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2017