Lançado o cliente Couchbase .NET 1.3.4!

Esta versão é outra versão de estabilidade/correção de bugs que se concentra em melhorar o algoritmo de repetição de visualizações e adicionar um registro mais refinado ao cliente, além de algumas outras correções diversas.

Melhorar a consistência das operações de visualização é importante, pois o Couchbase é um banco de dados distribuído e os nós podem sair ou entrar no cluster a qualquer momento. Isso se torna problemático para os clientes do Couchbase quando, por exemplo, um nó específico deixa o cluster enquanto uma operação direcionada a esse nó está em pleno voo. A questão é: o que fazer em seguida? Poderíamos simplesmente falhar e permitir que o aplicativo de hospedagem lidasse com o erro e talvez tentasse novamente a operação por seus próprios meios, mas não achamos que essa seja a abordagem correta ou o tipo de experiência que um desenvolvedor de aplicativos que usa o cliente apreciaria.

Com a versão 1.3.4, quando uma operação de visualização falha, o cliente usa o código de status HTTP e algumas heurísticas para determinar se deve ou não tentar novamente a operação ou se deve borbulhar a mensagem de erro de volta para o aplicativo com seu valor de sucesso definido como falso. Se uma nova tentativa for necessária, o cliente usará uma estratégia de retrocesso exponencial em que, para cada nova tentativa, a duração entre as tentativas será dobrada até que o limite máximo seja atingido ou a operação seja bem-sucedida. A primeira tentativa não é contada, mas o cliente faz uma pausa para cada nova tentativa subsequente: 1 ms, 2 ms, 4 ms etc. Isso garante que o cliente dê tempo ao cluster para resolver qualquer problema de estabilidade antes de falhar completamente na operação sem causar um ataque de DoS no cluster.

O algoritmo pode ser ajustado por meio da propriedade ViewRetryCount na configuração e o padrão é 2. Observe que, com essa configuração de 2, o cliente tentará a operação quatro vezes antes de desistir: a primeira tentativa não é contada, depois o cliente tentará em 1 ms, depois em 2 ms e, finalmente, em 4 ms. Você pode escolher uma configuração entre 0 e 10; 0 desabilitará as novas tentativas e 10 fará a última tentativa em 1024 ms (na verdade, é a soma do tempo entre a primeira e a última tentativa, portanto, o tempo total é muito maior). Observe que esse algoritmo pode mudar em versões posteriores.

As notas oficiais da versão podem ser encontradas aqui.

Compartilhe este artigo
Receba atualizações do blog do Couchbase em sua caixa de entrada
Esse campo é obrigatório.

Autor

Postado por Jeff Morris, engenheiro de software sênior, Couchbase

Jeff Morris é engenheiro de software sênior da Couchbase. Antes de ingressar na Couchbase, Jeff passou seis anos na Source Interlink como arquiteto da Web corporativa. Jeff é responsável pelo desenvolvimento dos SDKs do Couchbase e pela integração com o N1QL (linguagem de consulta).

3 Comentários

  1. Oi Jeff,

    Recentemente, enfrentamos um problema de conectividade com o Couchbase em nosso código .net. Ao depurar o problema, descobrimos que o número de conexões TCP que estavam sendo criadas para o servidor couch era muito alto (quase 10 mil por servidor). Um pouco mais de investigação sobre o problema nos mostrou que a pressão da conexão está relacionada ao nosso consumo atual do cliente Couchbase. Lendo o código e escrevendo alguns códigos de teste de unidade, descobrimos que o pool de conexões está associado ao objeto CouchBaseClient. Nosso código estava criando um novo objeto cliente para cada solicitação e confiando no destrutor para descartar o objeto. Como resultado, havia uma imensa pressão de conexão no servidor, o que resultava em tempos limite de conexão e outros problemas de conectividade.

    Com base nas observações acima, alteramos nosso código para consumir o objeto cliente como singleton e reduzimos o tamanho mínimo do pool de conexões de 10 para 3. Essas alterações parecem ter resolvido o problema. Nenhum problema de conectividade foi registrado nos últimos três dias de teste de estresse.

    Gostaria de saber de você se esse é o padrão de consumo pretendido? Se precisar, posso compartilhar mais detalhes.

    Agradeço imensamente seus comentários sobre isso.

    Agradecimentos

    -VM

    1. Oi VM -

      Sim, você está correto, o cliente deve ser um objeto de longa duração; você o cria quando o processo ou o domínio do aplicativo é iniciado e o destrói antes que o processo seja destruído. Uma instância singleton ou estática pública é perfeita; o cliente é thread-safe.

      Você pode ler mais aqui: http://docs.couchbase.com/couc

      Pelo que posso dizer, você está fazendo as coisas "da maneira certa".

      -Jeff

  2. [...] Lançado o cliente Couchbase .NET 1.3.4! Leia o blog e veja as notas de versão [...]

Deixe um comentário

Pronto para começar a usar o Couchbase Capella?

Iniciar a construção

Confira nosso portal do desenvolvedor para explorar o NoSQL, procurar recursos e começar a usar os tutoriais.

Use o Capella gratuitamente

Comece a trabalhar com o Couchbase em apenas alguns cliques. O Capella DBaaS é a maneira mais fácil e rápida de começar.

Entre em contato

Deseja saber mais sobre as ofertas do Couchbase? Deixe-nos ajudar.