Hi, Sami! But isn´t strange that some documents were updated (atomic updates) correctly and other ones not? Can´t it be a more serious problem like some kind of index writer lock, or whatever?
Regards, - Luis Cappa. 2012/11/22 Sami Siren <ssi...@gmail.com> > I think the problem is that even though you were able to work around the > bug in the client solr still uses the xml format internally so the atomic > update (with multivalued field) fails later down the stack. The bug you > filed needs to be fixed to get the problem solved. > > > On Thu, Nov 22, 2012 at 8:19 PM, Luis Cappa Banda <luisca...@gmail.com > >wrote: > > > Hello everyone. > > > > I´ve starting to seriously worry about with SolrCloud due an strange > > behavior that I have detected. The situation is this the following: > > > > *1.* SolrCloud with one shard and two Solr instances. > > *2.* Indexation via SolrJ with CloudServer and a custom > > BinaryLBHttpSolrServer that uses BinaryRequestWriter to execute correctly > > atomic updates. Check > > JIRA-4080< > > > https://issues.apache.org/jira/browse/SOLR-4080?focusedCommentId=13498055&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13498055 > > > > > *3.* An asynchronous proccess updates partially some document fields. > After > > that operation I automatically execute a commit, so the index must be > > reloaded. > > > > What I have checked is that both using atomic updates or complete > document > > reindexations* aleatory documents are not updated* *even if I saw > debugging > > how the add() and commit() operations were executed correctly* *and > without > > errors*. Has anyone experienced a similar behavior? Is it posible that if > > an index update operation didn´t finish and CloudSolrServer receives a > new > > one this second update operation doesn´t complete? > > > > Thank you in advance. > > > > Regards, > > > > -- > > > > - Luis Cappa > > > -- - Luis Cappa
