[jboss-jira] [JBoss JIRA] (WFLY-4866) messaging-activemq: NPE when http-acceptor and https-acceptor configured

[Jeff Mesnil (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-4866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13123838#comment-13123838 ] 

Jeff Mesnil edited comment on WFLY-4866 at 10/30/15 10:24 AM:
--------------------------------------------------------------

ARTEMIS-151 introduces a behaviour changes and no longer allows to have identical acceptor configurations (with different names). This means that in WildFly case, the https-acceptor is discarded because it defines the same configuration that the http-acceptor one.


was (Author: jmesnil):
ARTEMIS-151 introduce a behaviour changes and no longer allows to have identical acceptor configurations (with different names). This means that in WildFly case, the https-acceptor is discarded because it defines the same configuration that the http-acceptor one.

> 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
>             Fix For: 10.0.0.CR3
>
>         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)