Wymagane porty dla JMS przy użyciu usługi HornetQ (JBoss) do wyświetlania w kontenerze dokowania

Question

Używam programu Docker do łączenia kontenera serwera JMS z innym kontenerem klienta JMS. Ale po uruchomieniu serwera w kontenerze dokowania klient nie może poprawnie połączyć się z serwerem. I narażony port 443 na docker (Czy jest jakiś inny port, który używa JMS?)

mogę z powodzeniem tworzyć destication, ale nie kontekst JMS:

String PROVIDER_URL = "https-remoting://MYDOMAIN:443"; 
... 

/** PASSED **/ 
Destination destination = (Destination) namingContext.lookup(destinationString); 

/** HAS ERROR **/ 
JMSContext context = connectionFactory.createContext(username, password) 

Tutaj jest błąd:

java.nio.channels.UnresolvedAddressException 
    at sun.nio.ch.Net.checkAddress(Net.java:123) 
    at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:621) 
    at io.netty.channel.socket.nio.NioSocketChannel.doConnect(NioSocketChannel.java:176) 
    at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.connect(AbstractNioChannel.java:169) 
    at io.netty.channel.DefaultChannelPipeline$HeadHandler.connect(DefaultChannelPipeline.java:1008) 
    at io.netty.channel.DefaultChannelHandlerContext.invokeConnect(DefaultChannelHandlerContext.java:495) 
    at io.netty.channel.DefaultChannelHandlerContext.connect(DefaultChannelHandlerContext.java:480) 
    at io.netty.channel.ChannelOutboundHandlerAdapter.connect(ChannelOutboundHandlerAdapter.java:47) 
    at io.netty.channel.CombinedChannelDuplexHandler.connect(CombinedChannelDuplexHandler.java:168) 
    at io.netty.channel.DefaultChannelHandlerContext.invokeConnect(DefaultChannelHandlerContext.java:495) 
    at io.netty.channel.DefaultChannelHandlerContext.connect(DefaultChannelHandlerContext.java:480) 
    at io.netty.channel.ChannelDuplexHandler.connect(ChannelDuplexHandler.java:50) 
    at io.netty.channel.DefaultChannelHandlerContext.invokeConnect(DefaultChannelHandlerContext.java:495) 
    at io.netty.channel.DefaultChannelHandlerContext.connect(DefaultChannelHandlerContext.java:480) 
    at io.netty.channel.DefaultChannelHandlerContext.connect(DefaultChannelHandlerContext.java:465) 
    at io.netty.channel.DefaultChannelPipeline.connect(DefaultChannelPipeline.java:847) 
    at io.netty.channel.AbstractChannel.connect(AbstractChannel.java:199) 
    at io.netty.bootstrap.Bootstrap$2.run(Bootstrap.java:165) 
    at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:354) 
    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:353) 
    at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101) 
    at java.lang.Thread.run(Thread.java:745) 

Exception in thread "main" javax.jms.JMSRuntimeException: Failed to create session factory 
    at org.hornetq.jms.client.JmsExceptionUtils.convertToRuntimeException(JmsExceptionUtils.java:98) 
    at org.hornetq.jms.client.HornetQConnectionFactory.createContext(HornetQConnectionFactory.java:149) 
    at org.hornetq.jms.client.HornetQConnectionFactory.createContext(HornetQConnectionFactory.java:130) 
    at com.wpic.uptime.Client.main(Client.java:100) 
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
    at java.lang.reflect.Method.invoke(Method.java:483) 
    at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134) 
Caused by: javax.jms.JMSException: Failed to create session factory 
    at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:673) 
    at org.hornetq.jms.client.HornetQConnectionFactory.createContext(HornetQConnectionFactory.java:140) 
    ... 7 more 
Caused by: HornetQNotConnectedException[errorType=NOT_CONNECTED message=HQ119007: Cannot connect to server(s). Tried with all available servers.] 
    at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:905) 
    at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:669) 
    ... 8 more 

Answer 1

Właśnie znalazłem rozwiązanie tego problemu. Ja też to przeżyłem.

W twoim przypadku problem dotyczy konfiguracji JBoss. W moim przypadku problem dotyczył Wildfly 8.2.

Prawdopodobnie używasz następujący parametr w swoim JBoss: jboss.bind.address = 0.0.0.0

Używam tego parametru w moim JBoss Application Server dla niego do przyjmowania połączeń zewnętrznych z dowolnego adresu IP, ponieważ mój JBoss Application Server jest wystawione w Internecie.

