Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-3965

Messaging: NullPointerException when http-acceptor and https-acceptor configured

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Won't Do
    • Icon: Major Major
    • None
    • 8.1.0.Final
    • JMS
    • Hide

      Configure standalone-full-ha.xml with these acceptors:

      <acceptors>
      <http-acceptor http-listener="undertow-https" name="https-acceptor"/>
      <http-acceptor http-listener="undertow-http" name="http-acceptor"/>
      <http-acceptor http-listener="undertow-http" name="http-acceptor-throughput">
      <param key="batch-delay" value="50"/>
      <param key="direct-deliver" value="false"/>
      </http-acceptor>
      <in-vm-acceptor name="in-vm" server-id="0"/>
      </acceptors>

      And these connectors:

      <connectors>
      <http-connector name="https-connector" socket-binding="https">
      <param key="ssl-enabled" value="true"/>
      <param key="http-upgrade-endpoint" value="https-acceptor"/>
      </http-connector>
      <http-connector name="http-connector" socket-binding="http">
      <param key="http-upgrade-endpoint" value="http-acceptor"/>
      </http-connector>
      <http-connector name="http-connector-throughput" socket-binding="http">
      <param key="http-upgrade-endpoint" value="http-acceptor-throughput"/>
      <param key="batch-delay" value="50"/>
      </http-connector>
      <in-vm-connector name="in-vm" server-id="0"/>
      </connectors>

      And attempt to make a connection on the SSL port from a Java app.

      Show
      Configure standalone-full-ha.xml with these acceptors: <acceptors> <http-acceptor http-listener="undertow-https" name="https-acceptor"/> <http-acceptor http-listener="undertow-http" name="http-acceptor"/> <http-acceptor http-listener="undertow-http" name="http-acceptor-throughput"> <param key="batch-delay" value="50"/> <param key="direct-deliver" value="false"/> </http-acceptor> <in-vm-acceptor name="in-vm" server-id="0"/> </acceptors> And these connectors: <connectors> <http-connector name="https-connector" socket-binding="https"> <param key="ssl-enabled" value="true"/> <param key="http-upgrade-endpoint" value="https-acceptor"/> </http-connector> <http-connector name="http-connector" socket-binding="http"> <param key="http-upgrade-endpoint" value="http-acceptor"/> </http-connector> <http-connector name="http-connector-throughput" socket-binding="http"> <param key="http-upgrade-endpoint" value="http-acceptor-throughput"/> <param key="batch-delay" value="50"/> </http-connector> <in-vm-connector name="in-vm" server-id="0"/> </connectors> And attempt to make a connection on the SSL port from a Java app.
    • Hide

      If a "dummy" <param> is added to the https-acceptor, the JMS connection from the Java app is established and no exception is thrown. I used a redundant tcpNoDelay with its default value of true:

      <http-acceptor http-listener="undertow-https" name="https-acceptor">
      <param key="tcp-no-delay" value="true"/>
      </http-acceptor>

      Show
      If a "dummy" <param> is added to the https-acceptor, the JMS connection from the Java app is established and no exception is thrown. I used a redundant tcpNoDelay with its default value of true: <http-acceptor http-listener="undertow-https" name="https-acceptor"> <param key="tcp-no-delay" value="true"/> </http-acceptor>

      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]

              jmesnil1@redhat.com Jeff Mesnil
              darrenjones_jira Darren Jones (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: