Guia de resolução de problemas do Azure Service Bus

Este artigo fornece dicas de solução de problemas e recomendações para alguns problemas que você vê ao usar o Barramento de Serviço do Azure.

Saúde dos recursos

O período de indisponibilidade marcado na página Integridade do recurso do seu namespace do Service Bus no Azure Portal pode durar alguns minutos a mais do que o período real. Por exemplo, a página pode reportar que o namespace está em mau estado entre 5-6 minutos, enquanto o período de mau estado real foi de apenas 1-2 minutos.

Esse comportamento é devido ao mecanismo de avaliação do sistema de alerta, que usa um intervalo de avaliação de 3 minutos combinado com uma janela de retrospetiva de 5 minutos. A janela de monitorização é usada para garantir que não haja erros por pelo menos 5 minutos antes de considerar o namespace estável. No exemplo acima, o namespace ficou íntegro em um ou dois minutos, mas a próxima avaliação ocorreu pelo menos 5 minutos (janela de retrospetiva) depois que o namespace se tornou íntegro.

Problemas de conectividade

Tempo limite ao conectar-se ao serviço

Dependendo do ambiente anfitrião e da rede, um problema de conectividade pode manifestar-se nas aplicações como um TimeoutException, OperationCanceledException ou um ServiceBusException com Reason de ServiceTimeout e ocorre com maior frequência quando o cliente não consegue encontrar um caminho de rede para o serviço.

Para resolver os problemas:

  • Verifique se a cadeia de conexão ou o nome de domínio totalmente qualificado que você especificou ao criar o cliente está correto. Para obter informações sobre como adquirir uma cadeia de conexão, consulte Obter uma cadeia de conexão do Service Bus.
  • Verifique as permissões de firewall e porta em seu ambiente de hospedagem. Verifique se as portas 5671 e 5672 do Advanced Message Queuing Protocol (AMQP) estão abertas e se a extremidade tem permissão para passar pela firewall.
  • Tente usar a opção de transporte Web Socket, que se conecta usando a porta 443. Para obter detalhes, consulte configurar o transporte.
  • Veja se a sua rede está a bloquear endereços IP específicos. Para obter detalhes, consulte Que endereços IP preciso permitir?
  • Se aplicável, verifique a configuração do proxy. Para obter detalhes, consulte: Configurando o transporte
  • Para obter mais informações sobre como solucionar problemas de conectividade de rede, consulte: Problemas de conectividade, certificado ou tempo limite.

Falhas de handshake SSL (Secure Socket Layer)

Este erro pode ocorrer quando um proxy de intercetação é usado. Para verificar, recomendamos que você teste o aplicativo no ambiente host com o proxy desabilitado.

Erros de exaustão do soquete

Os aplicativos devem preferir tratar os tipos do Service Bus como singletons, criando e usando uma única instância durante o tempo de vida do aplicativo. Cada novo ServiceBusClient criado resulta em uma nova conexão AMQP, que usa um soquete. O tipo ServiceBusClient gerencia a conexão para todos os tipos criados a partir dessa instância. Cada ServiceBusReceiver, ServiceBusSessionReceiver, ServiceBusSender e ServiceBusProcessor gerencia seu próprio link AMQP para a entidade do Service Bus associada. Quando você usa ServiceBusSessionProcessor, vários links AMQP são estabelecidos dependendo do número de sessões que estão sendo processadas simultaneamente.

Os clientes são seguros para armazenar em cache quando ociosos; eles garantem um gerenciamento eficiente do uso de rede, CPU e memória, minimizando seu impacto durante os períodos de inatividade. Também é importante que CloseAsync ou DisposeAsync seja invocado quando um cliente deixar de ser necessário, para garantir que os recursos de rede são corretamente libertados.

Adicionar componentes à cadeia de conexão não funciona

A geração atual da biblioteca de cliente do Service Bus oferece suporte a cadeias de conexão somente no formato publicado pelo portal do Azure. As cadeias de conexão destinam-se a fornecer apenas informações básicas de localização e chave compartilhada. A configuração do comportamento dos clientes é feita através das suas opções.

As gerações anteriores dos clientes do Service Bus permitiam que alguns comportamentos fossem configurados adicionando componentes de chave/valor a uma cadeia de conexão. Esses componentes não são mais reconhecidos e não têm efeito sobre o comportamento do cliente.

Alternativa "TransportType=AmqpWebSockets"

Para configurar Web Sockets como o tipo de transporte, consulte Configurando o transporte.

