I'm using Stomp messaging and am subscribed to a topic in my client/browser code:
stompClient.subscribe('/topic/informer', function(greeting){
showGreeting(JSON.parse(greeting.body).content);
});
I am using a camel route that sends a message to an activemq topic:
I have tried both:
<to uri="activemq:topic:informer"/>
and:
<to uri="stomp:topic:informer"/>
Both simply create a topic in activemq and enqueue the messages there. They never reach the client. To me, this means that the /topic/informer in the client is separate from the topic:informer that I can see in the activemq console. Does anyone know how to link them either by making the subscription to the activemq topic or by changing the camel route to send to the topic referenced by the subscription?
Thank you so much in advance for any tips/advice!
Is your STOMP client connect and subscribed before the message is sent? Topics are not Queues, they don't hold onto sent messages if there is no client subscribed at the time of a send. If you client connects after the message is sent then it will not receive anything unless it is using a durable topic subscription which was created previously.
I have few questions apart from what #Tim has asked.
Which STOMP client library are you using in your client/browser code? The way you specify the topic sometimes changes based on the client library that you are using. Please check client documentation.
From the broker logs, can you see for which topic the subscriber is subscribing to?
If you can see the ActiveMQ console, can you see if there is any other topic that's created with the word "informer" in it? If so, you can easily figure out what's going wrong.
Related
Let me start by describing the system. There are 2 applications, let's call them Client and Server. There are also 2 queues, request queue and reply queue. The Client publishes to the request queue, and the server listens for that request to process it. After the Server processes the message, it publishes it to the reply queue, which the Client is subscribed to. The Server application always publishes the reply to the predefined reply queue, not a queue that the Client application determines.
I cannot make updates to the Server application. I can only update the Client application. The queues are created and managed by the Server application.
I am trying to implement request/reply pattern from Client, such that the reply from the Server is synchronously returned. I am aware of the "sendAndReceive" approach with spring, and how it works with a temporary queue for reply purposes, and also with a fixed reply queue.
Spring AMQP - 3.1.9 Request/Reply Messaging
Here are the questions I have:
Can I utilize this approach with existing queues, which are managed and created by the Server application? If yes, please elaborate.
If my Client application is a scaled app (multiple instances of it are running at the same time), then how do I also implement it in such a way, that the wrong instance (one in which the request did not originate) does not read the reply from the queue?
Am I able to use the "Default" exchange to my advantage here, in addition to a routing key?
Thanks for your time and your responses.
Yes; simply use a Reply Listener Container wired into the RabbitTemplate.
IMPORTANT: the server must echo the correlationId message property set by the client, so that the reply can be correlated to the request in the client.
You can't. Unlike JMS, RabbitMQ has no notion of message selection; each consumer (in this case, reply container) needs its own queue. Otherwise, the instances will get random replies and it is possible (highly likely) that the reply will go to the wrong instance.
...it publishes it to the reply queue...
With RabbitMQ, publishers don't publish to queues, they publish to exchanges with a routing key. It is bad practice to tightly couple publishers to queues. If you can't change the server to publish the reply to an exchange, with a routing key that contains something from the request message (or use the replyTo property), you are out of luck.
Using the default exchange encourages the bad practice I mentioned in 2 (tightly coupling producers to queues). So, no, it doesn't help.
EDIT
If there's something in the reply that allows you to correlate it to a request; one possibility would be to add a delegating consumer on the server's reply queue. Receive the reply, perform the correlation, route the reply to the proper replyTo.
Using kaazing jms demo with AMQP 1.0 AND ActiveMQ
https://demo.kaazing.com/demo/jms/javascript/jms-javascript.html
Register/Subscribe to new Queue and process it for application server and send message back to client[kaazing] from application server.However, client subscribed to same queue did not received any message, any reason why?
I assume you're trying to use two browsers clients: a publisher and a subscriber. I just tested it, and it works fine on the URL you provided above.
A while back I published a 6-minute screencast of the steps. You can see the messages flying back-and-forth at around 3:30.
Is it possible to configure the topic to store a copy of just the last message and send this to new connections without knowing client identifiers or other info?
Update:
From the info provided by Shashi I found this two pages where they describe a use case similar to mine (applied over stock prices) by using retroactive consumer and a subscription recovery policy. How ever I'm not getting the desired behaviour. What I currently do is:
Include in the activemq the folowing lines in the policyEntry for topic=">"
<subscriptionRecoveryPolicy>
<fixedCountSubscriptionRecoveryPolicy maximumSize="1"/>
</subscriptionRecoveryPolicy>
Add to the URL used to connect to the brocker (using activemq-cpp) consumer.retroactive=true.
Set the consumer has durable. (But I strongly think this is not want since I only need the last one, but without it I didn't get any message when starting the consumer for the second time)
Start up the broker.
Start the consumer.
Send a message to the topic using the activemq web admin console. (I receive it in the consumer, as expected)
Stop consumer.
Send another message to the topic.
Start consumer. I receive the message, also as expected.
However, if the consumer receives a message, then it goes offline (stop process) and then I restart it, it doesn't get the last message back.
The goal is to whenever the consumer starts get the last message, no mater what (obviously, except when there weren't messages sent to the topic).
Any ideas on what I'm missing?
Background:
I have a device which publishes his data to a topic when ever its data changes. A variable number of consumer may be connected to this topic, from 0 to less than 10. There is only one publisher in the topic and always publish all of his data as a single message (little data, just a couple of fields of a sensor reading). The publication rate of this information is variable, not necessarily time based, when something changes a new updated message is sent to the broker.
The problem is that when a new consumer connects to the topic it has no data of the device readings until a new message is send to the topic by the device. This could be solve by creating an additional queue so new connections can subscribe to the topic and then request the device for the current reading through the queue (the device would consume the queue message which would be a request for data, and then response in the same queue).
But Since the messages send to the topic are always information complete I was wondering if is it possible to configure the topic to store a copy of just the last message and send this to new connections without know client identifiers or other info?
Current broker in use is ActiveMQ.
What you want is to have retroactive consumers and to set the lastImageSubscriptionRecoveryPolicy subscription recovery policy on the topic. Shashi is correct in saying that the following syntax for setting a consumer to be retroactive works only with Openwire
topic = new ActiveMQTopic("TEST.Topic?consumer.retroactive=true");
In your case, what you can do is to configure all consumers to be retroactive in broker config with alwaysRetroactive="true". I tested that this works even for the AMQP protocol (library qpid-jms-client) and I suspect it will work for all protocols.
<destinationPolicy>
<policyMap>
<policyEntries>
<policyEntry topic="FOO.>" alwaysRetroactive="true">
<subscriptionRecoveryPolicy>
<lastImageSubscriptionRecoveryPolicy />
</subscriptionRecoveryPolicy>
</policyEntry>
The configuration example is taken from https://github.com/apache/activemq/blob/master/activemq-unit-tests/src/test/resources/org/apache/activemq/test/retroactive/activemq-message-query.xml
Messaging providers (WebSphere MQ for example) have a feature called Retained Publication. With this feature the last published message on a topic is retained by the messaging provider and delivered to a new consumer who comes in after a message has been published on a given topic.
Retained Publication may be supported by Active MQ in it's native interface. This link talks about consumer.retroactive which is available for OpenWire only.
A publisher will tell the messaging provider to retain a publication by setting a property on the message before publishing. Below is how it is done using WebSphere MQ.
// set as a retained publication
msg.setIntProperty(JmsConstants.JMS_IBM_RETAIN, JmsConstants.RETAIN_PUBLICATION)
I am using Autobahn to broadcast messages to subscribed clients. However, when a client is NOT connected to the Internet, it is still necessary that they receive the messages when they reconnect. Will I need to use something like RabbitMQ to accomplish this or can Autobahn handle this natively?
AutobahnPython does not persist messages. Retrieval of message history is an upcoming feature in WAMPv2, and a broker with message persistence will be available as part of Crossbar.io.
Disclosure: I am original author of Autobahn, WAMP and Crossbar.io, and work for Tavendo.
I'm trying to set up a bridge between two topics. The idea is this:
A notification gets posted to a topic on HornetQ server A
This notification gets sent to a topic on HornetQ server B (over a
bridge?)
The client app gets the notification from server B.
The reason I need to do this is, if server B is down, we still want the topic up and eventually delivered to the subscribing servers.
What I need is an example hornetq-configuration.xml and hornetq-jms.xml demonstrating this. Or am I looking at it the wrong way and there is a better way to do this?
I am using HornetQ 2.2.14.Final.
Topic is not in the core level, but you can do it; follow this link:
https://community.jboss.org/thread/177979