0 Replies Latest reply on Jul 22, 2017 7:53 PM by abysas

    port-offset in JNDI is ignored

    abysas

      Our company use JBoss EAP 7.0.4

      The messaging subsystem in standalone-ha.xml which is being looked up with JNDI is such:

      <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">

        <server name="default" id-cache-size="30000" async-connection-execution-enabled="true">

          ...

          <remote-connector name="netty" socket-binding="messaging-remote"/>
          <remote-acceptor name="netty" socket-binding="messaging"/>

              <connection-factory name="RemoteConnectionFactory" reconnect-attempts="10" retry-interval-multiplier="1.0" retry-interval="1000" block-on-acknowledge="true" client-failure-check-period="20000" ha="true" entries="java:jboss/exported/jms/RemoteConnectionFactory" connectors="netty"/>

          ...

        </server>
      </subsystem>

       

      The socket binding for "messaging" and "messaging-remote":

      <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
      ...
        <socket-binding name="messaging" port="${messaging.connector.port:5445}"/>

        <socket-binding name="remoting" port="${jboss.remoting.port:4447}"/>

        <outbound-socket-binding name="messaging-remote">
          <remote-destination host="${remote.messaging.server.bind.address:127.0.0.1}" port="${messaging.connector.port:5445}"/>
        </outbound-socket-binding>
      </socket-binding-group>

       

      I set jboss.socket.binding.port-offset=100 for EAP server, and for JMS client try to lookup for "RemoteConnectionFactory" with the following properties (considering the offset):

      Properties props = new Properties();
      props.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");

      props.put(Context.PROVIDER_URL, "remote://localhost:4547");

      InitialContext ctx = new InitialContext(props);

      ConnectionFactory connectionFactory = (ConnectionFactory) ctx.lookup("jms/RemoteConnectionFactory");

       

      Lookup succeeds, but creating session from connection factory fails with exception:

      javax.jms.JMSRuntimeException: Failed to create session factory

      ...

      Caused by: ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ119007: Cannot connect to server(s). Tried with all available servers.]

       

      The detail log reveals that ConnectionFactory receives destination info without port offset:

      01:39:29,623 DEBUG activemq.artemis.core.client.impl.ClientSessionFactoryImpl:766 - Trying reconnection attempt 0/1
      01:39:29,624 DEBUG activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1044 - Trying to connect with connector = org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnectorFactory@2ef3eef9, parameters = {port=5445, localAddress=0.0.0.0, host=127.0.0.1} connector = null
      01:39:29,808 DEBUG artemis.core.remoting.impl.netty.NettyConnector:531 - Started Netty Connector version 4.0.32.Final-redhat-1
      01:39:29,808 DEBUG artemis.core.remoting.impl.netty.NettyConnector:589 - Remote destination: /127.0.0.1:5445
      01:39:30,918 DEBUG activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1013 - Connector towards NettyConnector [host=127.0.0.1, port=5445, httpEnabled=false, httpUpgradeEnabled=false, useServlet=false, servletPath=/messaging/ActiveMQServlet, sslEnabled=false, useNio=true] failed
      01:39:30,935 TRACE activemq.artemis.core.client.impl.ClientSessionFactoryImpl:1236 - Neither backup or live were active, will just give up now
      Session factory tries to use the default binding port 5445, though in fact the valid binding port with offset is 5545.

       

      The only workaround to deal with it I found was:

      a) to set fixed-port attribute:

      <socket-binding name="messaging" port="${messaging.connector.port:5445}" fixed-port="true"/>

      b) explicitly set messaging.connector.port property with offset 5545.

       

      I suspect it is a bug in EAP. Please, fix.