hi Jason , Have , the replication can probably piggyback on the new java replication proposed (SOLR-561). * It can be either a pull model . Keep the pollInterval very short (in the slave) say every second or less and get the transaction logs. If there is a new tx just get it and push it in the slave * Push model. Register the urls of slaves in master . Trigger a snappull (or a new txlogpull command ) in the slaves. The slaves will then call the master to fetach the new logs and update it --Noble
On Tue, Jun 3, 2008 at 1:11 AM, Jason Rutherglen (JIRA) <[EMAIL PROTECTED]> wrote: > > [ > https://issues.apache.org/jira/browse/SOLR-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Jason Rutherglen updated SOLR-564: > ---------------------------------- > > Attachment: solr-564.patch > > solr-564.patch > > Early Ocean Solr integration code. For viewing only. Depends on SOLR-568, > SOLR-567, Lucene contrib InstantiatedIndex, LUCENE-1289, jdom, commons-io, > commons-lang, geoapi-nogenerics-2.1-M2.jar, gt2-referencing-2.3.2.jar. Not > sure what to do with heavily modified net.sourceforge.jsorter code (it is > Apache license). > >> Realtime search in Solr >> ----------------------- >> >> Key: SOLR-564 >> URL: https://issues.apache.org/jira/browse/SOLR-564 >> Project: Solr >> Issue Type: New Feature >> Components: replication, search >> Affects Versions: 1.3 >> Reporter: Jason Rutherglen >> Attachments: solr-564.patch >> >> >> Before when I looked at this, the changes required to make Solr realtime >> would seem to break the rest of Solr. Is this still the case? In project >> Ocean http://code.google.com/p/oceansearch/ there is a realtime core however >> integrating into Solr has looked like a redesign of the guts of Solr. >> - Support for replication per update to transaction log >> - Custom realtime index creation >> - Filter and facet merging >> - Custom IndexSearcher that ties into realtime subsystem >> - Custom SolrCore that ties into realtime subsystem >> Is there a way to plug into these low level Solr functions without a massive >> redesign? A key area of concern is the doclist caching which is not used in >> realtime search because after every update the doclists are no longer valid. >> The doclist caching and handling is default in SolrCore. Ocean relies on a >> custom threaded MultiSearcher rather than a single IndexSearcher is a >> difficulty. DirectUpdateHandler2 works directly on IndexWriter is >> problematic. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > > -- --Noble Paul
