I'm trying to subscribe to a topic using durable and shared enabled, so that multiple instance can be connected to a topic to increase the scalability.
However, only the first instance getting connected without any errors, the second instance message listener keeps throwing the below error messages. I checked with my Webmethods counterpart and he found that the client state was disabled and that's why second listener was not able to connect using the same subscription name.
Can someone throw light on this issue please.
18:14:15,050 WARN
[org.springframework.jms.listener.DefaultMessageListenerContainer]
(DefaultMessageListenerContainer-145) Setup of JMS message listener
invoker failed for destination 'topicName' - trying to recover. Cause:
[BRM.10.2209] JMS: Durable subscription
"connectionFactory##subscriptionName" is in use.
The message
JMS: Durable subscription "connectionFactory##subscriptionName" is in use.
typically hints at a misconfiguration of your Topic on Broker. Please check (with MWS) that the Topic really has "Shared State=true“:
Then make sure your Connection Factory has a „Connection Factory Client ID“ set:
And finally you should set the following JVM setting:
-Dcom.webmethods.jms.clientIDSharing=true
Related
I am new to PCF and need some help understanding the root cause of an issue I am facing.
We have one PCF application that is connecting to Rabbit MQ (no binding done on the Rabbit MQ service yet). the messages get passed through the application to queues created on this Rabbit MQ instance. so far so good.
But when we bind again the application to the same Rabbit MQ instance and restage the application, it starts getting connected to a different messaging instance and the message is being relayed to that messaging service and no message transfer happened on expected Rabbit MQ instance although I can't see the actual movement of messages because I might not be having access to the mystery messaging service (I say that because two spring boot services are communicating as expected and the process gets completed).
I am clueless as to what is changing in the application by binding it to Rabbit MQ. is it a default spring implementation of spring AMQP which is interfering here? what can I do to stop this behavior? I haven't provided any parameters while binding the app to Rabbit MQ.
I tried to put the loggers to find out the name of the exchange it's getting connected to but it's still the same exchange, but I can't see the messages flowing and can't explain the phenomenon to the client.
Try to look at the service key of the your rabbit instance and that will give you hostname etc. i.e. rabbitmq details where you are connecting to after binding.
cf service-key SERVICE_INSTANCE SERVICE_KEY
Not sure if there is any default setting in the app that's being used for setting up the connection to a different rabbit instance in absence of binding.
I have developed a Spring Integration Application which is running in multiple instance of PCF.
The application listens to the topic and process the message.
I use MqConnectionFactory for Topic connection and Spring JMS - DefaultMessageListenerContainer for listener message.
On Durable Subscription - With Same Client ID.
The first instance of the application runs without any issue and process the message.
Other instance, I am getting the following Error.
2429 - MQRC_SUBSCRIPTION_IN_USE
When I have different Client ID , Every instance of the application get the same copy of message resulting in duplicate processing - The idea of running multiple instance is to share the load and process parallel.
On Enabling Shared Subscription along with Durable Subscription - With Same Client ID.
Every instance is getting the following error.
JMSWMQ2025 Failed to subscribe to the topic due to the exception occurred
reason '2432' MQRC_SUB_ALREADY_EXIST.
I want to automatically read/receive messages from solace queue/topic if any message produced or published when my application is up. So is there any method in solace which can open connection automatically if there is any message available in Queue/Topic.
So is there any method in solace which can open connection automatically if there is any message available in Queue/Topic
This is not possible for JMS.
JMS applications initiate a connection to the broker and receive messages over the locally initiated connection.
The only way to do what you want is to use REST instead of JMS.
When a REST consumer is configured, the Solace event broker will initiate a HTTP connection to the application.
A sample can be found here:
https://solace.com/samples/solace-samples-rest-messaging/publish-subscribe/
We are unable to publish JMS message on Solace topic.We are ale to create Solace topic on Solace client UI.
But unable to send message on it.
we are getting below error message.
****WARN | Setup of JMS message listener invoker failed for destination 'topic1' - trying to recover.
Cause: Error creating consumer - operation not supported on router (Capability Mismatch: Router does not support temp endpoints or session not yet connected.)****
This error occurs when the application is attempting to create a MessageConsumer for a temporary endpoint, but the client does not have the right capabilities.
To resolve this, you will need to enable the "Allow Guaranteed Endpoint Create" capability in the client-profile that this client is using. You can enable this with SolAdmin, or with the Solace CLI.
I have problems creating a durable subscription to a topic in RabbitMQ using the Qpid JMS client.
I tried the following:
session.createDurableSubscriber( topic, "name" );
but I get a JMSAMQException with the message "Queue bound query failed: Woken up due to class javax.jms.JMSException"
Does anyone know the correct way to set up a durable subscriber using Qpid JMS client connecting to RabbitMQ?
This looks to be a Qpid JMS client bug.
The createDurableSubscriber path is making use of a Qpid specific extension to the AMQP specification which RabbitMQ does not support (specifically exchange.bound). In order for interoperability, it should be guarding such calls in a similar way to QPID-5224.
I'd suggest reporting this on the Qpid users list and raising a JIRA/submitting a patch.