[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:
--------------------------------------------
I think the simplest way to deal with this is to enforce a default behaviour of one protocol per proxy instance, which is effectively what we had before the possibility of having two EJB remote connectors became available. Each time a proxy is created, it has an
{noformat}
String initialProtocol = null ;
{noformat}
setting in the EJBInvocationHandler. When a target is chosen, this gets initialised with the protocol used in the first target. Thereafter, any candidate for a target needs to have a protocol which matches the value in initialProtocol; if there is no such target, the invocation fails. Both the NamingEJBClientInterceptor and the DiscoveryEJBClientInterceptor can be modified to check this value before assigning a destination. In particular, discovery can make use of a new filterspec variable for the protocol so that searches only return values which match the given protocol.
The only problem is how to select the first invocation target (for the generation 4.x EJB client) when there are two or more possibilities available. This choice could be based on a number of possible calculations:
* the protocol used in any JNDI PROVIDER_URL
* the protocol used in any configured connections in wildfly-config.xml which end up in the EJBClientContext
* a specific setting in the EJBClientContext, such as "preferProtocol="remote|remote+http|remote+https" where the protocols are ordered in preference
* a simple setting like "preferlegacyProtocol=true" to indicate a preference of "remote" over "remote+http" or "remote+https"
Just some ideas.
> 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, 2 months
[JBoss JIRA] (WFCORE-4948) read-resource operation does not return the version and name spaces
by Yeray Borges Santana (Jira)
Yeray Borges Santana created WFCORE-4948:
--------------------------------------------
Summary: read-resource operation does not return the version and name spaces
Key: WFCORE-4948
URL: https://issues.redhat.com/browse/WFCORE-4948
Project: WildFly Core
Issue Type: Bug
Components: Management
Affects Versions: 7.0.0.Final
Reporter: Yeray Borges Santana
Assignee: Yeray Borges Santana
The following operation, in this case for the jmx subsystem resource, returns the version and xml-namespaces of the read resource:
{noformat}
[standalone@localhost:9990 /] /extension=org.jboss.as.jmx/subsystem=jmx:read-resource
{
"outcome" => "success",
"result" => {
"management-major-version" => 1,
"management-micro-version" => 0,
"management-minor-version" => 2,
"xml-namespaces" => [
"urn:jboss:domain:jmx:1.0",
"urn:jboss:domain:jmx:1.1",
"urn:jboss:domain:jmx:1.2",
"urn:jboss:domain:jmx:1.3"
]
}
}
{noformat}
Since wildlfly-core 7.0.0.Final, this operation does not return any value:
{noformat}
[standalone@localhost:9990 /] /extension=org.jboss.as.jmx/subsystem=jmx:read-resource
{
"outcome" => "success",
"result" => {}
}
{noformat}
The operation returns the same empty result for any subsystem read similarly under the extension resource.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13413) Undertow mod-cluster filter capability name is incorrectly generated from the parent resource
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13413?page=com.atlassian.jira.plugi... ]
Radoslav Husar updated WFLY-13413:
----------------------------------
Security: (was: Red Hat Internal)
> Undertow mod-cluster filter capability name is incorrectly generated from the parent resource
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-13413
> URL: https://issues.redhat.com/browse/WFLY-13413
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster, Web (Undertow)
> Affects Versions: 19.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Major
> Labels: regression
>
> {code}
> <filters>
> <mod-cluster name="load-balancer" management-socket-binding="mcmp-management" advertise-socket-binding="modcluster" enable-http2="true" max-retries="3"/>
> <mod-cluster name="load-balancer2" management-socket-binding="mcmp-management" advertise-socket-binding="modcluster" enable-http2="true" max-retries="3"/>
> </filters>
> {code}
> {code}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 2) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "undertow"),
> ("configuration" => "filter"),
> ("mod-cluster" => "load-balancer2")
> ]) - failure description: "WFLYCTL0436: Cannot register capability 'org.wildfly.undertow.mod_cluster-filter.filter' at location '[
> (\"subsystem\" => \"undertow\"),
> (\"configuration\" => \"filter\"),
> (\"mod-cluster\" => \"load-balancer2\")
> ]' as it is already registered in context 'global' at location(s) '[[
> (\"subsystem\" => \"undertow\"),
> (\"configuration\" => \"filter\"),
> (\"mod-cluster\" => \"load-balancer\")
> ]]'"
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13405) Update CommonDeploymentService in release.
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFLY-13405?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFLY-13405:
--------------------------------------
[~algolua7] Is there something special about your environment? Are you by chance using an embedded server? I'm trying to figure out how slf4j would end up on the call stack as jboss-logging should be binding to the jboss-logmanager. When I run this locally I see the following which is still wrong but doesn't break anything:
{code}
08:23:45,015 DEBUG [org.jboss.as.connector] (MSC service thread 1-2) Started CommonDeployment %s
{code}
> Update CommonDeploymentService in release.
> ------------------------------------------
>
> Key: WFLY-13405
> URL: https://issues.redhat.com/browse/WFLY-13405
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 19.0.0.Final
> Reporter: Alexander Golovko
> Assignee: Brian Stansberry
> Priority: Major
> Attachments: debug.log
>
>
> Current calls of ROOT_LOGGER.debugf("Started/Stopped CommonDeployment %s", new Object[0]); are errors. They raise MissingFormatArgumentException exception since new Object[0] is an empty array and is not compatible with %s in format argument.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13405) Update CommonDeploymentService in release.
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13405?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-13405:
-----------------------------------------
[~jamezp] No, I didn't try to reproduce; I just saw the fix was obvious but went down the rabbit hole a bit to try and guess why it happened to Alexander but not to tons of people over the last 4-5 years.
> Update CommonDeploymentService in release.
> ------------------------------------------
>
> Key: WFLY-13405
> URL: https://issues.redhat.com/browse/WFLY-13405
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 19.0.0.Final
> Reporter: Alexander Golovko
> Assignee: Brian Stansberry
> Priority: Major
> Attachments: debug.log
>
>
> Current calls of ROOT_LOGGER.debugf("Started/Stopped CommonDeployment %s", new Object[0]); are errors. They raise MissingFormatArgumentException exception since new Object[0] is an empty array and is not compatible with %s in format argument.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13387) Expose Jaeger Client Metrics
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13387?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFLY-13387:
---------------------------------------
Component/s: (was: MP Metrics)
Assignee: Emmanuel Hugonnet (was: Jeff Mesnil)
[~jmesnil] [~ehugonnet] I'm dropping MP Metrics from this one and changing the assignee. My assumption is anything for this would involve adding standard WildFly management metrics, which then come through MP Metrics the same way all other subsystem metrics do. So nothing specific to MP Metrics about it.
> Expose Jaeger Client Metrics
> ----------------------------
>
> Key: WFLY-13387
> URL: https://issues.redhat.com/browse/WFLY-13387
> Project: WildFly
> Issue Type: Feature Request
> Components: MP OpenTracing
> Reporter: Tobias Stadler
> Assignee: Emmanuel Hugonnet
> Priority: Major
>
> I would be nice, if the internal jaeger client metrics could be exposed via mp metrics endpoint.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JGRP-2474) Messages about dropped queued message when using IpAddressUUID
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2474?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2474:
--------------------------------
{{IpAddressUUID}} has been removed in 5. Reason: nobody ever used it, it added complexity and it was never well tested.
I'm reluctant to look into something that has been pulled from the codebase in the next version.
If you want readable information, I suggest use {{ExtendedUUID}} or create your own subclass of {{UUID}} that includes a name, so it is visible in the database table.
> Messages about dropped queued message when using IpAddressUUID
> --------------------------------------------------------------
>
> Key: JGRP-2474
> URL: https://issues.redhat.com/browse/JGRP-2474
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.2.3
> Reporter: Mirko Streckenbach
> Assignee: Bela Ban
> Priority: Major
> Attachments: JGR.java, log-fail-1.txt
>
>
> We upgraded from 4.0.14 to 4.1.8 and ever since then, we had some messages like
> {code}
> Apr 27, 2020 10:30:54 AM org.jgroups.protocols.UNICAST3 addQueuedMessages
> WARNING: i2:1709: dropped queued message i1:1609#2 as its conn_id (0) did not match (entry.conn_id=1)
> {code}
> when ever an application is restarted. Our setup is as follows (most due to network restrictions):
> * Fixed port numbers
> * JDBC_PING
> * We use IpAddressUUID in order to have a "readable" information in the jgroupsping table
> I could track this down to 4.1.2 / 4.1.3: 4.1.2 works as expected, from 4.1.3 I'm seeing the effect observed above.
> I attached a simple example that demonstrates the problem: starts two stacks, shuts down the second (non-coordindator) and starts it again after a couple of seconds. With 4.1.2 this works as expected (no warnings), but 4.1.3 and more recent versions (including 4.2.3) produce warnings. The exact behavior is not completely consistent: in most cases, starting the second app again results in some timeouts and the second app becomes a coordinator itself and a merge view is established later (log attached). In some cases it only creates the warnings shown above (this is what we observe in our real application) and in some cases everything works fine.
> I don't have any warnings in the log if I don't set an AddressGenerator, but I'd like to avoid this.
> While running this on higher debug levels, I observed the following: 4.1.2 will not require an
> ACK for the LEAVE_RSP message. 4.1.3 will. The second app sends the ACK, but the coordinator does not seem to receive or process it properly and retransmits the LEAVE_RSP message again and again. This is independent of the AddressGenerator used,
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months