like if there is a DivideByZzero exception so it requires a code fix and if the code gets fixed will it tries to resend the same message again
Related
I am trying to simply Get a message off an Azure Storage Queue and then delete it using the REST API.
I can retrieve the message and get a popreceipt but when I try and use this to delete the message, I keep getting, "The specified message does not exist."
In the documentation (https://learn.microsoft.com/en-us/rest/api/storageservices/delete-message2) it looks like you only have to supply the popreceipt however further down the page, it says,
After a client retrieves a message with the Get Messages operation, the client is expected to process and delete the message. To delete the message, you must have two items of data returned in the response body of the Get Messages operation:
The message ID, an opaque GUID value that identifies the message in
the queue.
A valid pop receipt, an opaque value that indicates that the message has been retrieved.
So this implies you do need to send the MessageId as well but there is nothing in the docs that specifies where to place the messageid.
The URI in the docs says to pass DELETE to
https://myaccount.queue.core.windows.net/myqueue/messages/messageid?popreceipt=string-value and I have tried replacing messageid with the actual messageid from the GET but this does not seem to be correct.
Has anyone used this and can explain why I always get "The specified message does not exist" when trying to DELETE the message off the queue or am I missing something?
When GET message /dequeue a message is requested, the message becomes
invisible for certain amount of time .In this mean time ,if it is
not deleted in process which dequeued ,it will be visible again as
said by #gaurav mantri and have a chance to be picked up by another
process i.e ; when you perform get message operation with a visibility timeout reached, another message object is returned with a new pop_receipt .
So please check the time, when you dequeue the message and wait if
the time is out or delete it on time as sometimes encoding process
may take more time than the message invisibility timeout.
Also please note that the maximum timeout interval for Queue service
operations is 30 seconds. If the server timeout interval elapses
before the service has finished processing the request, the service
returns an error.
For the next process pop receipt is updated and so using old one
gives error error code 404 (Not Found) because message with a
matching pop receipt wont be found .
So please check by gradually increasing the invisibility timeout.
References:
Queue getmessage fails - some messages only. (microsoft.com)
Setting timeouts for Queue service operations (REST API) - Azure
Storage | Microsoft Docs
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 would like to know if IBM Worklight has out of the box support for not propagating the error details to the client in the response.
To illustrate, let's suppose that while processing a request, per some reason something went wrong and the server responds it with a body similar to:
{"errors":["Some exception/error details go here..."],"isSuccessful":false,"warnings":[],"info":[]}
However, I don't want the consumer to be aware of the such details, neither to inflate my response with it. Does IBM Worklight provide any way to change such behaviour and, for example, send the errors array empty or at least to transform it before sending the response to the client?
Worklight server responds to requests from the client. Depending on the case, this may be a valid response to the request or an error message, in case something did not go as per plan. Note that in this case, the response flow enters the failure callback of the listener.
The error message is passed back in a format understood by the developer such that they can account for these and take corrective actions. This message is not intended for the end user, but for the developer to handle. In case the message is too descriptive ( or too technical), it is left to the developer to show a generic or proper message.
For example, instead of "An exception was thrown because the input parameter is wrong" can be presented to the end user as "Please verify your input..." .
In case the error is resulting from the adapter - when adapter receives an error from the backend, it can be checked and modified at the adapter, before passing back to the client. Similarly, if errors from exceptions at the adapter can be caught and handled, custom responses can be sent back to the client.
If the error results from exceptions or other conditions, Worklight server cannot be configured to the send errors array empty or transform the response before sending the response to the client. This is for the developer to handle at client side.
We have a system in production where one of the message processing services is hanging up.
Symptoms:
Service using 100% CPU
Restart of service doesn't resolve
A message handler is called but never finished
We've looked at the code and it appears to be endless loop bug in the message handler. Is there any way to configure NServiceBus to timeout handler processing and move the message to the error queue if the handler doesn't complete in a specified time?
Was the message being processed on the infinite loop copied wholesale from the error queue?
I have seen this behavior before.
When you copy a message from the error queue back onto the input queue manually it does something weird with the message header which results in this hapenning.
Just upgraded to a new version of RabbitMQ -- 2.3.1 -- and now the following error occurs:
PRECONDITION_FAILED unknown delivery tag 1
...followed by the channel closing. This worked on an older RabbitMQ with no client-side changes.
In terms of application behavior:
When App A wants to send an async message to App b and receive an answer from B, this is the algorithm:
App A generate a unique ID and puts it in the message object
Then App A subscribes to a new Queue with both the queue name and routing key equals to the uuid.
App B open the message, do some calculations and return the result to the channel with the routkey that it recieved.
App A gets the answer and close the queue.
So far everything went really well in 1.7.0. what went wrong in 2.3.1?
When Application A calls basicPublish(), application B immediately throws the following exception:
com.rabbitmq.client.ShutdownSignalException: channel error; reason: {#method<channel.close>(reply-code=406,reply-text=PRECONDITION_FAILED - unknown delivery tag 1,class-id=60,method-id=80),null,""}
at com.rabbitmq.client.impl.ChannelN.processAsync(ChannelN.java:191)
at com.rabbitmq.client.impl.AMQChannel.handleCompleteInboundCommand(AMQChannel.java:159)
at com.rabbitmq.client.impl.AMQChannel.handleFrame(AMQChannel.java:110)
at com.rabbitmq.client.impl.AMQConnection$MainLoop.run(AMQConnection.java:438)
Caused by: com.rabbitmq.client.ShutdownSignalException: channel error; reason: {#method<channel.close>(reply-code=406,reply-text=PRECONDITION_FAILED - unknown delivery tag 1,class-id=60,method-id=80),null,""}
The only codepath that can cause that exception is through the broker handling a 'basic.ack', so this sounds like a client issue; check the client code.
In particular, check that you aren't ack'ing messages more than once. Doing so is in violation of the AMQP 0-9-1 spec:
A message MUST not be acknowledged more than once. The receiving peer MUST validate that a non-zero delivery-tag refers to a delivered message, and raise a channel exception if this is not the case
A great place to ask such questions is the rabbitmq-discuss mainling-list; all the RabbitMQ developers read that list and make a point of not leaving questions unanswered.
It's also worth noting that previous versions of Rabbit were more lax and did not throw an error in this case, but more recent versions do.
Just set noAck: false on BasicConsume method