February 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3655) Improve embedded HC started with empty config state reporting?

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3655?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-3655: ------------------------------------------ [~luck3y] I believe polling for any successful read (e.g. of an attribute on the root resource) would work as a workaround to prevent the race I mentioned. The WFCORE-2579 fix at https://github.com/wildfly/wildfly-core/pull/3124 means any op from the embedded client fails during boot until the process reaches RUNNING state. IOW, simply successfully executing an op provides the same info as reading a particular attribute. > Improve embedded HC started with empty config state reporting? > -------------------------------------------------------------- > > Key: WFCORE-3655 > URL: https://issues.jboss.org/browse/WFCORE-3655 > Project: WildFly Core > Issue Type: Enhancement > Reporter: Ken Wills > Assignee: Ken Wills > Priority: Minor > > This is a discussion ticket, and I'm really only making it to track the discussion at the moment. > Alexey and I had a discussion regarding this, and I thought it would be useful to open this and get other feedback. > Currently, when an embedded host controller is started with an empty config, a partial domain controller start is performed and then paused until the /host=foo:add command is issued. > In the case that the HC is being started programatically it seems desirable to be able to check this step has been completed. > Using the command from the CLI / inside a cli script doesn't have this problem as the CLI waits for the response before continuuing. > Some clients poll on the /host=foo:host-status attribute, this isn't present until a host has been actually added though. > the existing options are: > (a) Like the CLI, just wait until the operation completes. I think this should currently always work. > (b) Poll on the existence of the /host resource. If this is registered, then you can safely try to add your host (after all there may already be one.) > Since the host hasn't been added, it doesn't make a lot of sense to provided a default status, as theres no /host=foo to hold the attribute. > Other thoughts? Personally I'm a fan of (a). And I think that should always be sufficient. I'm not really sure what the programmatic expectations are for using ops like this are in general. Is behavior always assumed to be synchronous, so the end client doesn't need to poll or wait etc? > [~aloubyansky] Feel free to comment and correct me if I was inaccurate about something. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2354) Simplify NetworkNodes equality and index nodes in CompositeSink

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2354?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-2354. --------------------------------- Resolution: Done Fixed by https://github.com/kiegroup/drools/commit/22f96ce8356f9f4b79bd8f431da98cb... > Simplify NetworkNodes equality and index nodes in CompositeSink > --------------------------------------------------------------- > > Key: DROOLS-2354 > URL: https://issues.jboss.org/browse/DROOLS-2354 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2354) Simplify NetworkNodes equality and index nodes in CompositeSink

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-2354: ----------------------------------- Summary: Simplify NetworkNodes equality and index nodes in CompositeSink Key: DROOLS-2354 URL: https://issues.jboss.org/browse/DROOLS-2354 Project: Drools Issue Type: Enhancement Components: core engine Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-44) Create a test for Service detail component

by viet nguyen (JIRA)

viet nguyen created SWSQE-44: -------------------------------- Summary: Create a test for Service detail component Key: SWSQE-44 URL: https://issues.jboss.org/browse/SWSQE-44 Project: Swift Sunshine QE Issue Type: Sub-task Reporter: viet nguyen Assignee: viet nguyen also need to to mock API service -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-43) Create tests in SWSUI repo

by viet nguyen (JIRA)

[ https://issues.jboss.org/browse/SWSQE-43?page=com.atlassian.jira.plugin.s... ] viet nguyen resolved SWSQE-43. ------------------------------ Resolution: Done > Create tests in SWSUI repo > -------------------------- > > Key: SWSQE-43 > URL: https://issues.jboss.org/browse/SWSQE-43 > Project: Swift Sunshine QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > Attachments: coveralls.png > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-43) Create tests in SWSUI repo

by viet nguyen (JIRA)

[ https://issues.jboss.org/browse/SWSQE-43?page=com.atlassian.jira.plugin.s... ] viet nguyen updated SWSQE-43: ----------------------------- Attachment: coveralls.png > Create tests in SWSUI repo > -------------------------- > > Key: SWSQE-43 > URL: https://issues.jboss.org/browse/SWSQE-43 > Project: Swift Sunshine QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > Attachments: coveralls.png > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9913) Balancer fails to balance requests according to load provided by custom load metric

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9913?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on WFLY-9913: -------------------------------------- [~jkasik] How does the native implementation behave? > 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. > This occurs only on EAP/Wildlfly balancer and we suspect, that this is an error in Undertow mod_cluster implementation. The problem is, that sometimes more requests than expected ends up on the worker with lowest load: > {{java.lang.AssertionError: Assert #5, Request distribution according to the load was supposed to be [jboss-eap-7.2-1:106, jboss-eap-7.2-2:106, jboss-eap-7.2-3:789] with tolerance +/-10, but was: [jboss-eap-7.2-1:36, jboss-eap-7.2-2:35, jboss-eap-7.2-3:930]}} > [1]: https://github.com/Karm/mod_cluster-custom-load-metric -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-43) Create tests in SWSUI repo

by viet nguyen (JIRA)

[ https://issues.jboss.org/browse/SWSQE-43?page=com.atlassian.jira.plugin.s... ] viet nguyen edited comment on SWSQE-43 at 2/27/18 11:04 AM: ------------------------------------------------------------ contributing tests to SWSUI repo while waiting for SWS-115. PR: https://github.com/swift-sunshine/swsui/pull/53 was (Author: vietn): contributing tests to SWSUI repo while waiting for SWS-115. > Create tests in SWSUI repo > -------------------------- > > Key: SWSQE-43 > URL: https://issues.jboss.org/browse/SWSQE-43 > Project: Swift Sunshine QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9926) JBoss Metadata upgrade added a new schema which requires a hard-coded change in AbstractValidationUnitTest

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-9926?page=com.atlassian.jira.plugin.... ] James Perkins updated WFLY-9926: -------------------------------- Steps to Reproduce: Build WildFly and run the `StandardConfigsXMLValidationUnitTestCase` in the {{testsuite/integration/smoke}} directory against the distribution in the dist directory. {code} mvn clean install -DskipTests && mvn test -Dtest=StandardConfigsXMLValidationUnitTestCase -Djboss.dist=../../../dist/target/wildfly-12.0.0.Final-SNAPSHOT -pl testsuite/integration/smoke/ {code} > JBoss Metadata upgrade added a new schema which requires a hard-coded change in AbstractValidationUnitTest > ---------------------------------------------------------------------------------------------------------- > > Key: WFLY-9926 > URL: https://issues.jboss.org/browse/WFLY-9926 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: James Perkins > Assignee: James Perkins > Fix For: 12.0.0.Final > > > The {{AbstractValidationUnitTest}} test case hard-codes the {{jboss-common_6_0.xsd}} schema for validation. The new schema is {{jboss-common_7_0.xsd}} in JBoss Metadata. The test just needs to be updated to use the new version -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3652) insufficient privileges with security manager causes tests to fail

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3652?page=com.atlassian.jira.plugi... ] Scott Marlow closed WFCORE-3652. -------------------------------- Our tests are now passing, thanks David! I'll close this. > 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, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2018