Could I search any particular message in solace JMS queue and then process in prior to other messages? Do we have such functionality w.r.t to solace queue.
There isn't such a functionality to search a solace queue for messages. These are designed for messages to be processed in the order in which the are received.
You can use a QueueBrowser to get a static snapshot of the messages and process those messages you want prior to others. Using selectors might help too, if it is applicable for your search use-case. But only the native Java implementation of the Solace API can delete messages; a JMS QueueBrowser doesn't provide that.
Related
We are using Solace as messaging broker. How can I get the number of times a message is delivered from broker? In Jboss, there is a property called JMSXDeliveryCount. Is there anything similar in Solace?
The Solace JMS API is compliant with JMS1.1.
Unfortunately, JMSXDeliveryCount is an optional property in the JMS1.1 specification that is not implemented by the Solace JMS API.
For now, you can keep track of redelivered messages with JMSRedelivered, which does not provide the count.
If you are worried about application handling of "poisonous" messages - messages which cannot be consumed for some reason and need to be redelivered, you can make use of the "Max Redelivery" feature on the Solace endpoints. Messages will be moved to the Dead Message Queue or even configured to be discarded, when the message has been redelivered above the "Max Redelivery" count.
Support for JMSXDeliveryCount is in Solace's feature candidate list, and is likely to be implemented in a future release.
I am using ActiveMQ messaging broker and I have a requirement where the producer application would want to know if the consumer application consuming on the particular destination is up or not?
How can I achieve this?
Thanks!
You should checkout Advisory messages. It's a topic you can subscribe to if you want updates on such events.
Specifically the topic: ActiveMQ.Advisory.NoConsumer.Queue should be of interest. You need to enable it broker side though using the destination policy property: sendAdvisoryIfNoConsumers.
You can do that by using java code as follows:
Destination class has a method getConsumers() which will return List of Subscriptions to that destination,and it will in turn give you consumer information, by this you can check whether your required consumer is active or not.
Good luck!
I am developing an application in which I have jms message queue.
There is a producer which enqueue message to the queue and a consumer to dequeue the message.
There might be cases when consumer is not running. If a message is not consumed by the consumer within a certain amount of time I need to catch that from producer.
I want to use JMX to monitor message queue's message whether it is expired.
Any suggestion or sample code how to this.....
It depends on the JMX implementer... Some servers provide JMX implementations to monitor its resources. If its not provided, then you will need to write the JMX implementation that uses the API provided by the MQ implementer.
An easier way to solve this problem is to use the request-response pattern with expiry. The consumer needs to respond in a specified internal of time. If it can't then the message on the queue can expire. If the response is not received the producer can take further action. JMS selector with correlation ID can be used to relate the responses with the request.
I read the hornetQ documentation, confused a lot. Can someone give an exact example to create a JMS topic in hornetQ. I mean the xml configurations in hornetq-jms.xml and hornetq-configuration.xml. assume we have a topic named top and 2 subscribers named: sub1, sub2. what I get is that we should define two queues(one for each subscribers) and bind them to an address which is the topic name actually, but how the subscriber would know they should connect to which one?(They only know the topic name)
I think you are confused by the way HornetQ handles topics internaly in contrast to the way the JMS specification describes topics.
Let's start with the JMS specification. Here you have one topic, where n subscribers can listen to the messages, that will be published by a client. In JMS we talk only about the destination in singular, eg. we'll send a message to the topic, or the queue respectively.
HornetQ is a JMS Provider - a server that implements the JMS specification, so Java-clients can connect to it, and use the JMS-API. The JMS Provider might change, but the code should still work when using another JMS provider.
However, HornetQ does not distinguish internally the destinations (topic or queue), since it tries to be a generic messaging middleware. In HornetQ all topics or queues are implemented as "addresses" and "queues". When you use the HornetQ API (CoreAPI) instead of the JMS-API, you have to deal with such things. You should read the Address section in the HornetQ documentation:
In core, there is no concept of a Topic, Topic is a JMS only term.
Instead, in core, we just deal with addresses and queues.
For example, a JMS topic would be implemented by a single address to
which many queues are bound. Each queue represents a subscription of
the topic. A JMS Queue would be implemented as a single address to
which one queue is bound - that queue represents the JMS queue.
For an example how to use a topic with JMS via HornetQ, I stongly recommend the examples that come with HornetQ itself. After donwloading and extracting the hornetq archive, just go to the examples/jms/topic directory and see the readme.html for a brief overview how to implement and how to execute the example (mvn verify).
I wonder what is the correct way to subscribe to a Topic using Spring.
I tried with a DefaultMessageListenerContainer, using a non-durable subscription, but it fails most of the time. There is an open bug (SPR-7833) that seems to point out it will not work for non-durable topic subscriptions.
Is there any alternative to the DMLC that supports auto-reconnection in case of failure?
By the way, I'm creating the DMLC programmatically, connecting to an embedded ActiveMQ 5.5.1 broker using the Failover Transport for automatic reconnection. Consuming messages from Queues work as expected even in the most bizarre scenarios, but no luck with Topics.