[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 3/2/20 3:28 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 connector installs some special Undertow handlers, used to allow the upgrade to Remoting to take place when the incoming HTTP request has a header Upgrade: jboss-remoting: a connection is made to Undertow and this triggers 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 is associated with the http socket, using 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, because only one connector reference is passed to <remote/>.
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.
This might involve changing the <remote/> element to take a connector-ref and an htttp-connector-ref, or similar.
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 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.
> 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)
6 years, 2 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 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)
6 years, 2 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 commented on WFLY-13132:
--------------------------------------------
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)
6 years, 2 months
[JBoss JIRA] (DROOLS-5009) DMN Designer convert java class with invalid DMN identiefier
by Daniel José dos Santos (Jira)
[ https://issues.redhat.com/browse/DROOLS-5009?page=com.atlassian.jira.plug... ]
Daniel José dos Santos updated DROOLS-5009:
-------------------------------------------
Sprint: 2020 Week 10-12 (from Mar 2)
> DMN Designer convert java class with invalid DMN identiefier
> ------------------------------------------------------------
>
> Key: DROOLS-5009
> URL: https://issues.redhat.com/browse/DROOLS-5009
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.33.0.Final
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Minor
> Labels: drools-tools
> Attachments: Screenshot from 2020-02-05 16-21-10.png
>
>
> There is an issue if user convert java class to DMN data type while the java class contains field name, that is invalid identifier for DMN.
> for example assume this java class and try to convert it into DMN data type, you will get an error as attached.
> {code:java}
> public class Address {
> private int number;
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFCORE-4621) Create a service to install a dynamic 'wildflyee.api' module
by Yeray Borges Santana (Jira)
[ https://issues.redhat.com/browse/WFCORE-4621?page=com.atlassian.jira.plug... ]
Yeray Borges Santana commented on WFCORE-4621:
----------------------------------------------
Hi [~brian.stansberry],
My understanding is a static JBoss Modules module, instead of a dynamic one, with all its dependencies as optional, could work fine even if we are provisioning with {{passive+}} strategy. Galleon creates packages for the JBoss Modules to provision using the module.xml file, and when the dependencies are optional, the package created does not include them. That means a server with any kind of provisioning strategy won't provision the optional dependencies if they are not already included by any other package that could require them.
Do you agree or am I missing something?
If the above is correct, the approach could be then to create a static module.xml for a new module named {{wildflyee.api}}. This new module will have all its dependencies declared as {{optional}}. Replace the uses of the {{javaee.api}} module dependency in {{ExternalModuleSpecService}} by {{wildflyee.api}}. Make {{javaee.api}} in WildFly full become an alias of {{wildflyee.api}}. I understand we could have Jakarta EE APIs that could depend on other Jakarta EE APIs, but I understand it is assumable by the user using a slimmed server that does not contain all the Jakarta EE dependencies. Do you see any downside with this approach?
> Create a service to install a dynamic 'wildflyee.api' module
> ------------------------------------------------------------
>
> Key: WFCORE-4621
> URL: https://issues.redhat.com/browse/WFCORE-4621
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Yeray Borges Santana
> Priority: Minor
>
> Follow up on WFCORE-4612 by removing the list of detailed optional dependencies added there and instead have a service that installs a dynamic 'wildflyee.api' module that optional depends on all those. Then ExternalModuleDependencySpecService would add a dependency on that 'wildflyee.api' module.
> Then the next step is the javaee.api module in full WildFly would become an alias to wildflyee.api.
> The benefit to this is the content set for this 'ee.api' convenience module
> a) gets set in one place (vs the two places that WFCORE-4612 introduces)
> b) is defined in core, which makes some sense as core utilizes the module for the ExternalModuleDependencySpecService use case.
> c) External uses of 'javaee.api' can benefit from the WFCORE-4612 improvement; i.e. if they have slimmed the server such that some APIs are not present, javaee.api can still be used. They just can't be using any APIs that they slimmed away.
> A downside is maintaining an 'ee.api' modules is not a great fit for core.
> The reason to use a dynamic module is a static module would be visible to Galleon, and with the standard passive+[1] provisioning scheme we use that would lead to Galleon provisioning the packages for all the EE APIs, regardless of whether the server config required them.
> [1] https://docs.wildfly.org/galleon/#_effective_package_set
> This is somewhat me brainstorming, so needs harder thought.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-2729) KieScanner tries to read test dependencies
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-2729?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-2729:
--------------------------------
Sprint: 2020 Week 10-12 (from Mar 2)
> KieScanner tries to read test dependencies
> ------------------------------------------
>
> Key: DROOLS-2729
> URL: https://issues.redhat.com/browse/DROOLS-2729
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.8.0.Final
> Reporter: Ales Dolecek
> Assignee: Mario Fusco
> Priority: Major
>
> Method KieRepositoryScannerImpl#indexArtifacts first reads ALL dependencies and then tries to exclude those with scope test/provided/system. This is wrong since the nested dependencies might have different scope. Conseder this case:
> A -> depends on B (with scope test)
> B -> depends on C (with scope compile)
> Asking for allDependencies will yield following descriptors:
> A (compile scope)
> B (test scope)
> C (compile scope)
> B gets discarded, but C remains and scanner will try to resolve it and add to class loader.
> Instead of fitering the results of ArtifactResolver#getAllDependencies() (without parameters) you should use overloaded version of this method that accepts dependency filter.
> I do not create rules via GUI, but have them in separate Maven project. This projects contains tests cases that check if the rules are OK. The tests create the knowlege base from filesystem and require drools-decisiontables in order to execute.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFWIP-309) MP Fault Tolerance - WELD-001303: No active contexts for scope type javax.enterprise.context.ApplicationScoped
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFWIP-309?page=com.atlassian.jira.plugin... ]
Radoslav Husar updated WFWIP-309:
---------------------------------
Description:
There is unexpected error log in following test scenario:
- Deploy MP FT service with:
{noformat}
@Asynchronous
@Bulkhead(value = 15, waitingTaskQueue = 15)
@Timeout(value = 1000)
@Fallback(fallbackMethod = "processFallback")
public CompletionStage<MyConnection> bulkheadTimeout(boolean fail) throws InterruptedException {
if (fail) {
Thread.sleep(2000);
}
return CompletableFuture.completedFuture(new MyConnection() {
@Override
public String getData() {
return "Hello from @Bulkhead @Timeout method";
}
});
}
private CompletionStage<MyConnection> processFallback(boolean fail) {
return CompletableFuture.completedFuture(new MyConnection() {
@Override
public String getData() {
return "Fallback Hello";
}
});
}
{noformat}
- Send 10+ parallel requests with fail == true
Expected result:
All requests should go to fallback.
Actual Result:
This test is currently hitting issue WFWIP-308 however additionally there is error in server log:
{noformat}
10:49:45,752 ERROR [stderr] (pool-22-thread-5) Exception in thread "pool-22-thread-5" Exception in thread "pool-22-thread-1" org.jboss.weld.contexts.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.ApplicationScoped
10:49:45,752 ERROR [stderr] (pool-22-thread-5) at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:647)
10:49:45,753 ERROR [stderr] (pool-22-thread-5) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89)
10:49:45,753 ERROR [stderr] (pool-22-thread-5) at org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:123)
10:49:45,753 ERROR [stderr] (pool-22-thread-5) at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
10:49:45,753 ERROR [stderr] (pool-22-thread-5) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87)
10:49:45,753 ERROR [stderr] (pool-22-thread-5) at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:131)
10:49:45,753 ERROR [stderr] (pool-22-thread-5) at org.eclipse.microprofile.metrics.MetricRegistry$Proxy$_$$_WeldClientProxy.getHistograms(Unknown Source)
10:49:45,754 ERROR [stderr] (pool-22-thread-5) at io.smallrye.faulttolerance.metrics.MetricsCollectorFactory$MetricsCollectorImpl.histogramOf(MetricsCollectorFactory.java:105)
10:49:45,754 ERROR [stderr] (pool-22-thread-5) at io.smallrye.faulttolerance.metrics.MetricsCollectorFactory$MetricsCollectorImpl.histogramUpdate(MetricsCollectorFactory.java:86)
10:49:45,754 ERROR [stderr] (pool-22-thread-5) at io.smallrye.faulttolerance.metrics.MetricsCollectorFactory$MetricsCollectorImpl.bulkheadQueueLeft(MetricsCollectorFactory.java:125)
10:49:45,754 ERROR [stderr] (pool-22-thread-5) at io.smallrye.faulttolerance.core.bulkhead.CompletionStageBulkhead$CompletionStageBulkheadTask.run(CompletionStageBulkhead.java:78)
10:49:45,754 ERROR [stderr] (pool-22-thread-5) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
10:49:45,754 ERROR [stderr] (pool-22-thread-5) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
10:49:45,754 ERROR [stderr] (pool-22-thread-5) at java.lang.Thread.run(Thread.java:748)
10:49:45,755 ERROR [stderr] (pool-22-thread-1) org.jboss.weld.contexts.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.ApplicationScoped
10:49:45,755 ERROR [stderr] (pool-22-thread-1) at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:647)
10:49:45,755 ERROR [stderr] (pool-22-thread-1) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89)
10:49:45,755 ERROR [stderr] (pool-22-thread-1) at org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:123)
10:49:45,755 ERROR [stderr] (pool-22-thread-1) at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
10:49:45,755 ERROR [stderr] (pool-22-thread-1) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87)
10:49:45,756 ERROR [stderr] (pool-22-thread-1) at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:131)
10:49:45,756 ERROR [stderr] (pool-22-thread-1) at org.eclipse.microprofile.metrics.MetricRegistry$Proxy$_$$_WeldClientProxy.getHistograms(Unknown Source)
10:49:45,756 ERROR [stderr] (pool-22-thread-1) at io.smallrye.faulttolerance.metrics.MetricsCollectorFactory$MetricsCollectorImpl.histogramOf(MetricsCollectorFactory.java:105)
10:49:45,756 ERROR [stderr] (pool-22-thread-1) at io.smallrye.faulttolerance.metrics.MetricsCollectorFactory$MetricsCollectorImpl.histogramUpdate(MetricsCollectorFactory.java:86)
10:49:45,756 ERROR [stderr] (pool-22-thread-1) at io.smallrye.faulttolerance.metrics.MetricsCollectorFactory$MetricsCollectorImpl.bulkheadQueueLeft(MetricsCollectorFactory.java:125)
10:49:45,756 ERROR [stderr] (pool-22-thread-1) at io.smallrye.faulttolerance.core.bulkhead.CompletionStageBulkhead$CompletionStageBulkheadTask.run(CompletionStageBulkhead.java:78)
10:49:45,757 ERROR [stderr] (pool-22-thread-1) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
10:49:45,757 ERROR [stderr] (pool-22-thread-1) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
10:49:45,757 ERROR [stderr] (pool-22-thread-1) at java.lang.Thread.run(Thread.java:748)
{noformat}
was:
There is unexpected error log in following test scenario:
- Deploy MP FT service with:
{noformat}
@Asynchronous
@Bulkhead(value = 15, waitingTaskQueue = 15)
@Timeout(value = 1000)
@Fallback(fallbackMethod = "processFallback")
public CompletionStage<MyConnection> bulkheadTimeout(boolean fail) throws InterruptedException {
if (fail) {
Thread.sleep(2000);
}
return CompletableFuture.completedFuture(new MyConnection() {
@Override
public String getData() {
return "Hello from @Bulkhead @Timeout method";
}
});
}
private CompletionStage<MyConnection> processFallback(boolean fail) {
return CompletableFuture.completedFuture(new MyConnection() {
@Override
public String getData() {
return "Fallback Hello";
}
});
}
{noformat}
- Send 10+ parallel requests with fail == true
Expected result:
All requests should go to fallback.
Actual Result:
This test is currently hitting issue WFWIP-308 however additionally there is error in server log:
{code}
16:55:41,374 ERROR [stderr] (pool-22-thread-2) Exception in thread "pool-22-thread-4" Exception in thread "pool-22-thread-2" org.jboss.weld.contexts.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.ApplicationScoped
16:55:41,374 ERROR [stderr] (pool-22-thread-2) at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:647)
16:55:41,374 ERROR [stderr] (pool-22-thread-2) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89)
16:55:41,374 ERROR [stderr] (pool-22-thread-2) at org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:123)
16:55:41,374 ERROR [stderr] (pool-22-thread-2) at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
16:55:41,374 ERROR [stderr] (pool-22-thread-2) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87)
16:55:41,375 ERROR [stderr] (pool-22-thread-2) at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:131)
16:55:41,375 ERROR [stderr] (pool-22-thread-2) at org.eclipse.microprofile.metrics.MetricRegistry$Proxy$_$$_WeldClientProxy.getHistograms(Unknown Source)
16:55:41,375 ERROR [stderr] (pool-22-thread-2) at io.smallrye.faulttolerance.metrics.MetricsCollectorFactory$MetricsCollectorImpl.histogramOf(MetricsCollectorFactory.java:105)
16:55:41,375 ERROR [stderr] (pool-22-thread-2) at io.smallrye.faulttolerance.metrics.MetricsCollectorFactory$MetricsCollectorImpl.histogramUpdate(MetricsCollectorFactory.java:86)
16:55:41,375 ERROR [stderr] (pool-22-thread-2) at io.smallrye.faulttolerance.metrics.MetricsCollectorFactory$MetricsCollectorImpl.bulkheadQueueLeft(MetricsCollectorFactory.java:125)
16:55:41,375 ERROR [stderr] (pool-22-thread-2) at io.smallrye.faulttolerance.core.bulkhead.CompletionStageBulkhead$CompletionStageBulkheadTask.run(CompletionStageBulkhead.java:78)
16:55:41,375 ERROR [stderr] (pool-22-thread-2) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
16:55:41,375 ERROR [stderr] (pool-22-thread-2) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
16:55:41,375 ERROR [stderr] (pool-22-thread-2) at java.lang.Thread.run(Thread.java:748)
{code}
> MP Fault Tolerance - WELD-001303: No active contexts for scope type javax.enterprise.context.ApplicationScoped
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-309
> URL: https://issues.redhat.com/browse/WFWIP-309
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Fault Tolerance
> Reporter: Miroslav Novak
> Assignee: Radoslav Husar
> Priority: Blocker
>
> There is unexpected error log in following test scenario:
> - Deploy MP FT service with:
> {noformat}
> @Asynchronous
> @Bulkhead(value = 15, waitingTaskQueue = 15)
> @Timeout(value = 1000)
> @Fallback(fallbackMethod = "processFallback")
> public CompletionStage<MyConnection> bulkheadTimeout(boolean fail) throws InterruptedException {
> if (fail) {
> Thread.sleep(2000);
> }
> return CompletableFuture.completedFuture(new MyConnection() {
> @Override
> public String getData() {
> return "Hello from @Bulkhead @Timeout method";
> }
> });
> }
> private CompletionStage<MyConnection> processFallback(boolean fail) {
> return CompletableFuture.completedFuture(new MyConnection() {
> @Override
> public String getData() {
> return "Fallback Hello";
> }
> });
> }
> {noformat}
> - Send 10+ parallel requests with fail == true
> Expected result:
> All requests should go to fallback.
> Actual Result:
> This test is currently hitting issue WFWIP-308 however additionally there is error in server log:
> {noformat}
> 10:49:45,752 ERROR [stderr] (pool-22-thread-5) Exception in thread "pool-22-thread-5" Exception in thread "pool-22-thread-1" org.jboss.weld.contexts.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.ApplicationScoped
> 10:49:45,752 ERROR [stderr] (pool-22-thread-5) at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:647)
> 10:49:45,753 ERROR [stderr] (pool-22-thread-5) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89)
> 10:49:45,753 ERROR [stderr] (pool-22-thread-5) at org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:123)
> 10:49:45,753 ERROR [stderr] (pool-22-thread-5) at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
> 10:49:45,753 ERROR [stderr] (pool-22-thread-5) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87)
> 10:49:45,753 ERROR [stderr] (pool-22-thread-5) at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:131)
> 10:49:45,753 ERROR [stderr] (pool-22-thread-5) at org.eclipse.microprofile.metrics.MetricRegistry$Proxy$_$$_WeldClientProxy.getHistograms(Unknown Source)
> 10:49:45,754 ERROR [stderr] (pool-22-thread-5) at io.smallrye.faulttolerance.metrics.MetricsCollectorFactory$MetricsCollectorImpl.histogramOf(MetricsCollectorFactory.java:105)
> 10:49:45,754 ERROR [stderr] (pool-22-thread-5) at io.smallrye.faulttolerance.metrics.MetricsCollectorFactory$MetricsCollectorImpl.histogramUpdate(MetricsCollectorFactory.java:86)
> 10:49:45,754 ERROR [stderr] (pool-22-thread-5) at io.smallrye.faulttolerance.metrics.MetricsCollectorFactory$MetricsCollectorImpl.bulkheadQueueLeft(MetricsCollectorFactory.java:125)
> 10:49:45,754 ERROR [stderr] (pool-22-thread-5) at io.smallrye.faulttolerance.core.bulkhead.CompletionStageBulkhead$CompletionStageBulkheadTask.run(CompletionStageBulkhead.java:78)
> 10:49:45,754 ERROR [stderr] (pool-22-thread-5) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 10:49:45,754 ERROR [stderr] (pool-22-thread-5) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 10:49:45,754 ERROR [stderr] (pool-22-thread-5) at java.lang.Thread.run(Thread.java:748)
> 10:49:45,755 ERROR [stderr] (pool-22-thread-1) org.jboss.weld.contexts.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.ApplicationScoped
> 10:49:45,755 ERROR [stderr] (pool-22-thread-1) at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:647)
> 10:49:45,755 ERROR [stderr] (pool-22-thread-1) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89)
> 10:49:45,755 ERROR [stderr] (pool-22-thread-1) at org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:123)
> 10:49:45,755 ERROR [stderr] (pool-22-thread-1) at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
> 10:49:45,755 ERROR [stderr] (pool-22-thread-1) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87)
> 10:49:45,756 ERROR [stderr] (pool-22-thread-1) at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:131)
> 10:49:45,756 ERROR [stderr] (pool-22-thread-1) at org.eclipse.microprofile.metrics.MetricRegistry$Proxy$_$$_WeldClientProxy.getHistograms(Unknown Source)
> 10:49:45,756 ERROR [stderr] (pool-22-thread-1) at io.smallrye.faulttolerance.metrics.MetricsCollectorFactory$MetricsCollectorImpl.histogramOf(MetricsCollectorFactory.java:105)
> 10:49:45,756 ERROR [stderr] (pool-22-thread-1) at io.smallrye.faulttolerance.metrics.MetricsCollectorFactory$MetricsCollectorImpl.histogramUpdate(MetricsCollectorFactory.java:86)
> 10:49:45,756 ERROR [stderr] (pool-22-thread-1) at io.smallrye.faulttolerance.metrics.MetricsCollectorFactory$MetricsCollectorImpl.bulkheadQueueLeft(MetricsCollectorFactory.java:125)
> 10:49:45,756 ERROR [stderr] (pool-22-thread-1) at io.smallrye.faulttolerance.core.bulkhead.CompletionStageBulkhead$CompletionStageBulkheadTask.run(CompletionStageBulkhead.java:78)
> 10:49:45,757 ERROR [stderr] (pool-22-thread-1) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 10:49:45,757 ERROR [stderr] (pool-22-thread-1) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 10:49:45,757 ERROR [stderr] (pool-22-thread-1) at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months