Alternativa "Authentication=Managed Identity"

Para autenticar com a Identidade Gerenciada, consulte: Credenciais de identidade e acesso compartilhado. Para obter mais informações sobre a Azure.Identity biblioteca, consulte Autenticação e o SDK do Azure.

Registo e diagnóstico

A biblioteca cliente do Service Bus está totalmente instrumentada para registar informações em vários níveis de detalhe, utilizando o .NET EventSource para emitir essas informações. O registro em log é realizado para cada operação e segue o padrão de marcação do ponto inicial da operação, sua conclusão e quaisquer exceções encontradas. Informações adicionais que possam fornecer contexto também são registadas no contexto da operação associada.

Ativar registo

Os registos do cliente do Service Bus estão disponíveis para qualquer EventListener, ao ativar as origens iniciadas por Azure-Messaging-ServiceBus ou ao ativar todas as origens que tenham o atributo AzureEventSource. Para facilitar a captura de registos das bibliotecas cliente do Azure, a biblioteca Azure.Core usada pelo Service Bus oferece um AzureEventSourceListener.

Para obter mais informações, consulte: Registo em log com o SDK do Azure para .NET.

Rastreabilidade distribuída

A biblioteca de cliente do Service Bus oferece suporte ao rastreamento distribuído por meio da integração com o SDK do Application Insights. Ele também tem suporte experimental para a especificação OpenTelemetry através do tipo .NET ActivitySource introduzido no .NET 5. Para ativar o suporte de ActivitySource para utilização com o OpenTelemetry, consulte suporte do ActivitySource.

Para usar o suporte ao GA DiagnosticActivity, você pode integrar com o SDK do Application Insights. Mais detalhes podem ser encontrados no ApplicationInsights com o Azure Monitor.

A biblioteca cria os seguintes spans:

Message
ServiceBusSender.Send
ServiceBusSender.Schedule
ServiceBusSender.Cancel
ServiceBusReceiver.Receive
ServiceBusReceiver.ReceiveDeferred
ServiceBusReceiver.Peek
ServiceBusReceiver.Abandon
ServiceBusReceiver.Complete
ServiceBusReceiver.DeadLetter
ServiceBusReceiver.Defer
ServiceBusReceiver.RenewMessageLock
ServiceBusSessionReceiver.RenewSessionLock
ServiceBusSessionReceiver.GetSessionState
ServiceBusSessionReceiver.SetSessionState
ServiceBusProcessor.ProcessMessage
ServiceBusSessionProcessor.ProcessSessionMessage
ServiceBusRuleManager.CreateRule
ServiceBusRuleManager.DeleteRule
ServiceBusRuleManager.GetRules

A maioria dos intervalos é autoexplicativa e começa e termina durante a operação com o mesmo nome. O span que liga os restantes entre si é Message. A maneira como a mensagem é rastreada é por meio do Diagnostic-Id que é definido na propriedade ServiceBusMessage.ApplicationProperties pela biblioteca durante as operações de envio e agendamento. No Application Insights, os spans Message são exibidos com ligações para os vários outros spans que foram utilizados para interagir com a mensagem; por exemplo, o span ServiceBusReceiver.Receive, o span ServiceBusSender.Send e o span ServiceBusReceiver.Complete estariam todos ligados a partir do span Message. Aqui está um exemplo de como isso se parece no Application Insights:

Imagem mostrando um exemplo de rastreamento distribuído.

Na captura de tela, você vê a transação de ponta a ponta que pode ser visualizada no Application Insights no portal. Nesse cenário, o aplicativo está enviando mensagens e usando o ServiceBusSessionProcessor para processá-las. A Message atividade está ligada a ServiceBusSender.Send, ServiceBusReceiver.Receive, ServiceBusSessionProcessor.ProcessSessionMessage, e ServiceBusReceiver.Complete.

Nota

Para obter mais informações, consulte Rastreamento distribuído e correlação por meio de mensagens do Service Bus.

Solucionar problemas do remetente

Não é possível enviar um lote com várias chaves de partição

Quando um aplicativo envia um lote para uma entidade habilitada para partição, todas as mensagens incluídas em uma única operação de envio devem ter o mesmo PartitionKey. Se sua entidade estiver habilitada para sessão, o mesmo requisito será válido para a SessionId propriedade. Para enviar mensagens com valores PartitionKey ou SessionId diferentes, agrupe as mensagens em instâncias ServiceBusMessageBatch separadas ou inclua-as em chamadas separadas para a sobrecarga SendMessagesAsync que aceita um conjunto de instâncias ServiceBusMessage.

