2 Replies Latest reply on Feb 13, 2016 1:46 PM by Miroslav Novak

    WildFly 10 JMS client with WildFly 9 broker

    Harald Wellmann Novice

      I have two WildFly 9 instances, let's call them Client and Broker, where Broker acts as a stand-alone message broker, and Client runs a web app sending messages to a queue on Broker via an HTTP connector with an outgoing socket binding.


      Now I'm trying to upgrade the Client to WildFly 10 while leaving the Broker untouched. I've migrated the messaging subsystem of my client configuration. When starting Client, I see the following in the log:


      2016-02-12 11:27:54,800 DEBUG [org.apache.activemq.artemis.core.client] (MSC service thread 1-1) Sending HTTP request DefaultHttpRequest(decodeResult: success, version: HTTP/1.1)

      GET  HTTP/1.1

      Host: ****

      Upgrade: activemq-remoting

      Connection: Upgrade

      httpPpgradeEndpoint: http-acceptor

      Sec-ActiveMQRemoting-Key: i2lLCniGoH7Nx5TuY0XkdA==

      2016-02-12 11:27:54,849 DEBUG [org.apache.activemq.artemis.core.client] (MSC service thread 1-1) Connector towards NettyConnector [host=****, port=80, httpEnabled=false, httpUpgradeEnabled=true, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true] failed


      So it looks like the WIldFly 10 client is trying to persuade the WildFly 9 broker to do an activemq-remoting upgrade, but all the broker is able to do is an hornetq-remoting upgrade.


      Is this scenario supposed to work at all? Is there a configuration option to make the WildFly 10 client talk HornetQ to the old broker?