Please see my response in line:
On Fri, Apr 17, 2015 at 10:59 PM Shalin Shekhar Mangar <
shalinman...@gmail.com> wrote:
> Some comments inline:
>
> On Sat, Apr 18, 2015 at 2:12 PM, gengmao wrote:
>
> > On Sat, Apr 18, 2015 at 12:20 AM "Jürgen Wagner (DVT)" <
> > juergen.wag...@devoteam.com> wrot
Thanks for the suggestion, Erick. However here what we need is not a patch,
is a clarification from practice perspective.
I think solr replication is a great feature to scale reads, and kind of
increase reliability. However, on HDFS it is not as useful as just
sharding. Sharding can scale both rea
In simple words:
HDFS is good for file-oriented replication. Solr is good for index replication.
Consequently, if atomic file update operations of an application (like Solr)
are not atomic on a file level, HDFS is not adequate - like for Solr with live
index updates. Running Solr on HDFS (as a
I assume you don't have much free space available in your disk. Notice that
during optimization (merge into a single segment) your shard replica space
usage may peak to 2x-3x of it's normal size until optimization completes.
Is it a problem? Not if optimization occurs over shards serially and your
Hi there!
I'd like to be added to the list of people who are able to edit the solr
wiki at https://wiki.apache.org/solr. I'm working as a Java developer for a
german company using Solr (and like it a lot) a lot and I would like to be
able to correct things as soon as I find them without going to t
Done and thanks!
The Reference Guide
(https://cwiki.apache.org/confluence/display/solr/Apache+Solr+Reference+Guide)
is another place to look, it's getting considerable attention at this
point. It's curated a bit more than the Wiki however, so if you see
anything wrong there please make comments on
Thanks, Anshum. Looks like there's no way for this to work in 5.1 for us
so I'll just have to wait to for the fixes. Relieving to know it wasn't
just me, though.
--Ere
18.4.2015, 2.45, Anshum Gupta kirjoitti:
The other issue that would fix half of your problems is:
https://issues.apache.org/j
There are no nested schemas as such. It's only a superset schema that
includes all the fields for parents and children. Obviously, the
fields that are not common should be optional.
The rest depends on what parent/child relation you are trying to
setup. Whether it is explicit with block indexing o