Lote falha ao enviar

Um lote de mensagens é ou ServiceBusMessageBatch contendo duas ou mais mensagens, ou uma chamada a SendMessagesAsync na qual são transmitidas duas ou mais mensagens. O serviço não permite que um lote de mensagens exceda 1 MB. Esse comportamento é verdadeiro se o recurso de suporte a mensagens grandes Premium estiver habilitado ou não. Se você pretende enviar uma mensagem maior que 1 MB, ela deve ser enviada individualmente em vez de agrupada com outras mensagens. Infelizmente, o tipo ServiceBusMessageBatch atualmente não suporta a validação de que um lote não contém mensagens maiores que 1 MB, pois o tamanho é restrito pelo serviço e pode mudar. Portanto, se você pretende usar o recurso premium de suporte a mensagens grandes, certifique-se de enviar mensagens com mais de 1 MB individualmente.

Solucionar problemas do recetor

O número de mensagens retornadas não corresponde ao número solicitado no recebimento em lote

Ao tentar efetuar uma operação de receção em lote, isto é, passar um valor de maxMessages igual ou superior a dois ao método ReceiveMessagesAsync, não há garantia de receber o número de mensagens solicitado, mesmo que a fila ou subscrição tenha esse número de mensagens disponível nesse momento e mesmo que ainda não tenha decorrido todo o período maxWaitTime configurado. Para maximizar a taxa de transferência e evitar a expiração do bloqueio, uma vez que a primeira mensagem chega através do fio, o recetor espera mais 20 milissegundos por quaisquer mensagens extras antes de enviar as mensagens para processamento. O maxWaitTime controla quanto tempo o recetor espera para receber a primeira mensagem - as mensagens subsequentes são esperadas por 20 milissegundos. Portanto, seu aplicativo não deve assumir que todas as mensagens disponíveis são recebidas em uma chamada.

O bloqueio de mensagem ou sessão é perdido antes do tempo de expiração do bloqueio

O serviço Service Bus usa o protocolo AMQP, que mantém o estado. Devido à natureza do protocolo, se o link que conecta o cliente e o serviço for desanexado depois que uma mensagem for recebida, mas antes que a mensagem seja resolvida, a mensagem não poderá ser resolvida ao reconectar o link. Os links podem ser desanexados devido a uma falha de rede transitória de curto prazo, uma interrupção de rede ou devido ao tempo limite de ociosidade de 10 minutos imposto pelo serviço. A reconexão do link acontece automaticamente como parte de qualquer operação que exija o link, ou seja, resolver ou receber mensagens. Nesta situação, você recebe um ServiceBusException com Reason de MessageLockLost ou SessionLockLost mesmo que o tempo de expiração do bloqueio ainda não tenha passado.

Como procurar mensagens agendadas ou adiadas

As mensagens agendadas e adiadas são incluídas ao pré-visualizar mensagens. Eles são identificados pela propriedade ServiceBusReceivedMessage.State . Depois de ter o SequenceNumber de uma mensagem adiada, você pode recebê-la com um bloqueio por meio do método ReceiveDeferredMessagesAsync .

Ao trabalhar com tópicos, não é possível consultar mensagens agendadas na subscrição, uma vez que as mensagens permanecem no tópico até à hora de colocação em fila agendada. Como solução alternativa, você pode construir um ServiceBusReceiver passando o nome do tópico para espiar essas mensagens. Nenhuma outra operação com o recetor funciona quando se utiliza um nome de tópico.

Como procurar mensagens de sessão em todas as sessões

Você pode usar um ServiceBusReceiver regular para espreitar todas as sessões. Para espiar uma sessão específica, você pode usar o ServiceBusSessionReceiver, mas precisa obter um bloqueio de sessão.

NotSupportedException lançada ao acessar o corpo da mensagem

Esse problema ocorre com mais freqüência em cenários de interoperabilidade ao receber uma mensagem enviada de uma biblioteca diferente que usa um formato de corpo de mensagem AMQP diferente. Se você estiver interagindo com esses tipos de mensagens, consulte o exemplo de corpo da mensagem AMQP para saber como acessar o corpo da mensagem.

Solucionar problemas do processador

A renovação de bloqueio automático não está a funcionar

