[JBoss JIRA] (WFLY-12188) Option READ_TIMEOUT is ignored
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12188?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-12188:
-----------------------------------------
tl;dr; A "READ_TIMEOUT" is not part of the set of options used by the object configured by the EJB subsystem. It was 'cruft' because it was not a setting relevant to that part of the configuration and in the end was ignored. It shouldn't be configured. However, configuring it does no harm beyond causing confusion, since the setting is ignored. The remoting subsystem http-connector setting is the one that matters.
The details:
The place that ejb3 subsystem config chunk is used is:
https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
which drives the state of an EJBRemoteConnectorService
https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
which drives the registration of a service on an existing Endpoint:
https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo...
The option map associated with that Registration is ultimately consumed by RemoteReadListener:
https://github.com/jboss-remoting/jboss-remoting/blob/master/src/main/jav...
The only options it considers are the ones starting at L181. READ_TIMEOUT is not one of them.
I believe that's because those are the only ones relevant to RemoteReadListener which AFAICT is not involved with connection management.
The http-connector config in the remoting subsystem OTOH does ultimately provide options that are related to connection management. I won't go through the whole path to that, but here's a key point:
https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr...
leading to:
https://github.com/jboss-remoting/jboss-remoting/blob/master/src/main/jav...
> Option READ_TIMEOUT is ignored
> ------------------------------
>
> Key: WFLY-12188
> URL: https://issues.jboss.org/browse/WFLY-12188
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Remoting
> Affects Versions: 17.0.0.Final
> Reporter: Joerg Baesner
> Assignee: Flavia Rainone
> Priority: Blocker
>
> What's the difference of the {{READ_TIMEOUT}} in _ejb3_ subsystem vs. _remoting_ subsystem? See:
> {code}
> <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>
> {code}
> {code}
> <subsystem xmlns="urn:jboss:domain:remoting:4.0">
> <endpoint/>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm">
> <!-- server-side configuration -->
> <properties>
> <property name="org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL" value="5000"/>
> <property name="KEEP_ALIVE" value="true"/>
> <property name="READ_TIMEOUT" value="10000"/>
> <property name="WRITE_TIMEOUT" value="10000"/>
> </properties>
> </http-connector>
> {code}
> None of those options work.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-12048) outbound-socket-binding element should allow grouping to be referenced by JGroups socket-discovery-protocol
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-12048?page=com.atlassian.jira.plugin... ]
Paul Ferraro closed WFLY-12048.
-------------------------------
Resolution: Rejected
Replaced by WFLY-12220
> outbound-socket-binding element should allow grouping to be referenced by JGroups socket-discovery-protocol
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12048
> URL: https://issues.jboss.org/browse/WFLY-12048
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 16.0.0.Final
> Reporter: Wolf-Dieter Fink
> Assignee: Radoslav Husar
> Priority: Major
>
> JGroups configuration can use two different ways to configure cluster detection
> ------ older configuration is via protocol properties --
> <protocol type="TCPPING">
> <property name="initial_hosts">host[7600]</property>
> ------ new configuration via socket reference
> <socket-discovery-protocol type="TCPPING" socket-bindings="ref-a ref-b"/>
> ...
> <outbound-socket-binding name="ref-a">
> <remote-destination host="127.0.0.1" port="7600"/>
> </outbound-socket-binding>
> -----------
> with the old option it is possible to use an expression to set all hosts in a cluster.
> The new one need to have all outbound connections listed which is harder to maintain.
> As an administrator I want to have the possibility to group the connections and only have one reference and the number of connections can be vary without changing multiple point in the configuration.
> So a configuration like this would enhance that
> <outbound-socket-binding-group>
> <outbound-socket-binding name="ref-a">
> <remote-destination host="host1" port="7600"/>
> </outbound-socket-binding>
> <outbound-socket-binding name="ref-b">
> <remote-destination host="host2" port="7600"/>
> </outbound-socket-binding>
> </outbound-socket-binding-group>
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-12222) Clustering subsystems integration with WildFly Discovery SPI (tracker Jira)
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-12222?page=com.atlassian.jira.plugin... ]
Paul Ferraro updated WFLY-12222:
--------------------------------
Description:
Ultimately, we could employ WildFly Discovery SPI to handle services discovery in a generic way. However, since the subsystem currently only supplies one provider based on static discovery, its usefulness is limited. To untangle the chicken-egg problem, we could first integrate the clustering subsystems with the discovery SPI,
* JGroups discovery
* remote-cache-container remote servers
* mod_cluster
then supply discovery providers,
* static list (implemented)
* multicast-based
* k8s-based (replacing JGroups' OPENSHIFT_PING, DNS_PING, KUBE_PING, etc)
* cloud providers specific (replacing S3_PING, NATIVE_S3_PING, AZURE_PING, GOOGLE_PING, etc)
This requires fixes to the discovery subsystem such as
* ability to register new providers
* Adding/removing services from static providers should require server reload, or restart of the service providing the DiscoveryProvider
* TBD
was:
Ultimately, we could employ WildFly Discovery SPI to handle services discovery in a generic way. However, since the subsystem currently only supplies one provider based on static discovery, its usefulness is limited. To untangle the chicken-egg problem, we could first integrate the clustering subsystems with the discovery SPI,
* JGroups discovery
* remote-cache-container remote servers
* mod_cluster
then supply discovery providers,
* static list (implemented)
* multicast-based
* k8s-based (replacing JGroups' OPENSHIFT_PING, DNS_PING, KUBE_PING, etc)
* cloud providers specific (replacing S3_PING, NATIVE_S3_PING, AZURE_PING, GOOGLE_PING, etc)
This requires fixes to the discovery subsystem such as
* ability to register new providers
* changing static providers should require server reload, or restart of the service providing the DiscoveryProvider
* TBD
> Clustering subsystems integration with WildFly Discovery SPI (tracker Jira)
> ---------------------------------------------------------------------------
>
> Key: WFLY-12222
> URL: https://issues.jboss.org/browse/WFLY-12222
> Project: WildFly
> Issue Type: Task
> Components: Clustering, mod_cluster
> Affects Versions: 17.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Major
>
> Ultimately, we could employ WildFly Discovery SPI to handle services discovery in a generic way. However, since the subsystem currently only supplies one provider based on static discovery, its usefulness is limited. To untangle the chicken-egg problem, we could first integrate the clustering subsystems with the discovery SPI,
> * JGroups discovery
> * remote-cache-container remote servers
> * mod_cluster
> then supply discovery providers,
> * static list (implemented)
> * multicast-based
> * k8s-based (replacing JGroups' OPENSHIFT_PING, DNS_PING, KUBE_PING, etc)
> * cloud providers specific (replacing S3_PING, NATIVE_S3_PING, AZURE_PING, GOOGLE_PING, etc)
> This requires fixes to the discovery subsystem such as
> * ability to register new providers
> * Adding/removing services from static providers should require server reload, or restart of the service providing the DiscoveryProvider
> * TBD
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-12222) Clustering subsystems integration with WildFly Discovery SPI (tracker Jira)
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-12222?page=com.atlassian.jira.plugin... ]
Paul Ferraro updated WFLY-12222:
--------------------------------
Description:
Ultimately, we could employ WildFly Discovery SPI to handle services discovery in a generic way. However, since the subsystem currently only supplies one provider based on static discovery, its usefulness is limited. To untangle the chicken-egg problem, we could first integrate the clustering subsystems with the discovery SPI,
* JGroups discovery
* remote-cache-container remote servers
* mod_cluster
then supply discovery providers,
* static list (implemented)
* multicast-based
* k8s-based (replacing JGroups' OPENSHIFT_PING, DNS_PING, KUBE_PING, etc)
* cloud providers specific (replacing S3_PING, NATIVE_S3_PING, AZURE_PING, GOOGLE_PING, etc)
This requires fixes to the discovery subsystem such as
* ability to register new providers
* changing static providers should require server reload, or restart of the service providing the DiscoveryProvider
* TBD
was:
Ultimately, we could employ WildFly Discovery SPI to handle services discovery in a generic way. However, since the subsystem currently only supplies one provider based on static discovery, its usefulness is limited. To untangle the chicken-egg problem, we could first integrate the clustering subsystems with the discovery SPI,
* JGroups discovery
* remote-cache-container remote servers
* mod_cluster
then supply discovery providers,
* static list (implemented)
* multicast-based
* k8s-based (replacing JGroups' OPENSHIFT_PING, DNS_PING, KUBE_PING, etc)
* cloud providers specific (replacing S3_PING, NATIVE_S3_PING, AZURE_PING, GOOGLE_PING, etc)
This requires fixes to the discovery subsystem such as
* ability to register new providers
* changing static providers should require server reload
* TBD
> Clustering subsystems integration with WildFly Discovery SPI (tracker Jira)
> ---------------------------------------------------------------------------
>
> Key: WFLY-12222
> URL: https://issues.jboss.org/browse/WFLY-12222
> Project: WildFly
> Issue Type: Task
> Components: Clustering, mod_cluster
> Affects Versions: 17.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Major
>
> Ultimately, we could employ WildFly Discovery SPI to handle services discovery in a generic way. However, since the subsystem currently only supplies one provider based on static discovery, its usefulness is limited. To untangle the chicken-egg problem, we could first integrate the clustering subsystems with the discovery SPI,
> * JGroups discovery
> * remote-cache-container remote servers
> * mod_cluster
> then supply discovery providers,
> * static list (implemented)
> * multicast-based
> * k8s-based (replacing JGroups' OPENSHIFT_PING, DNS_PING, KUBE_PING, etc)
> * cloud providers specific (replacing S3_PING, NATIVE_S3_PING, AZURE_PING, GOOGLE_PING, etc)
> This requires fixes to the discovery subsystem such as
> * ability to register new providers
> * changing static providers should require server reload, or restart of the service providing the DiscoveryProvider
> * TBD
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFLY-10042) Elytron tests fail intermittently
by Farah Juma (Jira)
[ https://issues.jboss.org/browse/WFLY-10042?page=com.atlassian.jira.plugin... ]
Farah Juma resolved WFLY-10042.
-------------------------------
Fix Version/s: 17.0.0.Final
Resolution: Done
> Elytron tests fail intermittently
> ---------------------------------
>
> Key: WFLY-10042
> URL: https://issues.jboss.org/browse/WFLY-10042
> Project: WildFly
> Issue Type: Bug
> Components: JMX, Security
> Reporter: Stuart Douglas
> Priority: Major
> Fix For: 17.0.0.Final
>
>
> The JMX MBean server service does not have correct dependencies set on the security domain, and as a result unregistering the Arquillian MBean can fail on reload.
> If this happen all subsequent tests will fail as the Arquillian service will not start correctly.
> An example run is at: https://ci.wildfly.org/viewLog.html?buildId=89151&buildTypeId=WFPR&tab=bu...
> {code}
> 2018-02-12 09:31:55,112 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 31) WFLYUT0022: Unregistered web context: '/chained-principal-transformer-transform-transformed' from server 'default-server'
> 2018-02-12 09:31:55,118 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment chained-principal-transformer-transform-transformed.war (runtime-name: chained-principal-transformer-transform-transformed.war) in 6ms
> 2018-02-12 09:31:55,129 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0002: Content removed from location /store/work/tc-work/9ccd5e119c4a65d0/testsuite/integration/elytron/target/wildfly/standalone/data/content/7b/30341090e956f73f2066f8e357380151a337e8/content
> 2018-02-12 09:31:55,129 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0009: Undeployed "chained-principal-transformer-transform-transformed.war" (runtime-name: "chained-principal-transformer-transform-transformed.war")
> 2018-02-12 09:31:55,563 ERROR [org.jboss.as.arquillian] (MSC service thread 1-8) Cannot stop Arquillian Test Runner: java.lang.IllegalStateException
> at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47)
> at org.jboss.as.controller.access.management.ManagementSecurityIdentitySupplier.get(ManagementSecurityIdentitySupplier.java:60)
> at org.jboss.as.controller.access.management.ManagementSecurityIdentitySupplier.get(ManagementSecurityIdentitySupplier.java:39)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.log(PluggableMBeanServerImpl.java:1180)
> at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.log(MBeanServerAuditLogRecordFormatter.java:331)
> at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.isRegistered(MBeanServerAuditLogRecordFormatter.java:176)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.isRegistered(PluggableMBeanServerImpl.java:784)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.unregisterMBean(JMXTestRunner.java:109)
> at org.jboss.as.arquillian.service.ArquillianService.stop(ArquillianService.java:96)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1767)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.execute(ServiceControllerImpl.java:1740)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1527)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1360)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFCORE-4516) Allow server-identities expression resolution to support Base64 encoded system properties.
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/WFCORE-4516?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-4516:
-------------------------------------
Summary: Allow server-identities expression resolution to support Base64 encoded system properties. (was: The expression for secret value under server-identities in test-security-realm does not work . )
> Allow server-identities expression resolution to support Base64 encoded system properties.
> ------------------------------------------------------------------------------------------
>
> Key: WFCORE-4516
> URL: https://issues.jboss.org/browse/WFCORE-4516
> Project: WildFly Core
> Issue Type: Bug
> Components: Management, Security
> Reporter: Indrajit Ingawale
> Assignee: Darran Lofthouse
> Priority: Major
>
> The expression for secret value under server-identities in test-security-realm does not work , even though it shows "expressions-allowed" to true like below .
> ----------------------------
> [standalone@localhost:9990 /] /core-service=management/security-realm=test-security-realm/server-identity=secret:read-resource-description()
> {
> "outcome" => "success",
> .
> .
> "attributes" =>
> {. . . . . }
> ,
> "value" =>
> { "type" => STRING, "description" => "The secret / password - Base64 Encoded.", "expressions-allowed" => true, "required" => true, "nillable" => true, "alternatives" => ["credential-reference"], "min-length" => 1L, "max-length" => 2147483647L, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "no-services" }
> },
> "operations" => undefined,
> "notifications" => undefined,
> "children" => {}
> }
> }
> ----------------------------
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFCORE-4543) CLI output is doubled after embed-server reload
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFCORE-4543?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-4543:
---------------------------------------
Thanks [~jdenise]. I see what the issue is and I'll look at a fix for it.
> CLI output is doubled after embed-server reload
> -----------------------------------------------
>
> Key: WFCORE-4543
> URL: https://issues.jboss.org/browse/WFCORE-4543
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Logging
> Reporter: Ondrej Kotek
> Assignee: James Perkins
> Priority: Major
>
> CLI output is doubled after embed-server reload:
> {noformat}
> [okotek@localhost wildfly-18.0.0.Beta1-SNAPSHOT]$ ./bin/jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server
> [standalone@embedded /] :whoami
> {
> "outcome" => "success",
> "result" => {"identity" => {"username" => "anonymous"}}
> }
> [standalone@embedded /] reload
> [standalone@embedded /] :whoami
> 12:34:27,735 INFO [org.jboss.as.cli.CommandContext] (CLI command) {
> "outcome" => "success",
> "result" => {"identity" => {"username" => "anonymous"}}
> }
> {
> "outcome" => "success",
> "result" => {"identity" => {"username" => "anonymous"}}
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFCORE-4543) CLI output is doubled after embed-server reload
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFCORE-4543?page=com.atlassian.jira.plugi... ]
James Perkins moved WFLY-12224 to WFCORE-4543:
----------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-4543 (was: WFLY-12224)
Component/s: CLI
Logging
(was: CLI)
(was: Logging)
Affects Version/s: (was: 18.0.0.Beta1)
> CLI output is doubled after embed-server reload
> -----------------------------------------------
>
> Key: WFCORE-4543
> URL: https://issues.jboss.org/browse/WFCORE-4543
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Logging
> Reporter: Ondrej Kotek
> Assignee: Jean Francois Denise
> Priority: Major
>
> CLI output is doubled after embed-server reload:
> {noformat}
> [okotek@localhost wildfly-18.0.0.Beta1-SNAPSHOT]$ ./bin/jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server
> [standalone@embedded /] :whoami
> {
> "outcome" => "success",
> "result" => {"identity" => {"username" => "anonymous"}}
> }
> [standalone@embedded /] reload
> [standalone@embedded /] :whoami
> 12:34:27,735 INFO [org.jboss.as.cli.CommandContext] (CLI command) {
> "outcome" => "success",
> "result" => {"identity" => {"username" => "anonymous"}}
> }
> {
> "outcome" => "success",
> "result" => {"identity" => {"username" => "anonymous"}}
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (WFCORE-4543) CLI output is doubled after embed-server reload
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFCORE-4543?page=com.atlassian.jira.plugi... ]
James Perkins reassigned WFCORE-4543:
-------------------------------------
Assignee: James Perkins (was: Jean Francois Denise)
> CLI output is doubled after embed-server reload
> -----------------------------------------------
>
> Key: WFCORE-4543
> URL: https://issues.jboss.org/browse/WFCORE-4543
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Logging
> Reporter: Ondrej Kotek
> Assignee: James Perkins
> Priority: Major
>
> CLI output is doubled after embed-server reload:
> {noformat}
> [okotek@localhost wildfly-18.0.0.Beta1-SNAPSHOT]$ ./bin/jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server
> [standalone@embedded /] :whoami
> {
> "outcome" => "success",
> "result" => {"identity" => {"username" => "anonymous"}}
> }
> [standalone@embedded /] reload
> [standalone@embedded /] :whoami
> 12:34:27,735 INFO [org.jboss.as.cli.CommandContext] (CLI command) {
> "outcome" => "success",
> "result" => {"identity" => {"username" => "anonymous"}}
> }
> {
> "outcome" => "success",
> "result" => {"identity" => {"username" => "anonymous"}}
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months