ng:
> >>>> > > >
> >>>> > > > *1.* SolrCloud with one shard and two Solr instances.
> >>>> > > > *2.* Indexation via SolrJ with CloudServer and a custom
> >>>> > > > BinaryLBHttpSolrServer that uses BinaryR
t;>> > > > atomic updates. Check
>>>> > > > JIRA-4080<
>>>> > > >
>>>> > >
>>>> >
>>>> https://issues.apache.org/jira/browse/SOLR-4080?focusedCommentId=13498055&page=com.atlassian.jira.plugin.syste
More info:
- I´m trying to update the document re-indexing the whole document again.
I first retrieve the document querying by it´s id, then delete it by it´s
id, and re-index including the new changes.
- At the same time there are other index writing operations.
*RESULT*: in most cases the docu
For more details, my indexation App is:
1. Multithreaded.
2. NRT indexation.
3. It´s a Web App with a REST API. It receives asynchronous requests that
produces those atomic updates / document reindexations I told before.
I´m pretty sure that the wrong behavior is related with CloudSolrServer and
Hello!
I´m using a simple test configuration with nShards=1 without any replica.
SolrCloudServer is suposed to forward properly those index/update
operations, isn´t it? I test with a complete document reindexation, not
atomic updates, using the official LBHttpSolrServer, not my custom
BinaryLBHttp
It might even depend on the cluster layout! Let's say you have 2 shards (no
replicas) if the doc belongs to the node you send it to so that it does not
get forwarded to another node then the update should work and in case where
the doc gets forwarded to another node the problem occurs. With replica
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
> I think the problem is that even though you were able
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:1
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 B
