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

messaging-activemq: NPE when http-acceptor and https-acceptor configured

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 10.0.0.CR5
    • 8.1.0.Final, 10.0.0.CR2
    • 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>

    Description

      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]

      Attachments

        Issue Links

          clones

          Bug - A problem that impairs or prevents the functions of the product. WFLY-3965 Messaging: NullPointerException when http-acceptor and https-acceptor configured

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed
          is cloned by

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-1288 messaging-activemq: NPE when http-acceptor and https-acceptor configured

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed
          is blocked by

          ARTEMIS-151 Loading...

          Activity

            People

              jmesnil1@redhat.com Jeff Mesnil
              jmesnil1@redhat.com Jeff Mesnil
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: