requête couchdb temporisation lors de l'exécution dans un lot avec mises à jour en continu

Question

J'utilise une simple fetch par lots et mettre à jour sur couchdb.

int batchSize = 5000; 
    String startKey = ""; 
    List<FrontLineWorker> frontLineWorkers; 

    while (true) { 
     frontLineWorkers = allFrontLineWorkers.getMsisdnsFrom(startKey, batchSize); 

     if (frontLineWorkers.size() < batchSize) break; 

     for (FrontLineWorker frontLineWorker : frontLineWorkers) { 
      // process record, only updates record 
     } 

     startKey = frontLineWorkers.get(frontLineWorkers.size() - 1).getMsisdn(); 
    } 

Le getMsisdnsFrom est une requête de canapé, et il commence à temps après quelques temps. Je sais que le divan indexe les vues seulement quand une lecture est faite, mais puisque je ne fais que mettre à jour les enregistrements il ne devrait pas affecter les index. De plus, puisqu'il s'agit d'une utilisation attendue, obtenir un ensemble d'enregistrements, modifier et obtenir l'ensemble suivant, je ne m'attends pas à ce qu'il expire.

J'ai essayé avec les deux fois par lots 1000 et 5000.

Message d'exception est: Exception dans le thread "principal" org.ektorp.DbAccessException: java.net.SocketTimeoutException: Lire a expiré

EDIT : Cela a fonctionné après que j'ai réduit la taille de lot à 100, mais j'aurais préféré une taille de lot plus élevée. La mise à jour des documents les force à être réindexés.

Answer 1

Answer 2

Cette java.net.SocketTimeoutException est une exception de bas niveau, il semble que vous ayez juste besoin d'augmenter la valeur du délai d'expiration du socket pour que Java attende la fin de la lecture.

djc est correcte aussi, toutes les mises à jour entraîneront une réindexation des nœuds affectés, mais le fait que vous pouvez éviter le délai avec une taille de lot de 100 signifie que la réindexation ne cause pas de problème significatif.

Le problème est que la taille du lot est trop grande pour le délai d'expiration de votre socket, réduire le premier ou augmenter le second.