October 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12624) Return hostname instead of IP address when generating default client mapping

by Richard Achmatowicz (Jira)

[ https://issues.jboss.org/browse/WFLY-12624?page=com.atlassian.jira.plugin... ] Richard Achmatowicz edited comment on WFLY-12624 at 10/8/19 10:52 AM: ---------------------------------------------------------------------- At present, the default client mapping returns 127.0.0.1/::1 rather than the hostname "localhost". The proposal here is to change this to return the hostname instead, avoiding the issue for the default case. This doesn't prevent a user from configuring IP addresses in user-specified client mappings. I believe it would also be advisable to generate a warning when a user creates a server configuration which uses client mappings which make use of IP addresses instead of hostnames for the destination-address: {noformat} <socket-binding name="remoting" port="1099"> <client-mapping destination-address="192.168.2.1" destination-port="1099" source-network="192.168.1.1/16"/> </socket-binding> {noformat} This will result in the EJB client receiving client mappings containing IP addresses, which is a root cause of the issue https://issues.jboss.org/browse/EJBCLIENT-349 was (Author: rachmato): At present, the default client mapping returns 127.0.0.1/::1 rather than the hostname "localhost". The proposal here is to change this to return the hostname instead, avoiding the issue for the default case. This doesn't prevent a user from configuring IP addresses in user-specified client mappings. > Return hostname instead of IP address when generating default client mapping > ----------------------------------------------------------------------------- > > Key: WFLY-12624 > URL: https://issues.jboss.org/browse/WFLY-12624 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 18.0.0.Beta1 > Environment: An EJB client application interacting with a cluster of Wildfly server nodes > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Priority: Major > > When an EJB client application interacts with a clustered Wildfly deployment, it receives topology updates from cluster nodes describing the membership of the cluster. > For each node in the cluster, a set of one or more client mappings is provided to indicate how the client may connect to the node, if it hasn't already. If the node is connected to a single network, there will be one client mapping; if the node is multi-homed and connected to two networks, there will be two client mappings, etc. Client mappings specify three things: a CIDR representation of the network the client may be on, a destination hostname or IP address and a destination port. > Client mappings may be generated by default (if none are provided in the server profile) or may be specified by the user via client mappings defined in the socket binding of the Remoting connector. For example: > {noformat} > <socket-binding name="remoting" port="1099"> > <client-mapping source-network="135.121.1.29/16" destination-address="135.121.1.29" destination-port="1099"/> > </socketbinding> > {noformat} > When the client mapping information is received by the EJB client application, it is added to the discovered node registry (DNR) in the Discovery component of the EJB client. The DNR represents all known information about nodes with which the client can interact which was received from nodes in one or more clusters. > When an invocation is attempted, the Discovery component uses this information to generate a set of ServiceURLs which represent candidate targets (i.e. servers containing the deployment and module the client is invoking on) for the invocation. The Discovery component uses "an algorithm" to take the information in the DNR (and other places) and convert that information to a corresponding set of ServiceURLs representing available targets. The Discovery component will then select one such ServiceURL and return this as the target for the invocation. > Discovery obtains node information used in the algorithm from various sources: client mappings associated with cluster nodes, as described above, as well as Remoting endpoints associated with established connections to nodes. These pieces of information describe at a minimum a host and a port. > The problem is that "the algorithm" used in Discovery to compute the set of ServiceURLs treats hostnames and IP addresses as simple strings. So "localhost" and "127.0.0.1" are treated as different hosts, even though they refer to the same host. If a mix of hostnames and IP addresses for the same node is received, this results in an incomplete/incorrect set of ServiceURLs being generated which in turn leads to incorrect Discovery failures. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-234) oc scale wildflyserver throws Permissions error with regular user

by Petr Kremensky (Jira)

Petr Kremensky created WFWIP-234: ------------------------------------ Summary: oc scale wildflyserver throws Permissions error with regular user Key: WFWIP-234 URL: https://issues.jboss.org/browse/WFWIP-234 Project: WildFly WIP Issue Type: Bug Components: OpenShift Reporter: Petr Kremensky Assignee: Jeff Mesnil Trying to use {{oc scale}} command using a regular users (non-admin) fails with permissions error: {code} oc scale --replicas=2 wildflyserver quickstart Error from server (Forbidden): wildflyservers.wildfly.org "quickstart" is forbidden: User "developer" cannot get resource "wildflyservers/scale" in API group "wildfly.org" in the namespace "eap-operator" {code} thou I'm able to change the wildflyserver (edit number of replicas in yaml) resource via web console without trouble. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12651) ModuleClassLoaderLocator$CombinedClassLoader created for every request when using default module

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-12651?page=com.atlassian.jira.plugin... ] Darran Lofthouse reassigned WFLY-12651: --------------------------------------- Assignee: (was: Darran Lofthouse) > ModuleClassLoaderLocator$CombinedClassLoader created for every request when using default module > ------------------------------------------------------------------------------------------------ > > Key: WFLY-12651 > URL: https://issues.jboss.org/browse/WFLY-12651 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 18.0.0.Final > Reporter: Matt Robson > Priority: Critical > Fix For: 19.0.0.Beta1 > > > During testing, we collected jmap -clstats to see what existed. > What we saw was: > total = 311741 > alive=1, dead=311740 > Of those 311750, 310687 of them are unique ModuleClassLoaderLocator$CombinedClassLoader with the same parent 0x0000000730aa98b8 > 0x000000074db04db0 0 0 0x0000000730aa98b8 dead org/jboss/as/security/plugins/ModuleClassLoaderLocator$CombinedClassLoader@0x00000007f0f58650 > Because they're dead, this is not a leak - but it shows what a new CL is created for every single request which is a huge performance hit. > The new classloading behaviour is introduced into 7.1 by https://issues.jboss.org/browse/SECURITY-930 / https://issues.jboss.org/browse/JBEAP-6559 > From https://github.com/jbossas/jboss-eap7/pull/925/files#diff-a8665415b9dad30... > } else > { mappingInfo.addJBossModuleName(DEFAULT_MODULE); } > } > The call(s) to ClassLoaderLocatorFactory.get() check for !jbossModuleNames.isEmpty() but because we now explicitly set the default module, it's never not empty so it gets called on every request. > ClassLoader moduleCL = null; > List<String> jbossModuleNames = jai.getJBossModuleNames(); > if (!jbossModuleNames.isEmpty()) > { ClassLoaderLocator locator = ClassLoaderLocatorFactory.get(); if (locator != null) moduleCL = locator.get(jbossModuleNames); } -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3566) DMN:Detailed interactions for creating and managing DRDs

