Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Fri, 23 Nov 2012 09:16:58 +0000 (UTC)
From: "Luis Cappa Banda (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <555669047.18865.1353662218277.JavaMail.jiratomcat@arcas>
In-Reply-To: <1798759927.18855.1353661737685.JavaMail.jiratomcat@arcas>
Subject: [jira] [Updated] (SOLR-4108) SolrCloud: Unexpected behavior when
 doing atomic updates or document reindexations.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/SOLR-4108?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luis Cappa Banda updated SOLR-4108:
-----------------------------------

    Environment:=20
Note: This issue is related with JIRA-4080.
Context: SolrCloud deployed with nShards=3D1, two Solr servers, each one wi=
th two cores/collections. We have then one leader and one replica for each =
shard.

  was:
Note: This issue is related with JIRA-4080.
Context: SolrCloud deployed with nShards=3D1, two Solr servers, each one wi=
th two cores/collections. We haven then one leader and one replica for each=
 shard.

   =20
> SolrCloud: Unexpected behavior when doing atomic updates or document rein=
dexations.
> -------------------------------------------------------------------------=
----------
>
>                 Key: SOLR-4108
>                 URL: https://issues.apache.org/jira/browse/SOLR-4108
>             Project: Solr
>          Issue Type: Bug
>          Components: SolrCloud
>    Affects Versions: 4.0
>         Environment: Note: This issue is related with JIRA-4080.
> Context: SolrCloud deployed with nShards=3D1, two Solr servers, each one =
with two cores/collections. We have then one leader and one replica for eac=
h shard.
>            Reporter: Luis Cappa Banda
>            Priority: Blocker
>             Fix For: 4.1
>
>
> The situation is this the following:
> 1. SolrCloud with one shard and two Solr instances.
> 2. Indexation via SolrJ with CloudServer and a custom BinaryLBHttpSolrSer=
ver that uses BinaryRequestWriter to execute correctly atomic updates. Chec=
k JIRA-4080
> 3. An asynchronous proccess updates partially some document fields. After=
 that operation I automatically execute a commit, so the index must be relo=
aded.
> What I have checked is that both using atomic updates or complete documen=
t reindexations random documents are not updated even if I saw debugging ho=
w the add() and commit() operations were executed correctly and without err=
ors. In other words, something strange happens when you both index and upda=
te documents asynchronously at the same time.
> Also, if I debug line by line and I check with my own eyes when an index =
operation is done, I confirm that the document itself updates correctly.
> What I think is that there is some critical problem with both SolrCloud a=
nd CloudSolrServer interface that has something to do with index blocking w=
hile writing and forwarding document updates to replicas.
> If I=C2=B4m right, and considering also JIRA-4080, I would not recommend =
SolrCloud in production at the moment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org