[
https://issues.jboss.org/browse/WFLY-4866?page=com.atlassian.jira.plugin....
]
Martyn Taylor commented on WFLY-4866:
-------------------------------------
This is actually caused by the TransportConfigOperationHandlers class in the messaging
subsystem. The WildFly acceptor configurations are read in and converted into Artemis
TransportConfiguration objects. However, the SSL field is being lost along the way.
The params.get(HTTP_ACCEPTOR) object contains the HTTP and HTTPS acceptors. As can be
seen below, the SSL information is not getting propagated to the resulting Artemis
TransportConfiguration object. Since, the only difference between the acceptors is the
HTTPS vs HTTP (and this is lost). The resulting Artemis objects are equal.
org.wildfly.extension.messaging.activemq.TransportConfigOperationHandlers.java
Line 258
{code:title=Bar.java|borderStyle=solid}
if (params.hasDefined(HTTP_ACCEPTOR)) {
for (final Property property : params.get(HTTP_ACCEPTOR).asPropertyList()) {
final String acceptorName = property.getName();
final ModelNode config = property.getValue();
final Map<String, Object> parameters = getParameters(context,
config, ACCEPTOR_KEYS_MAP);
parameters.put(TransportConstants.HTTP_UPGRADE_ENABLED_PROP_NAME, true);
acceptors.put(acceptorName, new
TransportConfiguration(NettyAcceptorFactory.class.getName(), parameters, acceptorName));
}
}
{code}
messaging-activemq: NPE when http-acceptor and https-acceptor
configured
------------------------------------------------------------------------
Key: WFLY-4866
URL:
https://issues.jboss.org/browse/WFLY-4866
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 8.1.0.Final, 10.0.0.CR2
Environment: Windows 7 Pro, Java 7u55
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
Labels: JMS, Messaging
Attachments: server-logs.zip
With both an http-acceptor and an https-acceptor configured in the message subsystem,
when an external Java app attempts to connect, it times out and the exception below
appears in the server log.
I tracked it down to the TransportConfigOperationHandlers.processAcceptors() method. At
the end of the method, it creates a HashSet of the TransportConfiguration objects
representing the acceptors. But, the TransportConfiguration equals() method reports that
the https and http acceptors are equal, and as it is building a Set of unique values, the
https-acceptor gets dropped.
Later, when the http-upgrade handshake runs, the code is unable to find the
https-acceptor, resulting in the NullPointerException.
I think the fix might be to either not use a Set, or to look at the
TransportConfiguration.equals() method.
The workaround in the ticket works because the redundant <param> causes the
equals() method to see the two acceptors as unequal.
The exception was:
[exec] 10:07:57,502 ERROR [org.xnio.listener] (default I/O-10) XNIO001007: A channel
event listener threw an exception: java.lang.NullPointerException
[exec] at
org.jboss.as.messaging.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:161)
[exec] at
org.jboss.as.messaging.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:153)
[exec] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
[xnio-api-3.2.2.Final.jar:3.2.2.Final]
[exec] at
io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:149)
[exec] at
io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:271)
[exec] at
io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:221)
[exec] at
io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1131)
[exec] at
io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1351)
[exec] at io.undertow.server.Connectors.terminateResponse(Connectors.java:78)
[exec] at
io.undertow.server.protocol.http.ServerFixedLengthStreamSinkConduit.channelFinished(ServerFixedLengthStreamSinkConduit.java:33)
[exec] at
io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.exitFlush(AbstractFixedLengthStreamSinkConduit.java:273)
[exec] at
io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(AbstractFixedLengthStreamSinkConduit.java:207)
[exec] at
org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
[xnio-api-3.2.2.Final.jar:3.2.2.Final]
[exec] at
io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100)
[exec] at
io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1489)
[exec] at
io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1470)
[exec] at
io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:152)
[exec] at
io.undertow.server.handlers.ProxyPeerAddressHandler.handleRequest(ProxyPeerAddressHandler.java:45)
[exec] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
[exec] at
io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:156)
[exec] at
io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:91)
[exec] at
io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:45)
[exec] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
[xnio-api-3.2.2.Final.jar:3.2.2.Final]
[exec] at
org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
[xnio-api-3.2.2.Final.jar:3.2.2.Final]
[exec] at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
[xnio-nio-3.2.2.Final.jar:3.2.2.Final]
[exec] at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
[xnio-nio-3.2.2.Final.jar:3.2.2.Final]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)