When I configure messages to PRE_ACKNOWLEDGE when heading to an array of consumers, do they get removed from the address space immediately or do they hang around for any other reason? I have a client that is misbehaving and locking up. It is not responding with acknowledgements, of course. It is set to AUTO_ACKNOWLEDGE right now.
I'm using JBoss 7.1.3, HornetQ 2.2.21.
Thanks.
PRE-ACKs will set the message to be removed as soon as Netty delivers it to the client.
It seems you're facing https://bugzilla.redhat.com/show_bug.cgi?id=1125042
Related
In my app(multiple instances), we occasionally see the case where connection is lost between my app and rabbitmq due to network issues(my app and rabbitmq are both alive), then after connection is recovered(re-established) we will receive messages that are unacked.
This creates an issue for us, because my app wasn't dead, and it is still processing the same message it received before, but now the message is redeivered, and it causes the app to process the message again (which can be fatal to us).
Since the app has multiple instances, it is not easy for an instance to check if another instance is processing the same message at the same time. We can't simply filter out redelivered message, because we need this feature to handle instance/app crashes/re-deployments.
It doesn't seem that there is an api to tell rabbitmq when to not redeliver unacked messages.
So what is the recommended practice to handle this situation ?
Thanks,
The general solution for such scenario is to make the consumers handle the messages in an idempotent manner . Generally what I do is from the producer side ( in case there is no unique identifier in the message body ) I add an attribute idempotencyId to the message body which is a guid and on the consumer side for each message this id is validated against the stored value in database , any duplicates are rejected.
This approach also works for messages which might be shoveled from another cluster or if in a same cluster multiple instances of consumers are listening then too this approach guarantee one time processing.
Would suggest to go over the RabbitMQ Reliability Guide here
Yeah, exactly-once delivery is not something RabbitMQ is good at. In fact, I'd say you should probably not be using it for these kinds of problems. Honestly, the only way to truly fix this is to use distributed transactions or locking.
Anyway, you could turn the problem on its head by ack'ing the message as soon as the consumer gets it, before it starts working on it. That would avoid the RabbitMQ-related duplication issue at least. This is at-most-once delivery.
Of course, it means that if the consumer crashes, the message is lost forever. So you need to persist the message right before you ack it so you can recover it later and also the consumer should remove it once it's complete.
Considering that crashes are rare, you can then have a single dedicated process that just works on those persisted messages. Or for that matter, handle them manually.
Just be aware that you are pushing the duplication problem in front of you, because the consumer might fail to remove the persisted message after it's done working with it anyway, but at least you have the option to implement it however you want.
Storage in this case could be anything from files, a RDBMS or something like ZooKeeper or Redis to lock/unlock in-flight messages.
i have service which uses NServiceBus to communicate with other services.
My problem is that i am supposed to get X amount of messages and i get X+1 or X+2 or X+3.
This problem occurs when the service is using multiple threads, but when i force this service to use a single thread, i do not have this issue.
I am suspecting RabbitMQ 'thinks' the message failed and resends it, or some other rabbit mechanism is at work here that sends me extra messages.
Are my suspicions valid?
Thank you.
Edit:
I now clearly see that i get the same message twice.
I am using RabbitMQ version 3.0.2 & I see close to 1000 message in Error queue. I want to know
At what point messages are moved to the error queues?
Is there a way to know why a certain message is being moved to an error queue?
Is there any way to move message from error queue to normal queue?
Thank you
a) they fail to deserialize or b) the consumer throws an exception processing that message five times
Not really... If you peek at the message in the queue, the payload headers might contain a note but I don't think we did that. If you turn logging on (NLog, log4net, etc) you should be able to see the exceptions in your log. You'll have to correlate message ids at that point to figure out exactly why.
There is no built in way via MassTransit. Mostly because there doesn't seem to be a great, generic way to handle this. Everyone wants some process around this. Dru did create a BusDriver app (in the main MT source repo) that could be used to move messages back to the exchange in question. This default behaviour is there so you at least know things have been failing if you don't put in the infrastructure to handle it.
To add to Travis' answer, During my development I found some other reasons for messages going onto the error queue:
The published message type has no consumer
A SAGA and a consumer are expecting the same concrete message type. Even if you try and differentiate using "Accepts" and ".Selected", both a SAGA and a Consumer should not be programmed to receive the same message type.
I have a producer sending durable messages to a RabbitMQ exchange. If the RabbitMQ memory or disk exceeds the watermark threshold, RabbitMQ will block my producer. The documentation says that it stops reading from the socket, and also pauses heartbeats.
What I would like is a way to know in my producer code that I have been blocked. Currently, even with a heartbeat enabled, everything just pauses forever. I'd like to receive some sort of exception so that I know I've been blocked and I can warn the user and/or take some other action, but I can't find any way to do this. I am using both the Java and C# clients and would need this functionality in both. Any advice? Thanks.
Sorry to tell you but with RabbitMQ (at least with 2.8.6) this isn't possible :-(
had a similar problem, which centred around trying to establish a channel when the connection was blocked. The result was the same as what you're experiencing.
I did some investigation into the actual core of the RabbitMQ C# .Net Library and discovered the root cause of the problem is that it goes into an infinite blocking state.
You can see more details on the RabbitMQ mailing list here:
http://rabbitmq.1065348.n5.nabble.com/Net-Client-locks-trying-to-create-a-channel-on-a-blocked-connection-td21588.html
One suggestion (which we didn't implement) was to do the work inside of a thread and have some other component manage the timeout and kill the thread if it is exceeded. We just accepted the risk :-(
The Rabbitmq uses a blocking rpc call that listens for a reply indefinitely.
If you look the Java client api, what it does is:
AMQChannel.BlockingRpcContinuation k = new AMQChannel.SimpleBlockingRpcContinuation();
k.getReply(-1);
Now -1 passed in the argument blocks until a reply is received.
The good thing is you could pass in your timeout in order to make it return.
The bad thing is you will have to update the client jars.
If you are OK with doing that, you could pass in a timeout wherever a blocking call like above is made.
The code would look something like:
try {
return k.getReply(200);
} catch (TimeoutException e) {
throw new MyCustomRuntimeorTimeoutException("RabbitTimeout ex",e);
}
And in your code you could handle this exception and perform your logic in this event.
Some related classes that might require this fix would be:
com.rabbitmq.client.impl.AMQChannel
com.rabbitmq.client.impl.ChannelN
com.rabbitmq.client.impl.AMQConnection
FYI: I have tried this and it works.
I'm trying to consume messages on an ActiveMQ topic from a C# application. I'm using the 1.3 .net release, and I don't receive any messages.
I have existing code that uses older libraries (and libraries built on top of libraries that I don't want to use or upgrade) that work fine, so I know messages are travelling along the topic, but my simple program with newer libraries just doesn't see them.
I'm using code copied and pasted from http://remark.wordpress.com/articles/publish-subscribe-with-activemq-and-nms/ as my test. The SimpleTopicSubscriber (with a simple change to make it a non-durable consumer) just doesn't receive anything. The SimpleTopicPublisher works just fine - I can send a simple message and it gets through, no problem.
Looking at the JMX console, I can see my subscriber connect, see that it's on the right topic, but it just doesn't get any messages.
Any ideas? I've even tried using the 1.2 libraries, but that didn't make any difference.
Thanks
Matt
Turns out there were 2 problems. I edited the example code incorrectly and passed in a durable consumer id instead of a selector. Not terribly clever.
Once I'd fixed this, I could receive messages, but only with the 1.1 release of the NMS/ActiveMq dlls. I couldn't receive messages with version 1.2 or 1.3.
But if I pass wireformat.version=2 as a parameter when connecting, everything works ok. The broker is 5.0.0 and I strongly suspect this would work ok with a later version of the broker.
Thanks
Matt
There are a couple reasons why your client might not be receiving messages, one could be that you didn't call Connection.Start(), without that the message pump won't start dispatching messages to your client. The other reason might be that your now non-durable Topic subscriber was started after the publisher in which case there'd be no messages delivered since you are using a Topic and Topics are like queue's in that once a message is sent its forgotten about so a subscriber that joins up later doesn't receive any messages that were sent before it subscribed.
Regards
Tim.
Open Source Integration: http://fusesource.com