A renovação do bloqueio automático depende do tempo do sistema para determinar quando renovar um bloqueio para uma mensagem ou sessão. Se a hora do sistema não for precisa, por exemplo, o relógio estiver lento, a renovação do bloqueio pode não acontecer antes que o bloqueio seja perdido. Certifique-se de que a data e a hora do sistema estão corretas se a renovação do bloqueio automático não estiver a funcionar.

O processador parece travar ou ter problemas de latência ao usar alta simultaneidade

A exaustão de threads geralmente causa esse comportamento, particularmente ao usar o gestor de sessões e quando se usa um valor muito elevado para MaxConcurrentSessions, em relação ao número de núcleos na máquina. A primeira coisa a verificar seria certificar-se de que você não está fazendo sync-over-async em nenhum dos seus manipuladores de eventos. Sync-over-async é uma forma fácil de causar interbloqueios e esgotamento de threads. Mesmo que não esteja a executar código síncrono sobre código assíncrono, qualquer código puramente síncrono nos seus processadores pode contribuir para o esgotamento de threads. Se você determinou que esse não é o problema, por exemplo, porque você tem código assíncrono puro, você pode tentar aumentar seu TryTimeout. Isto alivia a pressão sobre o pool de threads, reduzindo o número de mudanças de contexto e expirações que ocorrem, sobretudo quando se utiliza o processador de sessão. O valor padrão para TryTimeout é 60 segundos, mas pode ser definido até 1 hora. Recomendamos testar com o TryTimeout definido para 5 minutos como ponto de partida e ir ajustando a partir daí. Se nenhuma dessas sugestões funcionar, você simplesmente precisará expandir para vários hosts, reduzindo a simultaneidade em seu aplicativo, mas executando o aplicativo em vários hosts para alcançar a simultaneidade geral desejada.

Leituras adicionais:

Processador de sessão leva muito tempo para alternar sessões

Essa configuração pode ser configurada usando o SessionIdleTimeout, que informa ao processador quanto tempo esperar para receber uma mensagem de uma sessão, antes de desistir e mudar para outra. É útil se você tiver muitas sessões escassamente preenchidas, onde cada sessão tem apenas algumas mensagens. Se você espera que cada sessão tenha muitas mensagens que chegam, defini-la muito baixa pode ser contraproducente, pois resulta em encerramento desnecessário da sessão.

O processador para imediatamente

Esse comportamento geralmente é observado para cenários de demonstração ou teste. StartProcessingAsync retorna imediatamente após o início do processador. Chamar esse método não bloqueia e mantém seu aplicativo ativo enquanto o processador está em execução, então você precisa de algum outro mecanismo para fazer isso. Para demonstrações ou testes, basta adicionar uma Console.ReadKey() chamada depois de iniciar o processador. Para cenários de produção, você provavelmente deseja usar algum tipo de integração de estrutura como o BackgroundService para fornecer ganchos convenientes do ciclo de vida do aplicativo que podem ser usados para iniciar e descartar o processador.

Solucionar problemas de transações

Para obter informações gerais sobre transações no Service Bus, consulte Visão geral do processamento de transações do Service Bus.

Operações suportadas

Nem todas as operações são suportadas quando se utilizam transações. Para ver a lista de transações suportadas, consulte Operações dentro de um escopo de transação.

Limite de tempo excedido

Uma transação expira após um período de tempo, por isso é importante que o processamento que ocorre dentro de um escopo de transação siga esse tempo limite.

As operações numa transação não são tentadas novamente

Este comportamento é intencional. Considere o seguinte cenário - você está tentando concluir uma mensagem dentro de uma transação, mas há algum erro transitório que ocorre, por exemplo, ServiceBusException com um Reason de ServiceCommunicationProblem. Suponha que a solicitação realmente chegue ao serviço. Se o cliente tentasse novamente, o serviço veria duas solicitações completas. A primeira conclusão não é finalizada até que a transação seja confirmada. A segunda conclusão não pode sequer ser avaliada antes de a primeira estar concluída. A transação no cliente está aguardando a conclusão para terminar. Isso cria um impasse onde o serviço está esperando que o cliente conclua a transação, mas o cliente está esperando que o serviço reconheça a segunda operação completa. A transação acabará expirando após 2 minutos, mas é uma experiência ruim para o usuário. Por esse motivo, não repetimos as operações dentro de uma transação.

As transações entre entidades não estão a funcionar

