[ https://issues.apache.org/jira/browse/SOLR-6266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14144858#comment-14144858 ]
Noble Paul commented on SOLR-6266: ---------------------------------- It makes sense to have a per-cluster/per-collection/per shard components in Solr. The component should be available at all nodes and SolrCloud should ensure that it runs in only one node (depending on scope) at a given time. For this usecase * I need a per collection component * SolrCloud should ensure that one and only one instance of this component runs per collection * The component lifecycle should be managed by SolrCloud. i.e callbacks for component init() when it is started up in a node. If possible , give a unload() callback if the system decided to switch the node > Couchbase plug-in for Solr > -------------------------- > > Key: SOLR-6266 > URL: https://issues.apache.org/jira/browse/SOLR-6266 > Project: Solr > Issue Type: New Feature > Reporter: Varun > Assignee: Joel Bernstein > Attachments: solr-couchbase-plugin.tar.gz, > solr-couchbase-plugin.tar.gz > > > It would be great if users could connect Couchbase and Solr so that updates > to Couchbase can automatically flow to Solr. Couchbase provides some very > nice API's which allow applications to mimic the behavior of a Couchbase > server so that it can receive updates via Couchbase's normal cross data > center replication (XDCR). > One possible design for this is to create a CouchbaseLoader that extends > ContentStreamLoader. This new loader would embed the couchbase api's that > listen for incoming updates from couchbase, then marshal the couchbase > updates into the normal Solr update process. > Instead of marshaling couchbase updates into the normal Solr update process, > we could also embed a SolrJ client to relay the request through the http > interfaces. This may be necessary if we have to handle mapping couchbase > "buckets" to Solr collections on the Solr side. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org