I play with nsqd a little bit and met the prob mentioned in the title. But when I send message via single nsqd, there is no such prob. Does this mean message should always be sent via same nsqd?
Here is my project. https://github.com/hoozecn/nsqd-cluster
It's resolved by set a higher MaxInFlight value.
ref: https://github.com/nsqio/nsq/issues/1213
Related
I've got following error while trying to send a message to a specific telegram channel:
TimedOut: Timed out
The read operation timed out
the method which I used from python-telegram-bot was send_message.
Although my bot got this error but it still sent the message to the channel and because I did not catch that exception all data from the message was lost but I really need to remove my messages from that channel after a specific period of time.
Is this OK that the bot sent the message even though it got Timed Out? How can I prevent this from happen again or remove this kind of messages from the channel after being sent?
Time out errors mean that TG didn't send a response to your send_message request quick enough. It does not necessarily mean that the request wasn't processed - that's why the message may still be sent. However, without response from TG, you don't have the message id of the resulting message and it will be hard to impossible to delete it.
You can try to increase the time that PTB waits for a response from TG. THis can be done in different ways:
with the timeout parameter of send_message
with Defaults.timeout, if you're using PTBs Defaults setup
by specifying it via the request_kwargs that you pass to Updater
You may want to have a look at this wiki page on networking.
Disclaimer: I'm currently the maintainer of python-telegram-bot
After a couple of hours reading here and there, and passing timeout=30 to context.bot.send_audio and getting an error that says unknown parameter even though send_audio's docs clearly states it takes a timeout param, I found that you can fix this by passing the timeouts to the Application upon building it:
application = ApplicationBuilder()
.token(bot_data["token"])
.read_timeout(30)
.write_timeout(30)
.build()
This fixed my bot. Hope this helps you as well.
I'm following one of the RabbitMQ RPC tutorials (https://www.rabbitmq.com/tutorials/tutorial-six-dotnet.html) and got a little confused around Correlation ID matching.
The tutorial states:
That's when the CorrelationId property is used. We're going to set it to a unique value for every request. Later, when we receive a message in the callback queue we'll look at this property, and based on that we'll be able to match a response with a request. If we see an unknown CorrelationId value, we may safely discard the message - it doesn't belong to our requests.
But why is it "safe" to discard the message after we've already consumed it from the queue? What about the client that is expecting that message? Shouldn't the message be re-queued to prevent loss?
Sounds resonable. But after a requeue it will not be quaranteed that the sender of the original message will receive it. Without more knowledge about the setup of exchanges, bindings and queues it is hard to tell if requeuing makes sense or not.
The above linked tutorial intentionally seems not to cover this complex problem. I think it would be out of scope for a tutorial that tells the reader how to technically use the RPC feature of RabbitMQ.
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).
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.
hi
I cannot see any explanation of the implementation of the collapse_key.
I think i understand what it does but not how it do it!
Android Cloud to Device Messaging Framework
I have a C2DM framework set up and sending 4 types of messages to many phones.
String messages very basic looks kind of like this:
type:name:uuid
type:name:uuid:number
type:uuid:id
If the phone is off many of this can get piled up waiting for phone on-line.
as far as i can tell my system works but what will the collapse_key do for me here?
addEncodedParameter(sb, "collapse_key", "no_ide_what_to_put_here");
You mentioned retrying the same message 3 times and using the same key value. It doesn't really have to be the same message. If you've got a message that indicates the current price of a stock, for instance, and you really only care about the latest price, then you could send different messages with the same key. When the device comes back online, it only gets the latest price quote message.
This may have been what you were saying already, but wanted to make it clear it's not only for "retrying sending same message".
I found this text: “collapse key” used for overriding old messages with the same key on the Google C2DM servers" I think if im retrying sending same message 3 times I must use same key value right. Google cloud server will send the latest msg with the same key value
...but be aware of the following (from http://code.google.com/intl/sv-SE/android/c2dm/):
"Note that since there is no guarantee of the order in which messages get sent, the "last" message may not actually be the last message sent by the application server."
But maybe this is not an issue if you don't generate a lot of messages.