[JBoss JIRA] (WFLY-13132) Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13132?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz commented on WFLY-13132:
--------------------------------------------
In order to get this issue merged, some additional work had to be completed to update the transformer tests for the ejb3 subsystem. This work has now been completed in https://issues.redhat.com/browse/WFLY-13267; a PR has been submitted and it is being reviewed.
The work for this issue has been completed, aside from writing a test case which is in progress.
> Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client
> -----------------------------------------------------------
>
> Key: WFLY-13132
> URL: https://issues.redhat.com/browse/WFLY-13132
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 19.0.0.Beta2
> Reporter: Joerg Baesner
> Assignee: Richard Achmatowicz
> Priority: Major
> Labels: downstream_dependency
> Attachments: playground.zip
>
>
> h2. +Issue+
> h3. +General Client setup:+
> {code:java}
> Properties p = new Properties();
> p.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
> p.put(Context.PROVIDER_URL, {see below});
> p.put(Context.SECURITY_PRINCIPAL, USER);
> p.put(Context.SECURITY_CREDENTIALS, PWD);
> Context context = new InitialContext(p);
> {code}
> ----
> h3. +Standard server configuration:+
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:ejb3:5.0">
> ...
> <remote connector-ref="http-remoting-connector" thread-pool-name="default">
> <channel-creation-options>
> <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/>
> <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/>
> </channel-creation-options>
> </remote>
> ...
> </subsystem>
> ...
> <subsystem xmlns="urn:jboss:domain:remoting:4.0">
> <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm">
> <properties>
> <property name="SSL_ENABLED" value="false"/>
> </properties>
> </connector>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
> </subsystem>
> {code}
> h5. +invocation from remote client to server with:+
> * {{remote://localhost:4447}}
> * {{remote+http://localhost:8080}}
> h5. +Client side topology update always:+
> {noformat}
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node0
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:8080
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node1
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:8180
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-web
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-ejb
> {noformat}
> ----
> h3. +Legacy server configuration:+
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:ejb3:5.0">
> ...
> <remote connector-ref="remoting-connector" thread-pool-name="default">
> <channel-creation-options>
> <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/>
> <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/>
> </channel-creation-options>
> </remote>
> ...
> </subsystem>
> ...
> <subsystem xmlns="urn:jboss:domain:remoting:4.0">
> <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm">
> <properties>
> <property name="SSL_ENABLED" value="false"/>
> </properties>
> </connector>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
> </subsystem>
> {code}
> h5. +invocation from remote client to server with:+
> * {{remote://localhost:4447}}
> * {{remote+http://localhost:8080}}
> h5. +Client side topology update always:+
> {noformat}
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node0
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:4447
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node1
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:4547
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-web
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-ejb
> {noformat}
> h2. +Conclusion+
> Depending on what is configured as {{connector-ref}} in the {{remote}} of the _ejb3_ subsystem the {{CLUSTER_TOPOLOGY}} update is different. From a client perspective it would be expected that either the {{CLUSTER_TOPOLOGY}} update would _only_ contain destinations that are applicable for the _connector/protocol_ that has been used, or maybe even _ALL_ available destinations, as the client could potentially run a mix of protocols between invocations...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-13132) Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13132?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz edited comment on WFLY-13132 at 4/17/20 6:42 PM:
---------------------------------------------------------------------
In order to permit the specification of multiple connectors to the <remote/> element, I am replacing the attribute connector-ref (as in <remote connector-ref="connector-name"/>) with a list of connector names <remote connectors="<list of connector names>"/>, so that a single or multiple connector references can be passed to the remote connector. So the current issue can be fixed by defining <remote connectors="remoting-connector http-remoting-connector"/>
The now legacy attribute connector-ref will be deprecated.
was (Author: rachmato):
In order to permit the specification of multiple connectors to the <remote/> element, I am replacing the attribute connector-ref (as in <remote connector-ref="connector-name"/>) with a list of connector names <remote connectors="<list of connector names>"/>, so that a single or multiple connector references can be passed to the remote connector. So the current issue can be fixed by defining <remote connectors="remoting-connector http-remoting-connector"/>
The now legacy attribute connector-ref will be deprecated.
Transformers need to be set up to transform new configurations for the <remote/> element to legacy configurations of the remote element. The initial attempt at this will be as follows:
* connectors
** undefined -> discard attribute
** defined and list size == 1, convert to connector-ref attribute using that list element
** defined and list size > 1, reject attribute as no legacy configuration can handle two connectors
* connector-ref
** undefined - > discard attribute
** defined and connectors is undefined -> pass attribute through with message that connector-ref is deprecated
** defined and connectors is defined -> reject with message that connector-ref and connectors cannot both be defined and connector-ref is deprecated
> Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client
> -----------------------------------------------------------
>
> Key: WFLY-13132
> URL: https://issues.redhat.com/browse/WFLY-13132
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 19.0.0.Beta2
> Reporter: Joerg Baesner
> Assignee: Richard Achmatowicz
> Priority: Major
> Labels: downstream_dependency
> Attachments: playground.zip
>
>
> h2. +Issue+
> h3. +General Client setup:+
> {code:java}
> Properties p = new Properties();
> p.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
> p.put(Context.PROVIDER_URL, {see below});
> p.put(Context.SECURITY_PRINCIPAL, USER);
> p.put(Context.SECURITY_CREDENTIALS, PWD);
> Context context = new InitialContext(p);
> {code}
> ----
> h3. +Standard server configuration:+
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:ejb3:5.0">
> ...
> <remote connector-ref="http-remoting-connector" thread-pool-name="default">
> <channel-creation-options>
> <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/>
> <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/>
> </channel-creation-options>
> </remote>
> ...
> </subsystem>
> ...
> <subsystem xmlns="urn:jboss:domain:remoting:4.0">
> <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm">
> <properties>
> <property name="SSL_ENABLED" value="false"/>
> </properties>
> </connector>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
> </subsystem>
> {code}
> h5. +invocation from remote client to server with:+
> * {{remote://localhost:4447}}
> * {{remote+http://localhost:8080}}
> h5. +Client side topology update always:+
> {noformat}
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node0
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:8080
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node1
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:8180
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-web
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-ejb
> {noformat}
> ----
> h3. +Legacy server configuration:+
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:ejb3:5.0">
> ...
> <remote connector-ref="remoting-connector" thread-pool-name="default">
> <channel-creation-options>
> <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/>
> <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/>
> </channel-creation-options>
> </remote>
> ...
> </subsystem>
> ...
> <subsystem xmlns="urn:jboss:domain:remoting:4.0">
> <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm">
> <properties>
> <property name="SSL_ENABLED" value="false"/>
> </properties>
> </connector>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
> </subsystem>
> {code}
> h5. +invocation from remote client to server with:+
> * {{remote://localhost:4447}}
> * {{remote+http://localhost:8080}}
> h5. +Client side topology update always:+
> {noformat}
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node0
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:4447
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node1
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:4547
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-web
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-ejb
> {noformat}
> h2. +Conclusion+
> Depending on what is configured as {{connector-ref}} in the {{remote}} of the _ejb3_ subsystem the {{CLUSTER_TOPOLOGY}} update is different. From a client perspective it would be expected that either the {{CLUSTER_TOPOLOGY}} update would _only_ contain destinations that are applicable for the _connector/protocol_ that has been used, or maybe even _ALL_ available destinations, as the client could potentially run a mix of protocols between invocations...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-1067?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz closed WFLY-1067.
-------------------------------------
Resolution: Out of Date
> Integrate JGroups with core AS security infrastructure
> ------------------------------------------------------
>
> Key: WFLY-1067
> URL: https://issues.redhat.com/browse/WFLY-1067
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Security
> Reporter: Brian Stansberry
> Assignee: Richard Achmatowicz
> Priority: Major
>
> Container task for better integrating JGroups security with overall AS security. The basic concept is the various security aware aspects of JGroups will expose an SPI, and the AS can create implementations of those SPIs that integrate with the AS security realms. The AS JGroups subsystem will inject the implementation into the JGroups runtime components.
> Subtasks are for the various aspects. These can be done separately but a common overall design should be created to ensure a consistent approach is taken.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (DROOLS-5251) Decision Table Output Header in Business Knowledge Model Renders Incorrectly When Output is a structure
by Tracy Hires (Jira)
Tracy Hires created DROOLS-5251:
-----------------------------------
Summary: Decision Table Output Header in Business Knowledge Model Renders Incorrectly When Output is a structure
Key: DROOLS-5251
URL: https://issues.redhat.com/browse/DROOLS-5251
Project: Drools
Issue Type: Bug
Components: DMN Editor
Affects Versions: 7.34.0.Final
Reporter: Tracy Hires
Assignee: Guilherme Gomes
Attachments: Decision.dmn, actual rendering.png, expected rendering.png
When the result of a Business Knowledge Model is a structure, and the logical expression for the business knowledge model is a decision table, the column headers for the output do not render correctly (see attached actual rendering.png, expected rendering.png). If the Decision Table in the BKM is nested inside of a context, then the headers will render correctly. (Though doing this will trigger the behavior described in DROOLS-5236.)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-13355) Add a Galleon layer for EE Concurrency
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13355?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFLY-13355:
---------------------------------------
Assignee: (was: Brian Stansberry)
> Add a Galleon layer for EE Concurrency
> --------------------------------------
>
> Key: WFLY-13355
> URL: https://issues.redhat.com/browse/WFLY-13355
> Project: WildFly
> Issue Type: Feature Request
> Components: Build System, Concurrency Utilities
> Reporter: Brian Stansberry
> Priority: Optional
>
> Minor thing. The existing 'ee' layer adds the EE Concurrency resources, which is fine. Adding a layer specific to ee-concurrency, which the existing ee layer would optionally depend on, would allow users to *exclude* it. Doing so wouldn't do much in terms of disk footprint, probably well under 200K. The main reason I file this is when I provision some slim servers suddenly the amount of config going to the ee concurrency resources jumps out at you. Even if the real impact of those isn't much it gives a sense of bloat.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
