What Shawn has described is exactly what we do: classical distributed no-SolrCloud setup. This is why it was possible to implement a custom frontend solr instance.
On Wed, Oct 2, 2013 at 12:42 AM, Shawn Heisey <s...@elyograg.org> wrote: > On 10/1/2013 2:35 PM, Isaac Hebsh wrote: > >> Hi Dmitry, >> >> I'm trying to examine your suggestion to create a frontend node. It sounds >> pretty usefull. >> I saw that every node in solr cluster can serve request for any >> collection, >> even if it does not hold a core of that collection. because of that, I >> thought that adding a new node to the cluster (aka, the frontend/gateway >> server), and creating a dummy collection (with 1 dummy core), will solve >> the problem. >> >> But, I see that a request which sent to the gateway node, is not then sent >> to the shards. Instead, the request is proxyed to a (random) core of the >> requested collection, and from there it is sent to the shards. (It is >> reasonable, because the SolrCore on the gateway might run with different >> configuration, etc). This means that my new node isn't functioning as a >> frontend (which responsible for sorting, etc.), but as a poor load >> balancer. No performance improvement will come from this implementation. >> >> So, how do you suggest to implement a frontend? On the one hand, it has to >> run a core of the target collection, but on the other hand, we don't want >> it to hold any shard contents. >> > > With SolrCloud, every node is a frontend node. If you're running > SolrCloud, then it doesn't make sense to try and use that concept. > > It only makes sense to create a frontend node (or core) if you are using > traditional distributed search, where you need to include a shards > parameter. > > http://wiki.apache.org/solr/**DistributedSearch<http://wiki.apache.org/solr/DistributedSearch> > > Thanks, > Shawn > >