Para executar transações que envolvem várias entidades, você precisa definir a ServiceBusClientOptions.EnableCrossEntityTransactions propriedade como true. Para obter detalhes, consulte o Exemplo de transações entre entidades .

Quotas

Informações sobre cotas do Service Bus podem ser encontradas aqui.

Problemas de conectividade, certificado ou tempo limite

As etapas a seguir ajudam você a solucionar problemas de conectividade/certificado/tempo limite para todos os serviços em *.servicebus.windows.net.

  • Navegue até ou wgethttps://<yournamespace>.servicebus.windows.net/. Ele ajuda a verificar se você tem filtragem de IP ou problemas de rede virtual ou cadeia de certificados, que são comuns ao usar o Java SDK.

    Um exemplo de mensagem bem-sucedida:

    <feed xmlns="http://www.w3.org/2005/Atom"><title type="text">Publicly Listed Services</title><subtitle type="text">This is the list of publicly-listed services currently available.</subtitle><id>uuid:27fcd1e2-3a99-44b1-8f1e-3e92b52f0171;id=30</id><updated>2019-12-27T13:11:47Z</updated><generator>Service Bus 1.1</generator></feed>

    Um exemplo de mensagem de erro de falha:

    <Error>
    <Code>400</Code>
    <Detail>
        Bad Request. To know more visit https://aka.ms/sbResourceMgrExceptions. . TrackingId:b786d4d1-cbaf-47a8-a3d1-be689cda2a98_G22, SystemTracker:NoSystemTracker, Timestamp:2019-12-27T13:12:40
    </Detail>
</Error>

  • Execute o seguinte comando para verificar se alguma porta está bloqueada no firewall. As portas utilizadas são 443 (HTTPS), 5671 e 5672 (AMQP) e 9354 (Net Messaging/SBMP). Dependendo da biblioteca que você usa, outras portas também são usadas. Aqui está o comando de exemplo que verifica se a porta 5671 está bloqueada.

    tnc <yournamespacename>.servicebus.windows.net -port 5671

    No Linux:

    telnet <yournamespacename>.servicebus.windows.net 5671

  • Quando houver problemas intermitentes de conectividade, execute o seguinte comando para verificar se há algum pacote descartado. Este comando tenta estabelecer 25 conexões TCP diferentes a cada 1 segundo com o serviço. Em seguida, poderá verificar quantas tiveram êxito-falharam e ver a latência da ligação TCP. Você pode baixar a psping ferramenta aqui.

    .\psping.exe -n 25 -i 1 -q <yournamespace>.servicebus.windows.net:5671 -nobanner

    Você pode usar comandos equivalentes se estiver usando outras ferramentas, como tnc, pinge assim por diante.

  • Obtenha um rastreamento de rede se as etapas anteriores não ajudarem e analise-o usando ferramentas como o Wireshark. Entre em contato com o Suporte da Microsoft, se necessário.

  • Para encontrar os endereços IP certos para adicionar à lista de permissões para suas conexões, consulte Quais endereços IP preciso adicionar à lista de permissões.

Importante

Em 30 de setembro de 2026, desativaremos o suporte ao protocolo SBMP para o Barramento de Serviço do Azure, portanto, você não poderá mais usar esse protocolo após 30 de setembro de 2026. Migre para as mais recentes bibliotecas SDK do Azure Service Bus utilizando o Advanced Message Queuing Protocol (AMQP), que oferecem atualizações críticas de segurança e capacidades melhoradas, antes dessa data.

Para obter mais informações, consulte o anúncio da descontinuação do suporte.

Problemas que podem ocorrer com atualizações/reinicializações de serviço

Sintomas

  • Os pedidos podem ser momentaneamente limitados.
  • Pode haver uma queda nas mensagens/solicitações recebidas.
  • O arquivo de log pode conter mensagens de erro.
  • Os aplicativos podem ser desconectados do serviço por alguns segundos.

Causa

Atualizações e reinicializações do serviço de back-end podem causar esses problemas em seus aplicativos.

Resolução

Se o código da aplicação utilizar o SDK, a política de repetição já está integrada e ativa. O aplicativo se reconecta sem impacto significativo no aplicativo/fluxo de trabalho.

Acesso não autorizado: Enviar reclamações são necessárias

Sintomas

Você pode ver esse erro ao tentar acessar um tópico do Service Bus do Visual Studio em um computador local usando uma identidade gerenciada atribuída pelo usuário com permissões de envio.

Service Bus Error: Unauthorized access. 'Send' claim\(s\) are required to perform this operation.

