[jboss-jira] [JBoss JIRA] (WFLY-4866) messaging-activemq: NPE when http-acceptor and https-acceptor configured
Martyn Taylor (JIRA)
issues at jboss.org
Thu Oct 22 09:52:00 EDT 2015
[ https://issues.jboss.org/browse/WFLY-4866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13121041#comment-13121041 ]
Martyn Taylor edited comment on WFLY-4866 at 10/22/15 9:51 AM:
---------------------------------------------------------------
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=TransportConfigOperationHandlers.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}
was (Author: martyn-taylor):
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)
More information about the jboss-jira
mailing list