by Elizabeth Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-3566?page=com.atlassian.jira.plugi... ] Elizabeth Clayton updated DROOLS-3566: -------------------------------------- Story Points: 5 (was: 3) > DMN:Detailed interactions for creating and managing DRDs > -------------------------------------------------------- > > Key: DROOLS-3566 > URL: https://issues.jboss.org/browse/DROOLS-3566 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Elizabeth Clayton > Assignee: Elizabeth Clayton > Priority: Major > Labels: UX, UXTeam, drools-tools > Attachments: contextual-menu.png > > > Canvas node actions related to grouping and assigning to DRDs. > As a user I want to easily select and group nodes on the canvas so that I can add them to a DRD or to create a new DRD. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12651) ModuleClassLoaderLocator$CombinedClassLoader created for every request when using default module

by Matt Robson (Jira)

Matt Robson created WFLY-12651: ---------------------------------- Summary: ModuleClassLoaderLocator$CombinedClassLoader created for every request when using default module Key: WFLY-12651 URL: https://issues.jboss.org/browse/WFLY-12651 Project: WildFly Issue Type: Bug Components: Security Affects Versions: 18.0.0.Final Reporter: Matt Robson Assignee: Darran Lofthouse Fix For: 19.0.0.Beta1 During testing, we collected jmap -clstats to see what existed. What we saw was: total = 311741 alive=1, dead=311740 Of those 311750, 310687 of them are unique ModuleClassLoaderLocator$CombinedClassLoader with the same parent 0x0000000730aa98b8 0x000000074db04db0 0 0 0x0000000730aa98b8 dead org/jboss/as/security/plugins/ModuleClassLoaderLocator$CombinedClassLoader@0x00000007f0f58650 Because they're dead, this is not a leak - but it shows what a new CL is created for every single request which is a huge performance hit. The new classloading behaviour is introduced into 7.1 by https://issues.jboss.org/browse/SECURITY-930 / https://issues.jboss.org/browse/JBEAP-6559 >From https://github.com/jbossas/jboss-eap7/pull/925/files#diff-a8665415b9dad30... } else { mappingInfo.addJBossModuleName(DEFAULT_MODULE); } } The call(s) to ClassLoaderLocatorFactory.get() check for !jbossModuleNames.isEmpty() but because we now explicitly set the default module, it's never not empty so it gets called on every request. ClassLoader moduleCL = null; List<String> jbossModuleNames = jai.getJBossModuleNames(); if (!jbossModuleNames.isEmpty()) { ClassLoaderLocator locator = ClassLoaderLocatorFactory.get(); if (locator != null) moduleCL = locator.get(jbossModuleNames); } -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4618) Test Scenario: refactor ExpressionEvaluator implementations

