What is the best practice to know if a message that is sent via jmsTemplate.send(new MessageCreator()....
I have an async process where a message is delivered to a queue, then some other third party process picks up the message.
What is best practice to know if the message was delivered, or in a case such as this is it normal to only check for errors?
Related
we are looking at socket io implementation for a chat application.
Finding acknowledgement support to handle missing messages while broadcast we are looking at acknowledgement support.
as per documentation socket io does not have support for callbacks in broadcast / rooms.
e.g. in "Room 1" we send broadcast message to all sockets within that room. how we check without call back that some users/sockets missed the message. and how we will handle that in system.
below code does not work.
io.sockets.in(data.room).emit('message', data, function(responseData){
console.log(responseData);
});
according to below issue
https://github.com/socketio/socket.io-redis/issues/30
Callbacks are not supported when broadcasting.
what are the other methods to handle this scenario.
In order to solve your problem, the messages for a room need to be persisted somewhere, and then re-sent to individual clients as needed.
The most obvious place to store messages is server-side, in a datastore (e.g. Redis). Store each conversation effectively as a list of events, appending new events as they happen.
A simple scheme works as follows:
Each broadcast message has a UUID attached to it. When the server handles a new message, it appends the message to the list for that 'room'.
When a client connects/re-connects, it sends a message (e.g. 'LAST_MESSAGE_RECEIVED') indicating the UUID of the last message it received.
When the server receives one of these 'LAST_MESSAGE_RECEIVED' messages, it checks if that is the latest message for the room, and if not, it emits a message just to that individual socket with an array of the missed messages. The client is now back up-to-date.
Alternative: if you don't need to keep a history after a conversation ends, you could be clever and use the fact that other clients are already storing the messages, and ask the clients to re-send messages in a peer-to-peer kind of way. This avoids you needing to have your own server-side datastore.
I know how to publish simple msg to a Queue or Topic in weblogic JMS and how to get subscribe those msgs. I use standalone Pojo to send and receive the msgs.
Can you tell me if I can force the msg to become a Poison msg? If yes, what is the easiest way to force a msg to get poisoned?
The reason I wish to do so is to test if those poison msgs go to my error Q which I had configured.
I searched alot but fail to find such a demonstration of JMS msgs turning poisoned.
http://docs.oracle.com/cd/E21764_01/apirefs.1111/e13952/taskhelp/jms_modules/queues/ManageQueues.html
Poison messages are implementation-specific, so you'll have to work out what kind of garbage data you need to make your consumers reject it. Perhaps send an empty message, or one of the wrong type (object message vs text message)
A producer is sending many messages to the queue.Now queue has theses messages stored.So before consuming these messages from consumer, if producer wants to delete some messages on queue which he sent it by mistake & he dont want receiver shoul receive this message.how can i achieve this. or any other suggestion,thnx
You should keep your session as transacted, and at the end either commit or rollback.
if you meant to commit and now you need to rollback, then you have a serious design problem with your application which you should review. Doing anything beyond that will require your application to have a database to deal with receives and ignore them, but if you can use a database for that you would have performance issues on accessing data in a sync manner.
One possible way: If the producer knows id of the message to be deleted, then it can just receive that message to remove that message from a queue. But this is not guaranteed to remove the message as consumer might have already received the message before producer realizes the mistake.
I have a question on how JMS is supposed to be used. Here's my case:
I have a queue with multiple consumers
A message gets sent to the queue - f.e. a "login" message
One of the consumers processes the message
Now I want to tell all my systems about the "login" message - i.e. that the user successfully logged in. What I'm currently doing is:
The consumer that processed the message sends a message to a Topic where everybody listens telling them "User x successfully logged in". Let's call this SUCCESS.
Now every system concerned knows that "user x has successfully logged in" due to the SUCCESS message. This is what I want.
However, if I understood JMS message delivery rules right, it is theoretically possible that a message to another topic/queue that relies on the fact that the receiving consumer knows that "user x logged in" could arrive before my SUCCESS message has been received. Even if it was sent after the session.send() call of the SUCCESS message. Is that right?
If so, how are you supposed to implement such a case with JMS?
Any help would be greatly appreciated!
Is that right?
Unfortunately, yes.
If so, how are you supposed to implement such a case with JMS?
Two different approaches come to my mind:
simulate other network protocols - add ACKNOWLEDGE message that every system must sent when it receives SUCCESS message. ACKNOWLEDGE message would be sent to some dedicated topic, and messages that rely on the fact the receiving consumer knows that user x logged in cannot be sent until ACKNOWLEDGE message arrived from that consumer.
send both SUCCESS and further messages on same topic (if that's applicable; other consumers can ignore further messages if they aren't final destination), and give greater priority to SUCCESS message. That should (at least theoretically - JMS API doesn't require this!) guarantee that SUCCESS message arrived prior to messages that rely on the fact the receiving consumer knows that user x logged in. The method that should interest you in this case is Message#setJMSPriority
We have producer which is producing message at a rate faster than cosumer can consume. We are using Spring JMS integration as the consumer side technology stack. Currently we are using AUTO_ACKNOWLEDGE mode.
In the onMessage() method of the listener, upon the receipt we are to planning submit the client side job to a job queue and return from the onMessage() method. This means if a) processing fails or b) our server goes down while processing there is no way for us recover.
We looked at the option of using CLIENT_ACKNOWLEDGE, but this means acknowledging a message with higher timestamp automatically acknowledges all the messages with a less timestamp. This is clearly not desirable for us because a successful processing a message with newer timestamp no way means that all the messages with older timestamp are processed completely. In effect we are looking on per message acknowledgement. However, I read somewhere that this means there is some design flaw.
The other option is to use a SessionAwareMessageListener interface provided by Spring. The contract of using this interface says that if a JMSException is thrown from the onMessage the message will be redelivered. However, I was not completely sure how to use this for our purpose.
While I dig more myself into this, any help from you guys will be greatly appreciated.
Session aware message has following onMessage prototype:
onMessage(Message message, Session session)
Invoke session.recover() for the message redelivery. Upon session.recover() will send all the unacknowledged messages back to the jms destination.