Update Message operation updates the visibility timeout of a message. You can also use this operation to update the contents of a message. A message must be in a format that can be included in an XML request with UTF-8 encoding, and the encoded message can be up to 64 KB in size. This operation was introduced with version 2011-08-18 of the Azure Queue Storage API.
You can construct the
Update Message request as follows. HTTPS is recommended. Replace myaccount with the name of your storage account, and myqueue with the name of your queue.
|Method||Request URI||HTTP version|
Emulated storage service
This operation is supported for SDK 1.6 and later versions.
When you make a request against the emulated storage service, specify the emulator hostname and Queue Storage port as
127.0.0.1:10001, followed by the emulated storage account name.
|Method||Request URI||HTTP version|
You can specify the following parameters on the request URI.
||Required. Specifies the valid pop receipt value returned from an earlier call to the Get Messages or Update Message operations.|
||Required. Specifies the new visibility timeout value, in seconds, relative to server time. The new value must be larger than or equal to 0, and can't be larger than 7 days. The visibility timeout of a message can't be set to a value later than the expiry time. You can update a message until it has been deleted or has expired.|
The following table describes required and optional request headers.
||Required. Specifies the authorization scheme, account name, and signature. For more information, see Authorize requests to Azure Storage.|
||Required. Specifies the Coordinated Universal Time (UTC) for the request. For more information, see Authorize requests to Azure Storage.|
||Requires 2011-08-18 or later. Specifies the version of the operation to use for this request. For more information, see Versioning for the Azure Storage services.|
||Optional. Provides a client-generated, opaque value with a 1-kibibyte (KiB) character limit that's recorded in the Azure Monitor logs when logging is configured. We highly recommend that you use this header to correlate client-side activities with requests that the server receives. For more information, see Monitor Azure Queue Storage.|
The body of the request contains the message data in the following XML format. Note that the message content must be in a format that can be encoded with UTF-8.
<QueueMessage> <MessageText>message-content</MessageText> </QueueMessage>
The response includes an HTTP status code and a set of response headers.
A successful operation returns status code 204 (No Content). For information about status codes, see Status and error codes.
The response for this operation includes the following headers. The response can also include additional, standard HTTP headers. All standard headers conform to the HTTP/1.1 protocol specification.
||This header uniquely identifies the request that was made, and can be used for troubleshooting the request. For more information, see Troubleshooting API operations.|
||Indicates the version of Queue Storage used to run the request. This header is returned for requests made against version 2009-09-19 and later.|
||A UTC date/time value that indicates the time at which the response was initiated. The service generates this value.|
||The pop receipt of the queue message.|
||A UTC date/time value that represents when the message will be visible on the queue.|
||You can use this header to troubleshoot requests and corresponding responses. The value of this header is equal to the value of the
The account owner can perform this operation. Additionally, anyone with a shared access signature who has permission to perform this operation can do so.
Sample request and response
The following request extends the visibility of a queue message by 30 seconds and updates its content.
PUT https://myaccount.queue.core.windows.net/myqueue/messages/663d89aa-d1d9-42a2-9a6a-fcf822a97d2c?popreceipt=AgAAAAEAAAApAAAAGIw6Q29bzAE%3d&visibilitytimeout=30&timeout=30 HTTP/1.1
The request is sent with the following headers:
x-ms-version: 2011-08-18 x-ms-date: Mon, 29 Aug 2011 17:17:21 GMT Authorization: SharedKey myaccount:batcrWZ35InGCZeTUFWMdIQiOZPCW7UEyeGdDOg7WW4= Content-Length: 75
The request is sent with the following XML body:
<QueueMessage> <MessageText>new-message-content</MessageText> </QueueMessage>
After the request has been sent, the following response is returned:
HTTP/1.1 204 No Content Content-Length: 0 Server: Windows-Azure-Queue/1.0 Microsoft-HTTPAPI/2.0 x-ms-request-id: df34a7dd-3cbe-4206-a586-d6de3cf225a7 x-ms-version: 2011-08-18 x-ms-popreceipt: AwAAAAIAAAApAAAAINtMQ29bzAEBAAAA x-ms-time-next-visible: Mon, 29 Aug 2011 17:17:51 GMT Date: Mon, 29 Aug 2011 17:17:21 GMT
Update Message operation fails if the specified message doesn't exist in the queue, or if the specified pop receipt doesn't match the message.
A pop receipt is returned by the
Get Messages operation or the
Update Message operation. Pop receipts remain valid until one of the following events occurs:
The message has expired.
The message has been deleted by using the last pop receipt received, either from
The invisibility time has elapsed and the message has been dequeued by a
Get Messagesrequest. When the invisibility time elapses, the message becomes visible again. If it's retrieved by another
Get Messagesrequest, the returned pop receipt can be used to delete or update the message.
The message has been updated with a new visibility timeout. When the message is updated, a new pop receipt will be returned.
You can use the
Update Message operation to continually extend the invisibility of a queue message. This functionality can be useful if you want a worker role to lease a queue message. For example, if a worker role calls Get Messages and recognizes that it needs more time to process a message, it can continually extend the message’s invisibility until it is processed. If the worker role were to fail during processing, eventually the message would become visible again, and another worker role could process it.