by Gabriele Cardosi (Jira)

[ https://issues.jboss.org/browse/DROOLS-4618?page=com.atlassian.jira.plugi... ] Gabriele Cardosi updated DROOLS-4618: ------------------------------------- Story Points: 3 > Test Scenario: refactor ExpressionEvaluator implementations > ----------------------------------------------------------- > > Key: DROOLS-4618 > URL: https://issues.jboss.org/browse/DROOLS-4618 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Reporter: Daniele Zonca > Assignee: Daniele Zonca > Priority: Major > Labels: ScenarioSimulation > > Refactor ExpressionEvaluator implementations moving from Object to String for rawExpression (and move as much as possible logic to common class) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4618) Test Scenario: refactor ExpressionEvaluator implementations

by Gabriele Cardosi (Jira)

[ https://issues.jboss.org/browse/DROOLS-4618?page=com.atlassian.jira.plugi... ] Gabriele Cardosi updated DROOLS-4618: ------------------------------------- Priority: Minor (was: Major) > Test Scenario: refactor ExpressionEvaluator implementations > ----------------------------------------------------------- > > Key: DROOLS-4618 > URL: https://issues.jboss.org/browse/DROOLS-4618 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Reporter: Daniele Zonca > Assignee: Daniele Zonca > Priority: Minor > Labels: ScenarioSimulation > > Refactor ExpressionEvaluator implementations moving from Object to String for rawExpression (and move as much as possible logic to common class) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4507) Ability to externally execute project defined tests.

by Toni Rikkola (Jira)

[ https://issues.jboss.org/browse/DROOLS-4507?page=com.atlassian.jira.plugi... ] Toni Rikkola commented on DROOLS-4507: -------------------------------------- Now the rest API can run all the tests. Is this to just run a specific test? > Ability to externally execute project defined tests. > ---------------------------------------------------- > > Key: DROOLS-4507 > URL: https://issues.jboss.org/browse/DROOLS-4507 > Project: Drools > Issue Type: Enhancement > Components: Scenario Simulation and Testing > Reporter: Paul Brown > Assignee: Daniele Zonca > Priority: Major > > Provide the ability to externally invoke project define tests scenario i.e via a rest api. > This is required in order for project defined tests to be reused and executed as part of a delivery pipeline and not from within business central. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4507) Ability to externally execute project defined tests.

by Gabriele Cardosi (Jira)

[ https://issues.jboss.org/browse/DROOLS-4507?page=com.atlassian.jira.plugi... ] Gabriele Cardosi updated DROOLS-4507: ------------------------------------- Story Points: 8 > Ability to externally execute project defined tests. > ---------------------------------------------------- > > Key: DROOLS-4507 > URL: https://issues.jboss.org/browse/DROOLS-4507 > Project: Drools > Issue Type: Enhancement > Components: Scenario Simulation and Testing > Reporter: Paul Brown > Assignee: Daniele Zonca > Priority: Major > > Provide the ability to externally invoke project define tests scenario i.e via a rest api. > This is required in order for project defined tests to be reused and executed as part of a delivery pipeline and not from within business central. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4588) Test Scenario: add support for MVEL expression on simple types in Rule test scenario

by Gabriele Cardosi (Jira)

[ https://issues.jboss.org/browse/DROOLS-4588?page=com.atlassian.jira.plugi... ] Gabriele Cardosi updated DROOLS-4588: ------------------------------------- Story Points: 1 (was: 5) > Test Scenario: add support for MVEL expression on simple types in Rule test scenario > ------------------------------------------------------------------------------------ > > Key: DROOLS-4588 > URL: https://issues.jboss.org/browse/DROOLS-4588 > Project: Drools > Issue Type: Enhancement > Components: Scenario Simulation and Testing > Reporter: Daniele Zonca > Assignee: Daniele Zonca > Priority: Major > Labels: CustomerFocus > > Add support to MVEL expression language as alternative supported syntax in Rule based scenario for simple types. > NOTE: simple types are all the type where user can directly write the value as input in the grid (string, integer, boolean, etc) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 9 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 2019