Sharing the solution to our problems:
*What was wrong: *We used to update the slave and the master solr at the
same time, and all of the webapps screens were searching on the slave,
where we cache almost everything. Updating the cache takes time.
*What we Changed:* We now (on the screen where th
Thanks Tomás,
We are trying many combinations on master/slave and commit configurations.
If we dont find the solution, we'll try NRT.
Once we've found an acceptable solution, we'll report back ...
2012/2/2 Tomás Fernández Löbbe
> The problem is that in order to make the changes visible to th
The problem is that in order to make the changes visible to the user you
have to issue a commit. If you commit with every user change (I assume you
may have concurrent users) you may have many commits per second. That's too
much for Solr, as each commit will flush a new segment, reopen an index
sea
Good morning everyone,
I'm working on a project using solr 3.5, one master and two slaves.
We run a grails app, and it has an update function.
When the user click the button, we search for the message to be updated,
clone it using SolrJ, delete the old message and save the new one.
We do this up
