Service Bus messaging exceptions
This article lists the .NET exceptions generated by .NET Framework APIs.
The messaging APIs generate exceptions that can fall into the following categories, along with the associated action you can take to try to fix them. The meaning and causes of an exception can vary depending on the type of messaging entity:
- User coding error (System.ArgumentException, System.InvalidOperationException, System.OperationCanceledException, System.Runtime.Serialization.SerializationException). General action: try to fix the code before proceeding.
- Setup/configuration error (Microsoft.ServiceBus.Messaging.MessagingEntityNotFoundException, System.UnauthorizedAccessException. General action: review your configuration and change if necessary.
- Transient exceptions (Microsoft.ServiceBus.Messaging.MessagingException, Microsoft.ServiceBus.Messaging.ServerBusyException, Microsoft.ServiceBus.Messaging.MessagingCommunicationException). General action: retry the operation or notify users. The
RetryPolicyclass in the client SDK can be configured to handle retries automatically. For more information, see Retry guidance.
- Other exceptions (System.Transactions.TransactionException, System.TimeoutException, Microsoft.ServiceBus.Messaging.MessageLockLostException, Microsoft.ServiceBus.Messaging.SessionLockLostException). General action: specific to the exception type; refer to the table in the following section:
The following table lists messaging exception types, and their causes, and notes suggested action you can take.
|Exception Type||Description/Cause/Examples||Suggested Action||Note on automatic/immediate retry|
|TimeoutException||The server didn't respond to the requested operation within the specified time, which is controlled by OperationTimeout. The server may have completed the requested operation. It can happen because of network or other infrastructure delays.||Check the system state for consistency and retry if necessary. See Timeout exceptions.||Retry might help in some cases; add retry logic to code.|
|InvalidOperationException||The requested user operation isn't allowed within the server or service. See the exception message for details. For example, Complete() generates this exception if the message was received in ReceiveAndDelete mode.||Check the code and the documentation. Make sure the requested operation is valid.||Retry doesn't help.|
|OperationCanceledException||An attempt is made to invoke an operation on an object that has already been closed, aborted, or disposed. In rare cases, the ambient transaction is already disposed.||Check the code and make sure it doesn't invoke operations on a disposed object.||Retry doesn't help.|
|UnauthorizedAccessException||The TokenProvider object couldn't acquire a token, the token is invalid, or the token doesn't contain the claims required to do the operation.||Make sure the token provider is created with the correct values. Check the configuration of the Access Control Service.||Retry might help in some cases; add retry logic to code.|
|One or more arguments supplied to the method are invalid.
The URI supplied to NamespaceManager or Create contains path segment(s).
The URI scheme supplied to NamespaceManager or Create is invalid.
The property value is larger than 32 KB.
|Check the calling code and make sure the arguments are correct.||Retry doesn't help.|
|MessagingEntityNotFoundException||Entity associated with the operation doesn't exist or it has been deleted.||Make sure the entity exists.||Retry doesn't help.|
|MessageNotFoundException||Attempt to receive a message with a particular sequence number. This message isn't found.||Make sure the message hasn't been received already. Check the deadletter queue to see if the message has been deadlettered.||Retry doesn't help.|
|MessagingCommunicationException||Client isn't able to establish a connection to Service Bus.||Make sure the supplied host name is correct and the host is reachable.
If your code runs in an environment with a firewall/proxy, ensure that the traffic to the Service Bus domain/IP address and ports isn't blocked.
|Retry might help if there are intermittent connectivity issues.|
|ServerBusyException||Service isn't able to process the request at this time.||Client can wait for a period of time, then retry the operation.||Client may retry after certain interval. If a retry results in a different exception, check retry behavior of that exception.|
|MessagingException||Generic messaging exception that may be thrown in the following cases:
An attempt is made to create a QueueClient using a name or path that belongs to a different entity type (for example, a topic).
An attempt is made to send a message larger than 256 KB.The server or service encountered an error during processing of the request. See the exception message for details. It's usually a transient exception.
The request was terminated because the entity is being throttled. Error code: 50001, 50002, 50008.
|Check the code and ensure that only serializable objects are used for the message body (or use a custom serializer).
Check the documentation for the supported value types of the properties and only use supported types.
Check the IsTransient property. If it's true, you can retry the operation.
|If the exception is due to throttling, wait for a few seconds and retry the operation again. Retry behavior is undefined and might not help in other scenarios.|
|MessagingEntityAlreadyExistsException||Attempt to create an entity with a name that is already used by another entity in that service namespace.||Delete the existing entity or choose a different name for the entity to be created.||Retry doesn't help.|
|QuotaExceededException||The messaging entity has reached its maximum allowable size, or the maximum number of connections to a namespace has been exceeded.||Create space in the entity by receiving messages from the entity or its subqueues. See QuotaExceededException.||Retry might help if messages have been removed in the meantime.|
|RuleActionException||Service Bus returns this exception if you attempt to create an invalid rule action. Service Bus attaches this exception to a deadlettered message if an error occurs while processing the rule action for that message.||Check the rule action for correctness.||Retry doesn't help.|
|FilterException||Service Bus returns this exception if you attempt to create an invalid filter. Service Bus attaches this exception to a deadlettered message if an error occurred while processing the filter for that message.||Check the filter for correctness.||Retry doesn't help.|
|SessionCannotBeLockedException||Attempt to accept a session with a specific session ID, but the session is currently locked by another client.||Make sure the session is unlocked by other clients.||Retry might help if the session has been released in the interim.|
|TransactionSizeExceededException||Too many operations are part of the transaction.||Reduce the number of operations that are part of this transaction.||Retry doesn't help.|
|MessagingEntityDisabledException||Request for a runtime operation on a disabled entity.||Activate the entity.||Retry might help if the entity has been activated in the interim.|
|NoMatchingSubscriptionException||Service Bus returns this exception if you send a message to a topic that has pre-filtering enabled and none of the filters match.||Make sure at least one filter matches.||Retry doesn't help.|
|MessageSizeExceededException||A message payload exceeds the 256-KB limit. The 256-KB limit is the total message size, which can include system properties and any .NET overhead.||Reduce the size of the message payload, then retry the operation.||Retry doesn't help.|
|TransactionException||The ambient transaction (Transaction.Current) is invalid. It may have been completed or aborted. Inner exception may provide additional information.||Retry doesn't help.|
|TransactionInDoubtException||An operation is attempted on a transaction that is in doubt, or an attempt is made to commit the transaction and the transaction becomes in doubt.||Your application must handle this exception (as a special case), as the transaction may have already been committed.||-|
QuotaExceededException indicates that a quota for a specific entity has been exceeded.
Queues and topics
For queues and topics, it's often the size of the queue. The error message property contains further details, as in the following example:
Microsoft.ServiceBus.Messaging.QuotaExceededException Message: The maximum entity size has been reached or exceeded for Topic: 'xxx-xxx-xxx'. Size of entity in bytes:1073742326, Max entity size in bytes: 1073741824..TrackingId:xxxxxxxxxxxxxxxxxxxxxxxxxx, TimeStamp:3/15/2013 7:50:18 AM
The message states that the topic exceeded its size limit, in this case 1 GB (the default size limit).
For namespaces, QuotaExceededException can indicate that an application has exceeded the maximum number of connections to a namespace. For example:
Microsoft.ServiceBus.Messaging.QuotaExceededException: ConnectionsQuotaExceeded for namespace xxx. <tracking-id-guid>_G12 ---> System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: ConnectionsQuotaExceeded for namespace xxx.
There are two common causes for this error: the dead-letter queue, and non-functioning message receivers.
Dead-letter queue A reader is failing to complete messages and the messages are returned to the queue/topic when the lock expires. It can happen if the reader encounters an exception that prevents it from calling BrokeredMessage.Complete. After a message has been read 10 times, it moves to the dead-letter queue by default. This behavior is controlled by the QueueDescription.MaxDeliveryCount property and has a default value of 10. As messages pile up in the dead letter queue, they take up space.
To resolve the issue, read and complete the messages from the dead-letter queue, as you would from any other queue. You can use the FormatDeadLetterPath method to help format the dead-letter queue path.
Receiver stopped. A receiver has stopped receiving messages from a queue or subscription. The way to identify this is to look at the QueueDescription.MessageCountDetails property, which shows the full breakdown of the messages. If the ActiveMessageCount property is high or growing, then the messages aren't being read as fast as they are being written.
A TimeoutException indicates that a user-initiated operation is taking longer than the operation timeout.
Timeouts are expected to happen during or in-between maintenance operations such as Service Bus service updates (or) OS updates on resources that run the service. During OS updates, entities are moved around and nodes are updated or rebooted, which can cause timeouts. For service level agreement (SLA) details for the Azure Service Bus service, see SLA for Service Bus.
Queues and topics
For queues and topics, the timeout is specified either in the MessagingFactorySettings.OperationTimeout property, as part of the connection string, or through ServiceBusConnectionStringBuilder. The error message itself might vary, but it always contains the timeout value specified for the current operation.
The MessageLockLostException is thrown when a message is received using the PeekLock Receive mode and the lock held by the client expires on the service side.
The lock on a message may expire due to various reasons -
- The lock timer has expired before it was renewed by the client application.
- The client application acquired the lock, saved it to a persistent store and then restarted. Once it restarted, the client application looked at the inflight messages and tried to complete these.
In the event of a MessageLockLostException, the client application can no longer process the message. The client application may optionally consider logging the exception for analysis, but the client must dispose off the message.
Since the lock on the message has expired, it would go back on the Queue (or Subscription) and can be processed by the next client application which calls receive.
If the MaxDeliveryCount has exceeded then the message may be moved to the DeadLetterQueue.
The SessionLockLostException is thrown when a session is accepted and the lock held by the client expires on the service side.
The lock on a session may expire due to various reasons -
- The lock timer has expired before it was renewed by the client application.
- The client application acquired the lock, saved it to a persistent store and then restarted. Once it restarted, the client application looked at the inflight sessions and tried to process the messages in those sessions.
In the event of a SessionLockLostException, the client application can no longer process the messages on the session. The client application may consider logging the exception for analysis, but the client must dispose off the message.
Since the lock on the session has expired, it would go back on the Queue (or Subscription) and can be locked by the next client application which accepts the session. Since the session lock is held by a single client application at any given time, the in-order processing is guaranteed.
A SocketException is thrown in the following cases:
- When a connection attempt fails because the host did not properly respond after a specified time (TCP error code 10060).
- An established connection failed because connected host has failed to respond.
- There was an error processing the message or the timeout is exceeded by the remote host.
- Underlying network resource issue.
The SocketException errors indicate that the VM hosting the applications is unable to convert the name
<mynamespace>.servicebus.chinacloudapi.cn to the corresponding IP address.
Check to see if below command succeeds in mapping to an IP address.
PS C:\> nslookup <mynamespace>.servicebus.chinacloudapi.cn
which should provide an output as below
Name: <cloudappinstance>.chinacloudapp.cn Address: XX.XX.XXX.240 Aliases: <mynamespace>.servicebus.chinacloudapi.cn
If the above name does not resolve to an IP and the namespace alias, check which the network administrator to investigate further. Name resolution is done through a DNS server typically a resource in the customer network. If the DNS resolution is done by Azure DNS please contact Azure support.
If name resolution works as expected, check if connections to Azure Service Bus is allowed here
MessagingException is a generic exception that may be thrown for various reasons. Some of the reasons are listed below.
- An attempt is made to create a QueueClient on a Topic or a Subscription.
- The size of the message sent is greater than the limit for the given tier. Read more about the Service Bus quotas and limits.
- Specific data plane request (send, receive, complete, abandon) was terminated due to throttling.
- Transient issues caused due to service upgrades and restarts.
The above list of exceptions is not exhaustive.
The resolution steps depend on what caused the MessagingException to be thrown.
- For transient issues (where isTransient is set to true) or for throttling issues, retrying the operation may resolve it. The default retry policy on the SDK can be leveraged for this.
- For other issues, the details in the exception indicate the issue and resolution steps can be deduced from the same.