Is it possible to consume multiple messages in one call from a Tibco EMS queue. I am using the Receive method of the MessageConsumer class to consume the data currently but this just returns one Message. I'm wondering if there's something that returns an array of Message objects?
Thanks
A queue should not be treated as an inbound array object... mostly because the number of such objects could be massive... and such behaviors would be in direct contradiction with the basic "atomic information piece" notions of messaging. Queues should really be seen as an input "faucet" providing a flux of information.
That said : You might be looking for the javax.jms.QueueBrowser facility object. It IS in contradiction of typical messaging patterns, but can be useful. (Rules are meant to be broken sometimes, are they not ?)
Here is a link to many related examples.
EMS is a JMS provider, so these examples can be used with it.
To retrieve specific messages (to put in an array ?), you could then use a "receive" with message selectors (ex: on the message ID)
UPDATE : There is also this non-jms response : Use the Native EMS API to purge.
Related
I'm trying to send and receive messages to channels/topics whose destination names are in a database, so they can be added/modified/deleted at runtime, but I'm surprised I have found little on the web. I'm using Spring Cloud Streams to allow to change the underlying broker.
To send messages to dynamically bound destinations I'm going with BinderAwareChannelResolver.resolveDestination(target).send(message), but I haven't found something that works like it to receive messages.
My questions are:
1. Is there something similar?
2. how can the message be processed periodically as #StreamListener does?
3. And not as important, but can you create a subscriber automatically in case there is none?
Thanks for any help!
This is a bit out of scope of the original design of the framework. But I would further question your architecture. . . If you truly desire to subscribe to unlimited amount of destinations I wonder why? What is the underlying business requirement?
Keep in mind that even if we were to do it somehow that would require creation of a message listener container dynamically for each new destination which would raise more questions, such as, how long would such container have to live since eventually you would run out of resources.
If, however, you simply asking about possibility of mapping multiple destinations to a single channel so all messages go to the same message handler (e.g., StreamListener), then you can simply use input destination property and define multiple destination delimited by comas.
I am trying to implement an application(Java) which will subscribe to different message types (XMLs) from other different applications via TIBCO EMS. Each of these message types will have a specific purpose. I am of the opinion that I should have multiple queues with multiple subscribers in my application, however, the TIBCO guy is adamant that there should be only one queue where all of these messages will be published and I will have one subscriber and the subscriber then should have logic to different tasks based on the XML received.
Which approach is better? One with multiple queues and subscribers OR the one queue and one subscriber? Please let me know reasons for the choice.
Thanks!
-Naveen
In general, if the same application is reading all the messages, it is much cleaner for that application to have a single input queue instead of multiple input queues. With multiple then the application will need to have logic to know which order to process the queues and so on. With one input queue, the messaging system can deal with the order of the messages - whether FIFO or by priority etc, and the application can just read the next message and process it.
Use unique message header for each type of xml while sending the message. And use message selectors / filters while receiving the same, so that it can be routed / delegated to the respective handler based on the header value. This way, you will be able to handle different type of xml messages by single queue as well.
I'm new to JMS and HornetQ.
I'm wondering if there is a way to implement Message Translator Pattern using HornetQ to split data from a message in a set of smaller data and send them. I explored Bridge and Divert solutions but I can't get how to do it using org.hornetq.core.server.cluster.Transformer and org.hornetq.core.server.ServerMessage. Where can I find some docs about it? Am I looking in the right direction?
In short no(I've no Idea on camel). You cannot modify the jms body once sent until its consumed by a client(body is immutable). However you can change message headers and message properties. The org.hornetq.core.server.cluster.Transformer interface is used for modifying the headers/properties. Hence you are left with two options.
Consume the message, chunk the message based on your algorithem and send to other queues or put back to the queue(but be careful to avoid loop, by having suitable selector).
Other approach is chunk the message then send with message property to differentiate the message. And use the diverter with filter based on the message property(you can use exclusive/non exclusive strategy to send only/send copy of message to the other queue.)
Say I have one JMS message FooCompleted
{"businessId": 1,"timestamp": "20140101 01:01:01.000"}
and another JMS message BazCompleted
{"businessId": 1,"timestamp": "20140101 01:02:02.000"}
The use case is that I want some action triggered when both messages have been received for the business id in question - essentially a join point of reception of the two messages. The two messages are published on two different queues and order between reception of FooCompleted and BazCompleted may change. In reality, I may need to have join of reception of several different messages for the businessId in question.
The naive approach was that to store the reception of the message in a db and check if message(s) its dependent join arm(s) have been received and only then kick off the action desired. Given that the problem seems generic enough, we were wondering if there is a better way to solve this.
Another thought was to move messages from these two queues into a third queue on reception. The listener on this third queue will be using a special avataar of DefaultMessageListenerContainer which overrides the doReceiveAndExecute to call receiveMessage for all outstanding messages in the queue and adding messages back to the queue whose all dependent messages have not yet arrived - the remaining ones will be acknowledged and hence removed. Given that the quantum of messages will be low, probing the queue over and adding messages again should not be a problem. The advantage would be avoiding the DB dependency and the associated scaffolding code. Wanted to see if there is something glaringly bad with this
Gurus, please critique and point out better ways to achieve this.
Thanks in advance!
Spring Integration with a JMS message-driven adapter and an aggregator with custom correlation and release strategies, and a peristent (JDBC) message store will provide your first solution without writing much (or any) code.
Is there any option to change queue order without using out of box "Resequencer"? Maybe it can be done using JMS client to get last message in queue instead of first?
I think that you should give more info about what you're trying to achieve...
Anyway if you read the specs of some JMS implementation like MQ you'll see that the FIFO order is not guaranteed at 100%.
That means that if you relay on the order of the messages received, you can get easily in trouble.
It's good practice to add a progressive number to the message header and use it to handle the messages as you please. If you adopt this solution you have 2 options to achieve your goal:
1) modify the receiver business logic to check the the header of the message;
2) (probably the cleaner approach if you're using MQ) use something called MESSAGE SELECTOR.
Message Selectors allow content based retrieval of specific messages using SQL92-query functions. MQ spec states:
The JMS message provides a facility to provide user-defined metadata
to the JMS message header (outside the actual body of the message).
JMS programs can take advantage of this facility to select a subset
of messages based on a selection criteria or, in other words, a JMS
client can choose only those messages that it is interested in.
Here some more info about the implementation of the two solutions...
The property that you're probably interested in and that you should set before sending the message is JMSCorrelationID that will be set to 1 for the first message, 2 for the second one and so on.
1) Since you're more interested in the message selector, you can skip to the next bullet. Anyway just for reference, if you decide to adopt the solution 1 you can find some good reference in:
http://activemq.apache.org/maven/apidocs/org/apache/activemq/ActiveMQQueueBrowser.html
2) Message Selector.
Your message selector will be an sql string like: JMSCorrelationID = max(JMSCorrelationID)
If you wanna implement a message selector in java the syntax is:
MessageConsumer consumer = session.createConsumer(destination, messageSelectorString, true);
ActiveMQObjectMessage objMsg = (ActiveMQObjectMessage) consumer.receiveNoWait();