Por meio deste blog, estamos lançando a primeira visualização para desenvolvedores do Java SDK 1.4.0. Além das correções de bugs e dos aprimoramentos habituais, essa nova versão secundária oferece suporte ao gerenciamento otimizado de conexões, que foi introduzido recentemente no Couchbase Server 2.5.0. Veja abaixo mais informações sobre as novidades.
Você pode fazer o download da visualização em Central Maven ou um arquivo zip com todos os JARs incluído.
Atualização: A visualização para desenvolvedores foi atualizada para a versão 1.4.0dp2 a partir de 4 de abril de 2014.
Gerenciamento otimizado de conexões
Servidor Couchbase 2.5.0 introduziu uma nova maneira de buscar uma configuração de cluster há algumas semanas. Além da maneira anterior de carregá-la pela porta 8091 (http), agora é possível que o SDK a carregue diretamente pelo protocolo binário subjacente (porta 11210). Anteriormente, para acompanhar as alterações em andamento no cluster, o cliente precisava estabelecer uma conexão de fluxo contínuo com a porta de configuração (que enviava novos blocos de configuração para o cliente). Agora, o cliente recebe novas configurações juntamente com respostas de operações de dados pela porta binária. Isso torna o bootstrap muito mais rápido e eficiente, facilitando o gerenciamento de grandes implementações.
Ao usar o Java SDK, não há nada que precise ser alterado em termos de API, mas como o processo de bootstrap muda um pouco, é bom entender o que realmente está acontecendo. Para uma introdução geral a esse tópico, recomendo Postagem no blog de Mark Nunberg sobre as alterações semelhantes na libcouchbase, que abrange muitas das partes circundantes.
O Java SDK recebe a lista de nós de bootstrap passada, mas ignora tudo do URI além do nome do host por enquanto. Ele tenta entrar em contato com o servidor de destino na porta 11210. Se o servidor responder com uma configuração válida (o que acontece se for um nó 2.5.0 ou posterior e um bucket do couchbase), essa configuração será imediatamente armazenada e usada. Nenhuma conexão de streaming é anexada, mas essa conexão binária é reutilizada para buscar atualizações de configuração sob demanda, conforme necessário. Se o servidor não responder com uma configuração válida, todos os outros nós da lista de bootstrap serão testados com o mesmo comportamento. Se nenhum deles retornar uma configuração válida (por exemplo, se for usado um bucket de memcache ou se todos os nós do cluster forem da versão 2.2 ou mais antiga), o cliente voltará para o bootstrap do tipo HTTP (antigo) e para a conexão de streaming. Embora esse processo altere o comportamento e não pareça corresponder ao que os argumentos sugerem que está acontecendo, achamos que é a coisa certa a fazer para fins de compatibilidade com os aplicativos existentes (embora estejamos abertos a comentários).
O mesmo processo é estabelecido quando a conexão de configuração é perdida ou quando outras partes do SDK indicam que a conexão de configuração está desatualizada (por exemplo, uma grande quantidade de operações com falha).
O registro em nível INFO foi adicionado para que seja visível nos registros qual abordagem de bootstrap foi usada. Se os novos recursos de gerenciamento de conexão funcionaram, essa mensagem de registro será exibida:
Caso contrário, essa saída de registro pode ser encontrada:
Como essa alteração é um pouco maior dentro do SDK, experimente a visualização para desenvolvedores (esse é o principal motivo pelo qual optamos por fazer uma visualização em vez de ir diretamente para a versão final) e nos dê feedback sobre vários cenários em seu ambiente. Nossa equipe de testes também está testando o sistema.
Número total de registros no ViewResponse
Toda visualização não reduzida expõe o número total de linhas na visualização e isso agora também é refletido no Java SDK. Isso é especialmente útil em cenários de paginação e teste de unidade. Aqui está um exemplo (do conjunto de dados de amostra de cerveja):
View view = c.getView("beer", "brewery_beers");
Consulta = new Query();
query.setLimit(10);
ViewResponse response = c.query(view, query);
System.out.println("In this batch: " + response.size());
System.out.println("Total in this View: " + response.getTotalRows());
Isso imprime:
Total nesta visualização: 7303
Essa é uma solicitação de longa data dos usuários e está agora nesta versão.
Recursos aprimorados de leitura de réplicas
Outra solicitação do usuário, desde que adicionamos os recursos de leitura de réplicas, foi que também houvesse uma maneira de recuperar o valor CAS do nó de réplica. Isso basicamente se assemelha ao conhecido comando "gets", mas desta vez para réplicas. Adicionamos o recurso por meio dos comandos asyncGetsFromReplica e getsFromReplica. Aqui está um exemplo de como utilizar os novos métodos:
CASValue
Lembre-se de que a semântica é a mesma de "getFromReplica", de modo que o valor retornado com CAS pode ser do mestre ou de um dos nós de réplica, dependendo de quem respondeu primeiro. Esse valor CAS pode ser usado para comandos de gravação subsequentes que precisam incluir o valor CAS para o bloqueio otimista.
Códigos de status Typesafe em OperationStatus
No passado, sempre foi um pouco incômodo lidar com strings de resposta de status de operações futuras. Não havia uma boa maneira de lidar com elas além de verificar as cadeias. Esta versão menor traz StatusCodes para os objetos OperationStatus, o que permite que você simplesmente verifique um ENUM:
Agora podemos usar a mesma abordagem para verificar se uma resposta de adição falhou porque a chave já foi definida:
O StatusCode fornece todos os códigos de status possíveis que podem ser retornados e, antes da versão final, também forneceremos a documentação adequada sobre quando eles podem ocorrer (para que você saiba o que procurar ao verificar os códigos).
Próximas etapas
Decidimos fazer uma prévia para desenvolvedores para essa versão secundária porque queremos garantir que os novos recursos otimizados de gerenciamento de conexões sejam testados antes de uma versão final. Experimente e informe quaisquer problemas que encontrar em nosso rastreador de problemas. Assim que nossa equipe de testes nos der sinal verde e se não houver preocupações dos usuários do DP, nós o lançaremos como GA!
Oi Nitschinger,
Estamos recebendo as exceções abaixo aleatoriamente com o couchbase 2.x e o java client sdk 1.4.x
1. Desligamento do bucket \"Sample\" em \"ns_1@10.10.10.163\" para o servidor shutdownns_memcached002ns_1@10.10.10.16322:33:48 - Ter 11 Ago, 2015
2.com.couchbase.client.vbucket.ConfigurationException: Não foi possível buscar uma configuração válida do Bucket.2015-08-06 00:37:37 STDIO [ERROR] at com.couchbase.client.vbucket.provider.BucketConfigurationProvider.bootstrap(BucketConfigurationProvider.ja...:123)
2015-08-06 00:37:37 STDIO [ERROR]
Alguma ideia de como podemos reproduzir isso e corrigi-lo?
Oi Ravi,
O melhor é transferir essa discussão para os fóruns, https://forums.couchbase.comonde poderemos acompanhar melhor a discussão e solicitar mais detalhes (certifique-se de postar na categoria Java SDK e forneça o máximo de contexto possível).
Obrigado!