Problem polega na tym, że jeśli nie określisz ustawień JBoss/Wildfly, które adresy IP, które HornetQ powinien zgłosić klientom JMS, którzy wykonują zdalne loockup, HornetQ przyjmie, że IP jest ustawione w pliku jboss.bind.address. W takim przypadku zajmie to, że 0.0.0.0 nie jest prawidłowym adresem IP. Prawdopodobnie pojawi się następujący komunikat w jego dziennika JBoss:

INFO [org.hornetq.jms.server] (ServerService Thread Pool -- 53) HQ121005: Invalid "host" value "0.0.0.0" detected for "http-connector" connector. Switching to "hostname.your.server". If this new address is incorrect please manually configure the connector to use the proper one.

W tym przypadku HornetQ użyje hosta określoną w nazwie urządzenia. Na Linuksie użyje na przykład tego, co jest zdefiniowane w/etc/hostname.

Jest inny problem. Ponieważ zazwyczaj nazwa hosta nie jest prawidłowym hostem w Internecie, można ją rozwiązać na podstawie adresu IP za pośrednictwem usługi DNS.

Następnie zauważ, co prawdopodobnie dzieje się z Tobą: Twój serwer JBoss ma zaplanować wiązanie z 0.0.0.0, twój HornetQ (osadzony w JBoss) próbuje przejąć ten adres IP i nie jest prawidłowym adresem IP, który bierze nazwa hosta twojego serwera. Kiedy twój zdalny klient JMS (który jest poza twoją siecią lokalną) robi lokaup na twoim JBoss, HornetQ raportuje klientowi, że musi szukać zasobów HornetQ na hoście YOUR_HOSTNAME_LOCAL_SERVER, ale kiedy próbuje rozwiązać tę nazwę przez DNS, nie może wówczas następujące awaria:

java.nio.channels.UnresolvedAddressException at sun.nio.ch.Net.checkAddress(Net.java:123) at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:621) at io.netty.channel.socket.nio.NioSocketChannel.doConnect(NioSocketChannel.java:176) at io.netty.channel.nio.AbstractNioChannel$AbstractNioUnsafe.connect(AbstractNioChannel.java:169) at io.netty.channel.DefaultChannelPipeline$HeadHandler.connect(DefaultChannelPipeline.java:1008) at io.netty.channel.DefaultChannelHandlerContext.invokeConnect(DefaultChannelHandlerContext.java:495) at io.netty.channel.DefaultChannelHandlerContext.connect(DefaultChannelHandlerContext.java:480) at io.netty.channel.ChannelOutboundHandlerAdapter.connect(ChannelOutboundHandlerAdapter.java:47) at io.netty.channel.CombinedChannelDuplexHandler.connect(CombinedChannelDuplexHandler.java:168) at io.netty.channel.DefaultChannelHandlerContext.invokeConnect(DefaultChannelHandlerContext.java:495) at io.netty.channel.DefaultChannelHandlerContext.connect(DefaultChannelHandlerContext.java:480) at io.netty.channel.ChannelDuplexHandler.connect(ChannelDuplexHandler.java:50) at io.netty.channel.DefaultChannelHandlerContext.invokeConnect(DefaultChannelHandlerContext.java:495) at io.netty.channel.DefaultChannelHandlerContext.connect(DefaultChannelHandlerContext.java:480) at io.netty.channel.DefaultChannelHandlerContext.connect(DefaultChannelHandlerContext.java:465) at io.netty.channel.DefaultChannelPipeline.connect(DefaultChannelPipeline.java:847) at io.netty.channel.AbstractChannel.connect(AbstractChannel.java:199) at io.netty.bootstrap.Bootstrap$2.run(Bootstrap.java:165) at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:354) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:353) at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101) at java.lang.Thread.run(Thread.java:745)

rozwiązaniem problemu jest skonfigurowanie JBoss, które gospodarz powinien on poinformować o klientów, którzy robią loockup odległa.

W moim przypadku ustawienie dla wildfly jest następujące. Plik standalone.xml należy zmienić:

<subsystem xmlns="urn:jboss:domain:messaging:2.0">  
    <hornetq-server> 
     <security-enabled>true</security-enabled> 
     <journal-file-size>102400</journal-file-size> 

     <connectors> 
     <http-connector name="http-connector" socket-binding="http-remote-jms"> 
      <param key="http-upgrade-endpoint" value="http-acceptor"/> 
     </http-connector> 
     </connectors> 
       ...  
    </hornetq-server> 
</subsystem> 

I

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}"> 
... 
    <outbound-socket-binding name="http-remote-jms"> 
     <remote-destination host="YOUR_REAL_HOSTNAME" port="${jboss.http.port:8080}"/> 
    </outbound-socket-binding> 
</socket-binding-group> 

Należy pamiętać, że nie jestem przy użyciu protokołu HTTPS, ponieważ nie mogłem zrobić JBoss Application Server pracę z https dla JMS.