Hi i am new to ActiveMQ,
We are using Active MQ-5.8.0 as message broker for our system.My requirement is to get a alert mail if the number of messages in a particular Queue exceeds some specified number(configurable) . So i found that that we can use QueueBrowser to get the list of messages.
Below is the code snippet:
enum1 = TestQBrowser.getEnumeration();
int count = 0;
while(enum1.hasMoreElements()){
count++;
enum1.nextElement();
}
if(count>5)
sendMail("Queue has more pending message than threashold 5");//logic to send alert mail.
This was working as expected previously but i found a strange number (1113762 messages) in queue however when i checked the same with ActiveMQ admin console there are only 100 message.
Can you please help me why i am getting this high count of messages. Is there any problem with the way i did or some problem with QueueBrowser??
P.S : This is my first question in StackOverflow , this question might be basic one but i have been spending a lot of time on this issue.
There is a bug in ActiveMQ 5.8 that causes this. You need to move to version 5.9.0 if you want to reliably use the QueueBrowser to try and do this. However you will still probably run into issues if the Queue is to deep as there is no guarantee that the browser will return all the messages since it must work within the configured memory limits which can cause it to stop paging in messages from the store.
Check out How can I monitor ActiveMQ, there are many possibilities.
Probably the Advisory Messages are the best for your requirement.
Related
I'm searching for few hours now about how to retrieve informations in a RabbitMQ exchange.
Let me explain my goal :
I designed a system to avoid burning gmail API calls limits (per second) in my application. To do so I set up a cron which scale the sendings in an hour : basically I defined a delay in my cron and then push my data into a delayed-queue which is itself bound to the x-delayed-exchanger (type direct). This part is working pretty well.
In addition, I have a consumer which consumes and send the emails from my queue. It's perfectly working too.
My problem come here : Some manual actions coming from my users need to be send ASAP. That so, I want to retrieve the few next delayed messages which are going to be sent from my delayed exchange to the queue and put this new message between the two next delayed message :
As an example :
my-delayed-exchange has [message1: will be published in 3000ms, message2: will be published in 6000ms]: I want to insert messageToSendAsap: will be published in 4500ms] that way I'll be insure that I control my API limits.
Does anyone hear about a method to achieve this ?
Thank you in advance
PS : I code in NodeJS with the amqp lib
Based on the example on the github page of the plugin, you can simply set the x-delay value to 1 (I think it cannot be zero). That is if you are sending message M1 with delay of X and message M2 with delay of Y, so that Y < X the message M2 will be delivered to queue(s) before M1.
Also if you want the message to be sent right away (so not in-between the next two as you wrote in your example) you can simply have another "classical" direct exchnage (without any delays).
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.
We are currently evaluating RabbitMQ. Trying to determine how best to implement some of our processes as Messaging apps instead of traditional DB store and grab. Here is the scenario. We have a department of users who perform similar tasks. As they submit work to the server applications we would like the server app to send messages back into a notification window saying what was done - to all the users, not just the one submitting the work. This is all easy to do.
The question is we would like these message to live for say 4 hours in the Queue. If a new user logs in or say a supervisor they would get all the messages from the last 4 hours delivered to their notification window. This gives them a quick way to review what has recently happened and what is going on without having to ask others, "have you talked to John?", "Did you email him is itinerary?", etc.
So, how do we publish messages that have a lifetime of x hours from the time they were published AND any new consumers that connect will get all of these messages delivered in chronological order? And preferably the messages just disappear after they have expired from the queue.
Thanks
There is Per-Queue Message TTL and Per-Message TTL in RabbitMQ. If I am right you can utilize them for your task.
In addition to the above answer, it would be better to have the application/client publish messages to two queues. Consumer would consume from one of the queues while the other queue can be configured using per queue-message TTL or per message TTL to retain the messages.
Queuing messages you do to get a message from one point to the other reliable. So the sender can work independently from the receiver. What you propose is working with a temporary persistent store.
A sql database would fit perfectly, but also a mongodb would work nicely. You drop a document in mongo, give it a ttl and let the database handle the expiration.
http://docs.mongodb.org/master/tutorial/expire-data/
RabbitMQ ticks all the boxes for the project I am planning, save one. I would have different workers listening on a queue and it is important that they process the newest messages (i.e., latest sequence number) first (LIFO).
My application is such that newer messages pretty much obsolete older messages. If you have workers to spare you could still process the older messages but it is important the newer ones are done first.
After trawling the various forums and such I can only see one solution and that is for a client to process a message it should first:
consume all messages
re-order them according to the sequence number
re-submit to the queue
consume the first message
Ugly and problematic if the client dies halfway. But mabye somebody here has a better solution.
My research is based (in part) on:
http://groups.google.com/group/rabbitmq-discuss/browse_thread/thread/e79e77d86bc7a3b8?fwc=1
http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2010-July/007934.html
http://groups.google.com/group/rabbitmq-discuss/browse_thread/thread/e40d1069dcebe2cc
http://old.nabble.com/Priority-Queue-implementation-and-performance-td29946348.html
Note: the expected traffic of messages will roughly be in the range of 1 msg/hour for some queues and 100/minute for others. So nothing stellar.
Since there is no reply I guess I did my homework rather well ;)
Anyway, after discussing the requirements with the other stakeholders it was decided I can drop the LIFO requirement for now. We can worry about that when it comes to it.
A solution that we will probably end up adopting is for the worker to open a second queue that the master can use to let the worker know what jobs to ignore + provide additional control/monitoring information (which it looks like we will need anyway).
The RabbitMQ implementing the AMQP 1.0 spec may also help here.
So I will mark this question as answered for now. Somebody else is still free to add or improve.
One possibility might be to use basic.get in a loop and wait for the response basic-ok.message-count to become zero (throwing away all other messages):
while (<get ok> = <call basic.get>) {
if (<get ok>.message-count == 0) {
// Now <get ok> is the most recent message on this queue
break;
} else if (<is get-empty>) {
// Someone else got it
}
}
Of course, you'd have to set up the message routing patterns on the broker such that 1 consumer throwing away messages doesn't mess with another. Try to avoid re queueing messages as they will re queue at the top of the stack, making them look like the most recent.
Getting this WCF error, and no idea how to fix it:
System.ServiceModel.CommunicationException: The sequence has been terminated by the remote endpoint. The user specified maximum retry count for a particular message has been exceeded. Because of this the reliable session cannot continue. The reliable session was faulted.
Any ideas welcome :(
From the error message, it would appear that you're using reliable messaging. One of its features is that if a message transfer fails, it will be retried - up to a maximum number of attempts.
Obviously, in your setup, this max number has been maxed out. This might indicate a problem with the network, or your service code, or both. Really hard to tell from here without knowing what you're doing and what your setup is......
I guess the main question would be: do you really need the reliable messaging feature? What are you trying to achieve with this? If you could turn it off, you wouldn't be seeing those errors... can you switch to some other mechanism, maybe message queueing (MSMQ)? Or can you rearchitect your app so you can live with the odd chance that one message might get delivered "out of band" ?