2:23 p.m.
[
https://issues.redhat.com/browse/WFLY-13132?page=com.atlassian.jira.plugi...
]
Richard Achmatowicz edited comment on WFLY-13132 at 3/2/20 3:21 PM:
--------------------------------------------------------------------
Historically, the only way for a remote client to connect to EJBs on the server was via
the URL scheme "remote" of the EJB client. This would effectively indicate a
choice to use EJB over Remoting . This involved making use of the <remote
connector-ref="remoting-connector"/> element in the EJB subsystem, where
connector-ref pointed to the standard Remoting-based connector <connector/> defined
in the Remoting subsystem. This in turn referenced the Remoting socket, port 4447.
The EJB3RemoteServiceAdd operation in the EJB3 subsystem defines a service,
EJBRemotingConnectorClientMappingsEntryProviderService, used to populate the client
mapping entries used for topology updates. The default client mapping entries which the
service creates are based on the socket host and port associated with the connector-ref.
For the Remoting connector <connector/> , these are remote://<host>:4447
Later, the scheme "http+remote" was introduced. This would effectively use EJB
over HTTP (with an upgrade to Remoting). This involved making use of the newer HTTP-based
connector <http-connector /> also defined in the Remoting subsystem. This involves
using Remoting based protocols by connecting to Undertow and then triggering a protocol
upgrade to Remoting. After the upgrade, the Remoting handshake would take place as usual.
However, unlike in the legacy case, the connector used would be the HTTP connector
<http-connector/>, which by default uses port 8080. In order to have the correct
client mapping entries generated (based on 8080 and not 4447), we needed to change the
connector ref in the <remote/> element from
connector-ref="remoting-connector" to
connector-ref="http-remoting-connector". This effectively changes which socket
is used to initialise the client mappings.
The problem, if I understand correctly, occurs when we try to configure use of both
"remote" and "remote+http" at the same time. The client mappings that
are generated only reflect one of the two protocol options.
It would seem that the solution is to change the way
EJBRemotingConnectorClientMappingsEntryProviderService is initialised, so that it takes
both possible connector references as parameters and will create client mapping entries
which will provide URIs for the "remote" protocol as well as the
"remote+http" protocol for the node in question. This way, during discovery, the
scheme can be used to select the correct URIs to choose.
was (Author: rachmato):
Historically, the only way for a remote client to connect to EJBs on the server was via
the URL scheme "remote" of the EJB client. This would effectively indicate a
choice to use EJB over Remoting . This involved making use of the <remote
connector-ref="remoting-connector"/> element in the EJB subsystem, where
connector-ref pointed to the standard Remoting-based connector <connector/> defined
in the Remoting subsystem. This in turn referenced the Remoting socket, port 4447.
The EJB3RemoteServiceAdd operation in the EJB3 subsystem defines a service,
EJBRemotingConnectorClientMappingsEntryProviderService, used to populate the client
mapping entries. The default client mapping entries which
EJBRemotingConnectorClientMappingsEntryProviderService creates are based on the socket
host and port associated with the connector-ref. For the Remoting connector
<connector/> , these are remote://<host>:4447
Later, the scheme "http+remote" was introduced. This would effectively use EJB
over HTTP (with an upgrade to Remoting). This involved making use of the newer HTTP-based
connector <http-connector /> also defined in the Remoting subsystem. This involves
using Remoting based protocols by connecting to Undertow and then triggering a protocol
upgrade to Remoting. After the upgrade, the Remoting handshake would take place as usual.
However, unlike in the legacy case, the connector used would be the HTTP connector
<http-connector/>, which by default uses port 8080. In order to have the correct
client mapping entries generated (based on 8080 and not 4447), we needed to change the
connector ref in the <remote/> element from
connector-ref="remoting-connector" to
connector-ref="http-remoting-connector". This effectively changes which socket
is used to initialise the client mappings.
The problem, if I understand correctly, occurs when we try to configure use of both
"remote" and "remote+http" at the same time. The client mappings that
are generated only reflect one of the two protocol options.
It would seem that the solution is to change the way
EJBRemotingConnectorClientMappingsEntryProviderService is initialised, so that it takes
both possible connector references as parameters and will create client mapping entries
which will provide URIs for the "remote" protocol as well as the
"remote+http" protocol for the node in question. This way, during discovery, the
scheme can be used to select the correct URIs to choose.
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
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)
2265
days inactive
2265
days old
0 comments
1 participants
participants (1)
-
Richard Achmatowicz (Jira)