[
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
