thanks Mark and Tomas. Tomas, you mean doing soft commits to all the
slave nodes right? If so, that is what I'm planning to do with the
update processor commented above.
2011/10/21 Tomás Fernández Löbbe :
> I was thinking in this, would it make sense to keep the master / slave
> architecture, ad
I was thinking in this, would it make sense to keep the master / slave
architecture, adding documents to the master and the slaves, do soft commits
(only) to the slaves and hard commits to the master? That way you wouldn't
be doing any merges on slaves. Would that make sense?
On Fri, Oct 21, 2011
Yeah - a distributed update processor like the one Yonik wrote will do fine in
simple situations.
On Oct 17, 2011, at 7:33 PM, Esteban Donato wrote:
> thanks Yonik. Any idea of when this should be completed? In the
> meantime I think I will have to add docs to every replica, possibly
> impleme
thanks Yonik. Any idea of when this should be completed? In the
meantime I think I will have to add docs to every replica, possibly
implementing an update processor. Something similar to SOLR-2355?
On Fri, Oct 14, 2011 at 7:31 PM, Yonik Seeley
wrote:
> On Fri, Oct 14, 2011 at 5:49 PM, Esteban
On Fri, Oct 14, 2011 at 5:49 PM, Esteban Donato
wrote:
> I found soft commits very useful for NRT search requirements.
> However I couldn't figure out how replication works with this feature.
> I mean, if I have N replicas of an index for load balancing purposes,
> when I soft commit a doc in on
Hello guys,
I found soft commits very useful for NRT search requirements.
However I couldn't figure out how replication works with this feature.
I mean, if I have N replicas of an index for load balancing purposes,
when I soft commit a doc in one of this nodes, is there any way that
those "in-m