Causa

A identidade não tem permissões para aceder ao tópico do Service Bus.

Resolução

Para resolver esse erro, instale a biblioteca Microsoft.Azure.Services.AppAuthentication . Para obter mais informações, consulte Autenticação de desenvolvimento local.

Para saber como atribuir permissões a funções, consulte Autenticar uma identidade gerenciada com a ID do Microsoft Entra para acessar recursos do Barramento de Serviço do Azure.

Exceção do Service Bus: falha no put token

Sintomas

Recebe a seguinte mensagem de erro:

Microsoft.Azure.ServiceBus.ServiceBusException: Put token failed. status-code: 403, status-description: The maximum number of '1000' tokens per connection has been reached.

Em 30 de setembro de 2026, desativaremos as bibliotecas do SDK do Barramento de Serviço do Azure WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus e com.microsoft.azure.servicebus, que não estão em conformidade com as diretrizes do SDK do Azure. Também encerraremos o suporte ao protocolo SBMP, para que você não possa mais usar esse protocolo após 30 de setembro de 2026. Migre para as bibliotecas mais recentes do SDK do Azure, que oferecem atualizações de segurança críticas e recursos aprimorados, antes dessa data.

Embora as bibliotecas mais antigas ainda possam ser usadas após 30 de setembro de 2026, elas não receberão mais suporte e atualizações oficiais da Microsoft. Para obter mais informações, consulte o anúncio da descontinuação do suporte.

Causa

O número de tokens de autenticação para links simultâneos em uma única conexão com um namespace do Service Bus excedeu o limite: 1000.

Resolução

Efetue um dos seguintes passos:

  • Reduza o número de links simultâneos em uma única conexão ou use uma nova conexão
  • Utilize os SDKs do Azure Service Bus para evitar esta situação (recomendado)

Os bloqueios de recursos não funcionam ao usar o SDK do plano de dados

Sintomas

Você configurou um bloqueio de exclusão em um namespace do Service Bus, mas pode excluir recursos no namespace (filas, tópicos, etc.) usando o Service Bus Explorer.

Causa

O bloqueio de recursos é preservado no Azure Resource Manager (plano de controle) e não impede que a chamada SDK do plano de dados exclua o recurso diretamente do namespace. O Service Bus Explorer autônomo usa o SDK do plano de dados, portanto, a exclusão é realizada.

Resolução

Recomendamos que você use a API baseada no Azure Resource Manager por meio do portal do Azure, PowerShell, CLI ou modelo do Gerenciador de Recursos para excluir entidades para que o bloqueio de recursos impeça que os recursos sejam excluídos acidentalmente.

A entidade não está mais disponível

Sintomas

Você vê um erro informando que a entidade não está mais disponível.

Causa

O recurso pode ter sido excluído. Siga estas etapas para identificar por que a entidade foi excluída.

  • Verifique o log de atividades para ver se há uma solicitação de exclusão do Azure Resource Manager.
  • Verifique o log operacional para ver se houve uma chamada direta de API para exclusão. Para saber como recolher um registo operacional, consulte Monitorizar o Azure Service Bus. Para obter o esquema e um exemplo de um log de operação, consulte Logs de operação
  • Verifique o registo de operações para ver se houve uma eliminação relacionada com autodeleteonidle.

Os nomes das entidades mostram tilde (~) em vez de barra para a frente (/)

Sintomas

Os nomes das entidades no portal Azure, CLI ou API ARM mostram caracteres ~, por exemplo orders~us~west em vez de orders/us/west.

Causa

Service Bus suporta nomes de entidades hierárquicas com / como separador de caminhos, mas Azure Resource Manager não permite / nos nomes dos recursos. Service Bus traduz ~ para / na fronteira ARM.

Resolução

Este é um comportamento esperado. O nome da entidade subjacente utiliza /. O ~ aparece apenas em ferramentas baseadas no ARM (portal, CLI, PowerShell, modelos do ARM). Os SDKs do Service Bus e os clientes AMQP veem o nome real /. Para mais detalhes, consulte nomes de entidades com barras oblíquas.

Próximos passos

Consulte os seguintes artigos:

  • Exceções do Azure Resource Manager. Lista exceções geradas ao interagir com o Azure Service Bus utilizando o Azure Resource Manager (através de modelos ou chamadas diretas).
  • Exceções de mensagens. Fornece uma lista de exceções geradas pelo .NET Framework para o Azure Service Bus.
  • Last updated on