堆棧內存溢出
  簡體   English   中英

無法從一個Wildfly 10應用連接到另一個JMS隊列

[英]Trouble connecting to a remote JMS queue from one wildfly 10 app to another

 原文  2017-08-02 12:44:29  9   1    java/ jms/ wildfly-10/ message-driven-bean

問題描述

我有兩個Wildfly 10服務器正在運行，並且有一個與Jboss和Hornet一起工作的JMS隊列。 在那里，我使用netty連接器，因此我廢棄了所有配置，並獲得了wildfy 10上用於消息傳遞的默認配置。我無法使JMS正常工作。 我還沒有真正找到能滿足我需求的優秀文檔或示例。 希望有人能幫忙。

服務器端

我已在服務器端將wildfly 10服務器設置為使用standalone-full.xml來獲取消息傳遞擴展。

這是與消息傳遞有關的standalone-full.xml內容（默認情況下不添加任何內容） 

<extension module="org.wildfly.extension.messaging-activemq"/>

<subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
        <server name="default">
            <security-setting name="#">
                <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
            </security-setting>
            <address-setting name="#" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/>
            <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="http"/>
            <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http">
                <param name="batch-delay" value="50"/>
            </http-connector>
            <in-vm-connector name="in-vm" server-id="0"/>
            <http-acceptor name="http-acceptor" http-listener="default"/>
            <http-acceptor name="http-acceptor-throughput" http-listener="default">
                <param name="batch-delay" value="50"/>
                <param name="direct-deliver" value="false"/>
            </http-acceptor>
            <in-vm-acceptor name="in-vm" server-id="0"/>
            <jms-queue name="ExpiryQueue" entries="java:/jms/queue/ExpiryQueue"/>
            <jms-queue name="DLQ" entries="java:/jms/queue/DLQ"/>
            <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/>
            <connection-factory name="RemoteConnectionFactory" entries="java:/jms/RemoteConnectionFactory" connectors="http-connector"/>
            <pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/>
        </server>
    </subsystem>

這是我為定義隊列和使用MessageDrivenBean接收消息而編寫的代碼： 

@MessageDriven(activationConfig = { 
  @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
  @ActivationConfigProperty(propertyName = "destination", propertyValue = "java:app/jms/queue/SecServerQ")
})
@JMSDestinationDefinition(
  name = "java:app/jms/queue/SecServerQ",
  interfaceName = "javax.jms.Queue",
  destinationName = "SecServerQ"
)
public class SecServerMDB implements MessageListener
{
  public void onMessage(Message message)
  {
    // my code here
  }
}

我可以在wildfly控制台中看到隊列：

在此處輸入圖片說明

客戶端

我有一個standalone-full.xml消息傳遞部分，它也與我的clientserver上的服務器端配置文件相同。

這是我用來嘗試與服務器端JMS隊列建立連接的代碼。 

public class WildFlyJmsQueueSender
{
  private static final Logger log = LoggerFactory.getLogger(WildFlyJmsQueueSender.class);

  public final static String JMS_CONNECTION_FACTORY_JNDI="jms/RemoteConnectionFactory";
  public final static String JMS_QUEUE_JNDI="jms/queue/SecServerQ";
  public final static String JMS_USERNAME="jmsuser";       //  The role for this user is "guest" in ApplicationRealm
  public final static String JMS_PASSWORD="jms2017Pwd!";
  public final static String WILDFLY_REMOTING_URL="http-remoting://secserver.mydomain.com:8080";

  public void send(IpcoJmsMessage msg, String msgType) throws NamingException, JMSException {

    Context namingContext = null;

    try {
      namingContext = getInitialContext();

      log.debug("Attempting to acquire connection factory {}", JMS_CONNECTION_FACTORY_JNDI);
      ConnectionFactory conFactory = (ConnectionFactory) namingContext.lookup(JMS_CONNECTION_FACTORY_JNDI);
      log.debug("Found connection factory {} in JNDI", JMS_CONNECTION_FACTORY_JNDI);

      log.debug("Attempting to acquire destination {}", JMS_QUEUE_JNDI);
      Destination destination = (Destination) namingContext.lookup(JMS_QUEUE_JNDI);
      log.debug("Found destination {} in JNDI", JMS_QUEUE_JNDI);

      try (JMSContext context = conFactory.createContext(JMS_USERNAME, JMS_PASSWORD)) {
        ObjectMessage objMsg = context.createObjectMessage();
        objMsg.setObject(msg);
        objMsg.setStringProperty("msgType", msgType);

        log.info("Sending message with content msg={}, msgType={}", msg, msgType);

        context.createProducer().send(destination, objMsg);
      }
    } catch (NamingException e) {
      log.error("NamingException: {} {}", e.getMessage(), e);
    } finally {
      if(namingContext != null) {
        try {
          namingContext.close();
        } catch (NamingException e) {
          log.error(e.getMessage());
        }
      }
    }
  }

  private static InitialContext getInitialContext() throws NamingException {
    InitialContext context=null;
    try {
      Properties props = new Properties();
      props.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
      props.put(Context.PROVIDER_URL, WILDFLY_REMOTING_URL);
      props.put(Context.SECURITY_PRINCIPAL, JMS_USERNAME);
      props.put(Context.SECURITY_CREDENTIALS, JMS_PASSWORD);
      context = new InitialContext(props);

      log.debug("Got initial Context: "+context);

    } catch (Exception e) {
      e.printStackTrace();
    }
    return context;
  }

}

