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.
Related
I am using spring/stomp/websocket framework to notify users of messages asynchronously. I have done this successfully. However, I would be get ACK from the client so that some server side action can take place when this is done.
The flow is roughly as flows:
Service notifies a specific user about a decision and updates a record in the DB with status = "notified"
Client receives the message (using stompClient.subscribe(...))
Client acknowledges that the message was received.
The service "knows" that this message was acknowledged and updates the status to "ACK" in the DB.
stompClient.connect({login:'guest', passcode:'guest'},
function(frame) {
setConnected(true);
**var headers = {ack: 'client'};**
...
stompClient.subscribe('/user/guest/response',function(notification) {
//doSomething
}), **headers**);
}
In the service, the message is sent:
this.messagingTemplate.convertAndSendToUser(user, "/response",msg, map);
Is there a way to handle the client ACK on the server side?
Alternatively, I tried to do a
stompClient.send("/app/response/ack/"+messageId);
on the client, in the method that handles the subscription, but in vain.
Can someone please tell me what is standard way to handle acknowledgments? I have been struggling with this for a a couple of days and any thoughts would be very helpful.
Thanks!
Use the ACK frame as per spec. The server sends an ack:some_id header, the client uses that some_id in the ACK frame.
The answer is no for simple broker.
https://docs.spring.io/spring/docs/current/spring-framework-reference/html/websocket.html
The simple broker is great for getting started but supports only a
subset of STOMP commands (e.g. no acks, receipts, etc.), relies on a
simple message sending loop, and is not suitable for clustering. As an
alternative, applications can upgrade to using a full-featured message
broker.
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.
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