[JBoss JIRA] (WFLY-7957) Redirecting to external ports such as 443 is not working
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7957?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-7957:
----------------------------------------
You need a socket-binding entry for https-ext.
The add handler for the http-listener should be validating that though. I'll send up a PR to fix that.
> Redirecting to external ports such as 443 is not working
> --------------------------------------------------------
>
> Key: WFLY-7957
> URL: https://issues.jboss.org/browse/WFLY-7957
> Project: WildFly
> Issue Type: Bug
> Components: Web Sockets
> Affects Versions: 10.1.0.Final
> Environment: Windows Server 2012 R2 Standard, 64bit
> Reporter: Bhaskara Undi
> Assignee: Stuart Douglas
>
> 2017-01-24 10:57:17,812 ERROR [io.undertow.request] (default task-1) UT005001: An exception occurred processing the request: java.lang.IllegalStateException: UT010053: No confidential port is available to redirect the current request.
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.getRedirectURI(ServletConfidentialityConstraintHandler.java:80)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:49)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60).........
> ------------------
> <server-identities>
> <ssl>
> <keystore path="edustgkeystore.jks" relative-to="jboss.server.config.dir" keystore-password="pass" alias="server"/>
> </ssl>
> </server-identities>
> -----------------------------
> <subsystem xmlns="urn:jboss:domain:undertow:3.1">
> <buffer-cache name="default"/>
> <server name="default-server">
> <ajp-listener name="listen-ajp" socket-binding="ajp"/>
> <http-listener name="default" socket-binding="http" redirect-socket="https-ext" enable-http2="true"/>
> <https-listener name="https" socket-binding="https" security-realm="SSLRealm" enable-http2="true"/>
> -------------------------------
> <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
> <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
> <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
> <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
> <socket-binding name="http" port="${jboss.http.port:8080}"/>
> <socket-binding name="https" port="${jboss.https.port:8443}"/>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7912) It's not possible to change election-policy of singleton-policy
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-7912?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-7912.
------------------------------
Resolution: Rejected
OK - After further deliberation, I've concluded the current behavior is appropriate. The add operation will translate to a remove + add, where the remove will need to use the allow-resource-service-restart=true flag. Therefore, it makes sense to require the allow-resource-service-restart=true flag for the single add operation, which will propagate to the internal remove + add.
> It's not possible to change election-policy of singleton-policy
> ---------------------------------------------------------------
>
> Key: WFLY-7912
> URL: https://issues.jboss.org/browse/WFLY-7912
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: Tomas Hofman
> Assignee: Paul Ferraro
>
> Attempt to change election policy:
> {code}
> [standalone@localhost:9990 /] batch
> [standalone@localhost:9990 / #] /subsystem=singleton/singleton-policy=default/election-policy=simple:remove
> [standalone@localhost:9990 / #] /subsystem=singleton/singleton-policy=default/election-policy=random:add
> [standalone@localhost:9990 / #] run-batch
> {code}
> results in
> {code}
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error):
> WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:
> Step: step-2
> Operation: /subsystem=singleton/singleton-policy=default/election-policy=random:add
> Failure: WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.singleton.policy.default.election-policy is already registered
> {code}
> The bug seems to be introduced by https://github.com/wildfly/wildfly/commit/605b22c30ae122492e7c019e330fea2...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7957) Redirecting to external ports such as 443 is not working
by Bhaskara Undi (JIRA)
Bhaskara Undi created WFLY-7957:
-----------------------------------
Summary: Redirecting to external ports such as 443 is not working
Key: WFLY-7957
URL: https://issues.jboss.org/browse/WFLY-7957
Project: WildFly
Issue Type: Bug
Components: Web Sockets
Affects Versions: 10.1.0.Final
Environment: Windows Server 2012 R2 Standard, 64bit
Reporter: Bhaskara Undi
Assignee: Stuart Douglas
2017-01-24 10:57:17,812 ERROR [io.undertow.request] (default task-1) UT005001: An exception occurred processing the request: java.lang.IllegalStateException: UT010053: No confidential port is available to redirect the current request.
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.getRedirectURI(ServletConfidentialityConstraintHandler.java:80)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:49)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60).........
------------------
<server-identities>
<ssl>
<keystore path="edustgkeystore.jks" relative-to="jboss.server.config.dir" keystore-password="pass" alias="server"/>
</ssl>
</server-identities>
-----------------------------
<subsystem xmlns="urn:jboss:domain:undertow:3.1">
<buffer-cache name="default"/>
<server name="default-server">
<ajp-listener name="listen-ajp" socket-binding="ajp"/>
<http-listener name="default" socket-binding="http" redirect-socket="https-ext" enable-http2="true"/>
<https-listener name="https" socket-binding="https" security-realm="SSLRealm" enable-http2="true"/>
-------------------------------
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
<socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
<socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
<socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
<socket-binding name="http" port="${jboss.http.port:8080}"/>
<socket-binding name="https" port="${jboss.https.port:8443}"/>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7031) Redirect Port Fails to Redirect to 3rd Party HTTP Port
by Bhaskara Undi (JIRA)
[ https://issues.jboss.org/browse/WFLY-7031?page=com.atlassian.jira.plugin.... ]
Bhaskara Undi commented on WFLY-7031:
-------------------------------------
Hi Joe,
Are you able to fix this issue. If yes can you please share the solution to me. I am also facing the same issue.
Thank you
Bhaskara Undi
> Redirect Port Fails to Redirect to 3rd Party HTTP Port
> ------------------------------------------------------
>
> Key: WFLY-7031
> URL: https://issues.jboss.org/browse/WFLY-7031
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.CR1
> Reporter: Joe Carder
> Assignee: Tomaz Cerar
> Priority: Minor
>
> When setting a redirect socket to port not opened by Wildfly (IE: a port opened by Apache HTTPD or IIS), Wildfly throws the following exception:
> ERROR [io.undertow.request] (default task-2) UT005001: An exception occurred processing the request: java.lang.IllegalStateException: UT010053: No confidential port is available to redirect the current request.
> With the redirect socket to a port opened by JBoss, it works as expected. I'm not 100% sure this is a bug, or functional decision made for Wildfly 10 and is working as expected. However, in Previous Widlfly version (Widlfly 8) it was possible to set the redirect port to a third party service without out issue.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7912) It's not possible to change election-policy of singleton-policy
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-7912?page=com.atlassian.jira.plugin.... ]
Paul Ferraro reopened WFLY-7912:
--------------------------------
Actually - I'm going to reopen this issue. When an add operation triggers a removal of an existing singleton resource, we should ensure that the allow-resource-service-restart flag is enabled.
> It's not possible to change election-policy of singleton-policy
> ---------------------------------------------------------------
>
> Key: WFLY-7912
> URL: https://issues.jboss.org/browse/WFLY-7912
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: Tomas Hofman
> Assignee: Paul Ferraro
>
> Attempt to change election policy:
> {code}
> [standalone@localhost:9990 /] batch
> [standalone@localhost:9990 / #] /subsystem=singleton/singleton-policy=default/election-policy=simple:remove
> [standalone@localhost:9990 / #] /subsystem=singleton/singleton-policy=default/election-policy=random:add
> [standalone@localhost:9990 / #] run-batch
> {code}
> results in
> {code}
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error):
> WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:
> Step: step-2
> Operation: /subsystem=singleton/singleton-policy=default/election-policy=random:add
> Failure: WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.singleton.policy.default.election-policy is already registered
> {code}
> The bug seems to be introduced by https://github.com/wildfly/wildfly/commit/605b22c30ae122492e7c019e330fea2...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-1987) Unable to define specific worker when using http-upgrade
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1987?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1987:
------------------------------------------
[~baranowb] I'm not comfortable with the bit where it adds the "operation" field to the warning. I don't think it's strictly necessary and can be added later if we get significant demand. Concerns are:
1) Too much data. If we eventually add it, IMO the address and op name are sufficient context.
2) The activeStep.operation field is an internal piece of data whose value is not required to have a clear relationship to something the end user provided. So I don't want to expose its contents.
Any failure in Level.parse needs to be handled, as it's a user mistake that shouldn't propagate to the log or disrupt the operation. Probably just treat any bad value as equivalent to Level.ALL. And for bonus points add a warning complaining about the bad header. :)
> Unable to define specific worker when using http-upgrade
> --------------------------------------------------------
>
> Key: WFCORE-1987
> URL: https://issues.jboss.org/browse/WFCORE-1987
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Reporter: Radim Hatlapatka
> Assignee: Bartosz Baranowski
> Labels: downstream_dependency
>
> In EAP 7.0.0, there was possible to define different worker for Undertow listener and Remoting.
> Now it is not possible and results in \[1\].
> The need for having the same XNIO worker used for both Remoting endpoint and Undertow listener used for the http-upgrade should be exposed when doing the configuration changes, either it should be allowed or proper warning shown (at least having it documented in both descriptions and in documentation, including the migration guide), for user to know that such configuration can result in not working remoting calls.
> Note, this change in behaviour was introduced when upgrading to XNIO 3.4.0.Final. This might seem as backward compatibility issue from customer as his original configuration working with EAP 7.0.0 will stop working.
> \[1\]
> {noformat}
> 08:57:12,014 ERROR [org.xnio.listener] (xxx I/O-4) XNIO001007: A channel event listener threw an exception: java.lang.IllegalArgumentException: JBREM000211: Invalid XNIO worker; the worker must match the Remoting Endpoint worker
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:196)
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:184)
> at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:179)
> at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:176)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:79)
> at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:372)
> at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:232)
> at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1247)
> at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1524)
> at io.undertow.server.Connectors.terminateResponse(Connectors.java:100)
> at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
> at Automaticio.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
> at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:192)
> at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:133)
> at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
> at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1673)
> at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1651)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:205)
> at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:95)
> at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:129)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
> 08:57:16,995 ERROR [org.xnio.listener] (xxx I/O-2) XNIO001007: A channel event listener threw an exception: java.lang.IllegalArgumentException: JBREM000211: Invalid XNIO worker; the worker must match the Remoting Endpoint worker
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:196)
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:184)
> at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:179)
> at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:176)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:79)
> at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:372)
> at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:232)
> at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1247)
> at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1524)
> at io.undertow.server.Connectors.terminateResponse(Connectors.java:100)
> at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
> at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
> at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:192)
> at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:133)
> at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> at io.undertow.channels.DetachableStreamSinkC08:57:12,014 ERROR [org.xnio.listener] (xxx I/O-4) XNIO001007: A channel event listener threw an exception: java.lang.IllegalArgumentException: JBREM000211: Invalid XNIO worker; the worker must match the Remoting Endpoint worker
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:196)
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:184)
> at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:179)
> at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:176)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:79)08:57:12,014 ERROR [org.xnio.listener] (xxx I/O-4) XNIO001007: A channel event listener threw an exception: java.lang.IllegalArgumentException: JBREM000211: Invalid XNIO worker; the worker must match the Remoting Endpoint worker
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:196)
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:184)
> at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:179)
> at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:176)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:79)
> at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:372)
> at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:232)
> at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1247)
> at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1524)
> at io.undertow.server.Connectors.terminateResponse(Connectors.java:100)
> at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
> at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
> at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:192)
> at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:133)
> at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
> at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1673)
> at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1651)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:205)
> at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:95)
> at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:129)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
> 08:57:16,995 ERROR [org.xnio.listener] (xxx I/O-2) XNIO001007: A channel event listener threw an exception: java.lang.IllegalArgumentException: JBREM000211: Invalid XNIO worker; the worker must match the Remoting Endpoint worker
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:196)
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:184)
> at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:179)
> at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:176)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:79)
> at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:372)
> at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:232)
> at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1247)
> at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1524)
> at io.undertow.server.Connectors.terminateResponse(Connectors.java:100)
> at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
> at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
> at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:192)
> at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:133)
> at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
> at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1673)
> at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1651)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:205)
> at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:95)
> at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:129)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
> at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:372)
> at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:232)
> at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1247)
> at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1524)
> at io.undertow.server.Connectors.terminateResponse(Connectors.java:100)
> at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
> at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
> at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:192)
> at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:133)
> at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
> at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1673)
> at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1651)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:205)
> at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:95)
> at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
> at org.xnio.ChannelListeners.invokeChannelAutomaticAutomaticListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:129)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
> 08:57:16,995 ERROR [org.xnio.listener] (xxx I/O-2) XNIO001007: A channel event listener threw an exception: java.lang.IllegalArgumentException: JBREM000211: Invalid XNIO worker; the worker must match the Remoting Endpoint worker
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:196)
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider$ConnectionAdaptorImpl.accept(HttpUpgradeConnectionProvider.java:184)Automatic
> at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:179)
> at org.jboss.as.remoting.RemotingHttpUpgradeService$1.handleEvent(RemotingHttpUpgradeService.java:176)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:79)
> at io.undertow.server.protocol.http.HttpReadListener.excAutomatichangeComplete(HttpReadListener.java:372)
> at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:232)
> at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1247)
> at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1524)
> at io.undertow.server.Connectors.terminateResponse(Connectors.java:100)
> at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:197)
> at io.undertow.server.protocol.http.HttpTransferEncoding$3.handleEvent(HttpTransferEncoding.java:195)
> at io.undertow.conduits.HeadStreamSinkConduit.exitFlush(HeadStreamSinkConduit.java:192)
> at io.undertow.conduits.HeadStreamSinkConduit.flush(HeadStreamSinkConduit.java:133)
> at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119)
> at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1673)
> at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1651)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:205)
> at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:95)
> at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListeAutomaticner(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:129)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
> hannel.flush(DetachableStreamSinkChannel.java:119)
> at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1673)
> at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1651)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:205)
> at io.undertow.server.protocol.http2.Http2UpgradeHandler.handleRequest(Http2UpgradeHandler.java:95)
> at io.undertow.server.handlers.DisallowedMethodsHandler.handleRequest(DisallowedMethodsHandler.java:61)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:148)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:129)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:588)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:468)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7912) It's not possible to change election-policy of singleton-policy
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-7912?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-7912.
------------------------------
Resolution: Rejected
Because the remove operation needs to remove a service that will be installed by the replacement election-policy's add operation, you must specify the "allow-resource-service-restart" flag.
e.g.
/subsystem=singleton/singleton-policy=default/election-policy=random:add(){allow-resource-service-restart=true}
> It's not possible to change election-policy of singleton-policy
> ---------------------------------------------------------------
>
> Key: WFLY-7912
> URL: https://issues.jboss.org/browse/WFLY-7912
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: Tomas Hofman
> Assignee: Paul Ferraro
>
> Attempt to change election policy:
> {code}
> [standalone@localhost:9990 /] batch
> [standalone@localhost:9990 / #] /subsystem=singleton/singleton-policy=default/election-policy=simple:remove
> [standalone@localhost:9990 / #] /subsystem=singleton/singleton-policy=default/election-policy=random:add
> [standalone@localhost:9990 / #] run-batch
> {code}
> results in
> {code}
> The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error):
> WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:
> Step: step-2
> Operation: /subsystem=singleton/singleton-policy=default/election-policy=random:add
> Failure: WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.singleton.policy.default.election-policy is already registered
> {code}
> The bug seems to be introduced by https://github.com/wildfly/wildfly/commit/605b22c30ae122492e7c019e330fea2...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2231) Deprecate the realm attribute on RBAC role mappings
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFCORE-2231:
----------------------------------------
Summary: Deprecate the realm attribute on RBAC role mappings
Key: WFCORE-2231
URL: https://issues.jboss.org/browse/WFCORE-2231
Project: WildFly Core
Issue Type: Task
Components: Domain Management, Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 3.0.0.Alpha23
As we migrate to WildFly Elytron the realm attribute in role mapping is no longer relevant and has no meaning in the pure Elytron case and so should be deprecated.
It was originally added so each management interface could be associated with a different security realm and then roles assigned based on which realm was used for authentication.
WildFly Elytron solves this in a different way by allowing different security domains to be used for the management interfaces and then a third domain can optionally be used for the identity to inflow to - this inflowing allows for the role mapping to be re-applied so there is no longer a need for realm specific mappings in the RBAC mappings (which are also now optional).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2230) Realm name not taken into account for RBAC role mapping using legacy security realm.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2230?page=com.atlassian.jira.plugi... ]
Darran Lofthouse moved JBEAP-8491 to WFCORE-2230:
-------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2230 (was: JBEAP-8491)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: 3.0.0.Alpha22
(was: 7.1.0.DR10)
Affects Testing: (was: Regression,Blocks Testing)
> Realm name not taken into account for RBAC role mapping using legacy security realm.
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-2230
> URL: https://issues.jboss.org/browse/WFCORE-2230
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Alpha22
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> Console is not able to connect to management interface.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months