這是我在客戶端遇到的異常： 

14:11:04.965 DEBUG [LoggerProviders.java:158] - Logging Provider: org.jboss.logging.Slf4jLoggerProvider
14:11:04.966 INFO  [Version.java:61] - WildFly Naming version 1.0.0.Beta13
14:11:04.969 DEBUG [WildFlyJmsQueueSender.java:82] - Got initial Context: javax.naming.InitialContext@2c7d3911
14:11:04.969 DEBUG [WildFlyJmsQueueSender.java:42] - Attempting to acquire connection factory jms/RemoteConnectionFactory
14:11:05.033 INFO  [Xnio.java:95] - XNIO version 3.5.0.Beta2
14:11:05.043 INFO  [NioXnio.java:57] - XNIO NIO Implementation Version 3.5.0.Beta2
14:11:05.069 DEBUG [WorkerThread.java:433] - Started channel thread 'XNIO-1 Accept', selector sun.nio.ch.EPollSelectorImpl@2883da14
14:11:05.069 DEBUG [WorkerThread.java:433] - Started channel thread 'XNIO-1 I/O-1', selector sun.nio.ch.EPollSelectorImpl@338779b1
14:11:05.081 INFO  [EndpointImpl.java:97] - JBoss Remoting version 5.0.0.Beta19
14:11:05.087 DEBUG [WorkerThread.java:433] - Started channel thread 'Remoting (anonymous) I/O-1', selector sun.nio.ch.EPollSelectorImpl@5375fba8
14:11:05.087 DEBUG [WorkerThread.java:433] - Started channel thread 'Remoting (anonymous) Accept', selector sun.nio.ch.EPollSelectorImpl@331af02b
14:11:05.141 INFO  [Version.java:57] - ELY00001: WildFly Elytron version 1.1.0.Beta33
14:11:05.382 ERROR [WildFlyJmsQueueSender.java:60] - NamingException: {}WFNAM00018: Failed to connect to remote host
javax.naming.CommunicationException: WFNAM00018: Failed to connect to remote host
at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:65) ~[wildfly-naming-client-1.0.0.Beta13.jar:1.0.0.Beta13]
at org.wildfly.naming.client.remote.RemoteContext.lambda$lookupNative$0(RemoteContext.java:109) ~[wildfly-naming-client-1.0.0.Beta13.jar:1.0.0.Beta13]
at org.wildfly.naming.client.NamingProvider.performExceptionAction(NamingProvider.java:99) ~[wildfly-naming-client-1.0.0.Beta13.jar:1.0.0.Beta13]
at org.wildfly.naming.client.remote.RemoteContext.lookupNative(RemoteContext.java:108) ~[wildfly-naming-client-1.0.0.Beta13.jar:1.0.0.Beta13]
at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:78) ~[wildfly-naming-client-1.0.0.Beta13.jar:1.0.0.Beta13]
at org.wildfly.naming.client.AbstractFederatingContext.lookup(AbstractFederatingContext.java:64) ~[wildfly-naming-client-1.0.0.Beta13.jar:1.0.0.Beta13]
at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:144) ~[wildfly-naming-client-1.0.0.Beta13.jar:1.0.0.Beta13]
at javax.naming.InitialContext.lookup(InitialContext.java:417) ~[na:1.8.0_121]
at javax.naming.InitialContext.lookup(InitialContext.java:417) ~[na:1.8.0_121]
at no.ipco.common.WildFlyJmsQueueSender.send(WildFlyJmsQueueSender.java:43) ~[ipco-common-jmsclient-0.1.jar:na]

1 個解決方案

解決方案1
 1  2017-08-02 14:41:02

我解決了問題。

首先，我在MessageDrivenBean服務器端使用@JMSDestinationDefinition。 相反，我使用jboss-cli定義了隊列。

我的standalone-full.xml配置文件現在添加了以下行 

<jms-queue name="SecServerQ" entries="jms/queue/SecServerQ java:jboss/exported/jms/queue/SecServerQ"/>

在客戶端，我切換了端口。 我嘗試通過telnet到8080（舊端口），並且那里沒有開放，所以我嘗試使用28080。 將clientcode修改為： 

public final static String JMS_CONNECTION_FACTORY_JNDI="jms/RemoteConnectionFactory";
public final static String JMS_QUEUE_JNDI="jms/queue/SecServerQ";
public final static String JMS_USERNAME="jmsuser";       //  The role for this user is "guest" in ApplicationRealm
public final static String JMS_PASSWORD="jms2017Pwd!";
public final static String WILDFLY_REMOTING_URL="http-remoting://secserver.mydomain.com:28080";

此后，客戶端可以無任何異常地連接，並且JMS消息開始流動。

暫無
暫無

聲明:本站的技術帖子網頁，遵循CC BY-SA 4.0協議，如果您需要轉載，請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

相關問題 如何在Wildfly 10上查找遠程JMS隊列 JMS + WildFly 8.2.0-從遠程jms隊列讀取 來自遠程 ActiveMQ Artemis 的 Wildfly JMS Consumer 如何在Wildfly 10服務器中以編程方式創建JMS隊列/主題。 在獨立應用程序中為JMS隊列創建遠程使用者 websphere jms隊列從遠程客戶端訪問 如何使用消費者從wildfly jms隊列接收消息 wildfly匿名遠程jms訪問 遠程JMS隊列的客戶端 如何在JBoss的遠程JMS隊列中編寫
相關標簽
 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM