- Java 双重比较
- java - 比较器与 Apache BeanComparator
- Objective-C 完成 block 导致额外的方法调用?
- database - RESTful URI 是否应该公开数据库主键?
我正在尝试从一个 JBoss AS 5.1 实例向另一个实例发送 JMS 消息。对于我的测试,我让它们都在本地主机上运行,客户端 JBoss AS 实例具有正常端口设置,服务器 JBoss AS 具有所有端口都偏移 100 的设置。
在客户端的一个 EAR 项目中,我在我的 EAR 根目录中一个名为 jmstest-service.xml 的文件中定义了一个 JMS 提供程序加载器,其中包含以下内容:
jmstest-service.xml:
<mbean code="org.jboss.jms.jndi.JMSProviderLoader" name="jboss.messaging:service=JMSProviderLoader,name=MyJMSProvider">
<attribute name="ProviderName">MyJMSProvider</attribute>
<attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute>
<attribute name="FactoryRef">java:/XAConnectionFactory</attribute>
<attribute name="QueueFactoryRef">java:/XAConnectionFactory</attribute>
<attribute name="TopicFactoryRef">java:/XAConnectionFactory</attribute>
<attribute name="Properties">
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
java.naming.provider.url=jnp://localhost:1199
</attribute>
</mbean>
在名为 jmstest-ds.xml 的文件中,我为连接工厂定义了一个定义:
jmstest-ds.xml:
<tx-connection-factory>
<jndi-name>MyJmsXA</jndi-name>
<xa-transaction/>
<rar-name>jms-ra.rar</rar-name>
<connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition>
<config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Topic</config-property>
<config-property name="JmsProviderAdapterJNDI" type="java.lang.String">java:/MyJMSProvider</config-property>
<max-pool-size>20</max-pool-size>
<depends>jboss.messaging:service=ServerPeer</depends>
</tx-connection-factory>
启动客户端 JBoss AS 实例时,我看到正在创建连接工厂。因此,我编写了以下代码来发送 JMS 消息:
InitialContext context = new InitialContext();
QueueConnectionFactory factory = (QueueConnectionFactory)context.lookup("java:/MyJmsXA");
QueueConnection connect = factory.createQueueConnection();
QueueSession session = connect.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
Destination destination = (Destination)getRemoteContext().lookup("/queue/nsQueue");
MessageProducer sender = session.createProducer(destination);
ObjectMessage message = session.createObjectMessage("bla");
sender.send(message);
connect.close();
getRemoteContext() 定义为:
InitialContext getRemoteContext() {
Properties env = new Properties();
env.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory" );
env.put(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");
env.put(Context.PROVIDER_URL, "jnp://localhost:1199");
return new InitialContext(env);
}
到这里基本上一切正常。我从 JNDI 获取连接池和远程队列的引用。但是,当我实际尝试发送消息时,它会失败并出现异常:
ERROR [ExceptionUtil] SessionEndpoint[pa-96fhptag-1-8wtzotag-7jdzy7-110j3] send [sa-mdkvptag-1-8wtzotag-7jdzy7-110j3]
javax.jms.JMSException: Failed to route Reference[20928781172555777]:RELIABLE to nsQueue
at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendMessage(ServerConnectionEndpoint.java:757)
at org.jboss.jms.server.endpoint.ServerSessionEndpoint.send(ServerSessionEndpoint.java:399)
at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$send$aop(SessionAdvised.java:87)
at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_7280680627620114891.invokeTarget(SessionAdvised$send_7280680627620114891.java)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
at org.jboss.jms.server.container.SecurityAspect.handleSend(SecurityAspect.java:157)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:122)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.server.endpoint.advised.SessionAdvised.send(SessionAdvised.java)
at org.jboss.jms.wireformat.SessionSendRequest.serverInvoke(SessionSendRequest.java:95)
at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:143)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
at org.jboss.remoting.Client.invoke(Client.java:1724)
at org.jboss.remoting.Client.invoke(Client.java:629)
at org.jboss.remoting.Client.invoke(Client.java:617)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:189)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:160)
at org.jboss.jms.client.delegate.ClientSessionDelegate.org$jboss$jms$client$delegate$ClientSessionDelegate$send$aop(ClientSessionDelegate.java:499)
at org.jboss.jms.client.delegate.ClientSessionDelegate$send_6145266547759487588.invokeTarget(ClientSessionDelegate$send_6145266547759487588.java)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
at org.jboss.jms.client.container.SessionAspect.handleSend(SessionAspect.java:661)
at org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect_z_handleSend_1677669648.invoke(SessionAspect_z_handleSend_1677669648.java)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:92)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.delegate.ClientSessionDelegate.send(ClientSessionDelegate.java)
at org.jboss.jms.client.container.ProducerAspect.handleSend(ProducerAspect.java:269)
at org.jboss.aop.advice.org.jboss.jms.client.container.ProducerAspect_z_handleSend_1677669648.invoke(ProducerAspect_z_handleSend_1677669648.java)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.delegate.ClientProducerDelegate.send(ClientProducerDelegate.java)
at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:164)
at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:207)
at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:145)
at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:136)
at org.jboss.resource.adapter.jms.JmsMessageProducer.send(JmsMessageProducer.java:142)
此时我有点卡住了:(
我尝试稍微调试一下 JMS,它似乎失败的地方是 org.jboss.messaging.core.impl.postoffice.MessagingPostOffice#routeInternal
。此方法接收我的队列的名称 (nsQueue),但某些内部结构不包含对此的任何引用:
private boolean routeInternal(MessageReference ref, Condition condition, Transaction tx, boolean fromCluster, Set names) throws Exception {
if (trace) { log.trace(this + " routing " + ref + " with condition '" +
condition + "'" + (tx == null ? "" : " transactionally in " + tx) +
" from cluster " + fromCluster); }
boolean routed = false;
lock.readLock().acquire();
try
{
List queues = (List)mappings.get(condition);
if (queues != null) // THIS IS INDEED NULL
routeInternal 方法因此返回 false 并抛出上述异常。
如果我从远程服务器请求(默认)连接工厂,那么一切正常。服务器正确发送和接收 JMS 消息。但是,出于性能原因,有必要使用本地连接池。
那么,有没有人知道这里出了什么问题,或者知道为远程 JMS 队列使用连接池的替代方法?
最佳答案
问题是您在提供程序加载程序的定义中使用了 java:/XAConnectionFactory。即使这个名称将被赋予远程 JNDI 初始上下文,它仍然会转到您的 LOCAL JNDI,而不是您认为它将被解析的远程 JNDI。这只是 JNDI 的一个奇怪之处。
你会得到这个异常,因为你本地的邮局正试图找到队列(“nsQueue”),而它显然不知道这一点。正在询问您本地的邮局,因为代码正在使用本地连接工厂,即使您认为它正在使用远程连接工厂也是如此。
只需更改对/XAConnectionFactory 的引用即可。
关于java - 通过连接池将 JMS 消息发送到 JBoss AS 中的远程队列,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/3112165/
我正在读这个 question和 corresponding answer并被答案第一行中的术语 JMS broker 弄糊涂了: MS (ActiveMQ is a JMS broker imple
我正在学习 API 中的 Reactive Streams,我对它与 JMS 之间的相似性感到震惊。在 JMS 中,我们也有异步处理、发布者和订阅者。我在进行这种等效时缺少什么观点? 最佳答案 Rea
假设生产者向 JMS 主题“新闻”发送一条消息。消费者 1 读取了消息,但消费者 2 处于离线状态,因此他还没有读取消息。 是否有任何内置(针对规范或实现)的方式来通知生产者消费者 1 已阅读他的消息
目前我正在开发一个 JMS 应用程序。但我使用普通的 JMS API 和属性文件进行配置。我的应用程序在 Weblogic 中运行并连接到我客户端的 MQ 系列服务器。 最近我知道我可以使用 Webl
我正在尝试使用 Solace 中可用的异步发送功能,但我打算使用 JMS 进行抽象,而不是直接使用 JCSMP 使用它。 JMS 2.0 支持异步发送以及其他新功能:http://www.oracle
我无法获得 javax.jms.ConnectionFactory注入(inject)我的独立 JMS 客户端。 我得到一个 java.lang.NullPointerException在 conne
保持 JMS 连接/ session /消费者始终打开是一种不好的做法吗? 代码草稿示例: // app startup code ConnectionFactory cf = (Connection
我有几个作业,每个作业都有多条消息排队。每个作业的消息随机交错。如果用户决定取消作业,我想从队列中删除属于该作业的所有消息。我已经能够使用 browse() 找到所有要删除的消息,但一直无法弄清楚如何
是否可以将主题配置为仅存储最后一条消息的副本并将其发送到新连接而不知道客户端标识符或其他信息? 更新: 从 Shashi 提供的信息中,我发现这两页使用 retroactive consumer 描述
目前正在使用 WebLogic 和分布式队列。我从文档中了解到,分布式队列允许您使用全局 JNDI 名称检索到集群中任何队列的连接。分布式队列为您提供的主要功能之一似乎是跨多个托管服务器的负载平衡连接
再见,我的基本要求是有一个可以发送消息的路由,并将其放在 JMS 队列中。 camel 上下文在 JavaEE 6 容器中运行,即 JBoss AS 7.1.1,因此它是 HornetQ for JM
我正在阅读 JMS 2.0 规范,其中提到(相关摘录下方)如果客户端尝试修改 Message 对象,则 JMS 提供程序可能会抛出异常。 我的问题是 JMS 提供者如何知道客户端是否试图修改 Mess
我的 spring 上下文文件中有以下设置。 "PowerEventQueue" “${
我正在尝试使用 JSP 连接到 ActiveMQ。但是,当我运行该程序时,它给了我以下类型的异常: NoClassDefFoundError: javax/jms/Destination . 我不确定
我刚看了CORBA和JMS,他们好像都是用来实现的代理架构/模式。 我对他们有几个问题 1.他们之间的区别我还不是很清楚,谁能解释一下? 2.CORBA 是否用于当今的 IT 解决方案?还是正在失去魅
我正在更新现有的 Mule 配置,任务是增强它以根据消息的某些属性将消息路由到不同的端点,因此最好对我手头的两个选项有一些利弊: 在消息上添加属性,使用“message-properties-tran
我有一个订阅 JMS 主题应用程序的 Java 应用程序,该应用程序偶尔会出现以下异常: javax.jms.JMSException: Connection has been terminated
我知道 Camel 的 JMS 组件用于接收消息,使用 Springs DefaultMessageListenerContainer。它可以配置为使用 CLIENT_ACKNOWLEDGE 模式来确
通常不鼓励使用从 JMS 提供者返回的消息 ID 作为相关 ID,将消息发布到队列中。人们如何为请求/响应架构生成相关 ID? 最佳答案 客户端可以使用唯一的 ID 标准,如 UUID生成新的 ID。
我有一个简单的代码可以将 2 条消息放入队列中。 1) 我用两台服务器设置了 connectionNameList。 2) 这两个服务器是独立的,但有相同的队列管理器和定义相同名称的队列,例如“QMg
我是一名优秀的程序员,十分优秀!