Hi,
I got this issue fixed. The problem was the existing bug in Jacoco plugin that
we were using along with gradle to execute the test cases. It looks like the
version of Jacoco that we were using didn’t go well with the “default methods
in an interface” feature of Java. Here are the bug deta
Thanks for the quick response. We are generally seeing exports from Solr 5
and 7 to be roughly the same, but I’ll check out Solr 8.
Joel - We are generally sorting a on tlong field and criteria can vary from
searching everything (*:*) to searching on a combination of a few tint and
string types.
I answered in StackOverflow but will paste it here:
Geo3D requires that polygons adhere to the "right hand rule", and thus the
exterior ring must be in counter-clockwise order and holes must be
clockwise. If you make this mistake then the meaning of the shape is
inverted, and thus that little rec
Your query and sort criteria sound like they should be fast.
In general if you are cutting off the stream at 10K don't use the /export
handler. Use the /select handler, it will be faster for sure. The reason
for the 30K sliding winding was that it maximized throughput over a long
export (many mill
Hi all
At the moment we have 6 servers for doing the search. We want to go up to 12 or
15 servers.
So my question is:
Are there any limitations for the SolrCloud and number of replicates?
Regards
Juergen
Your "sort" parameter has "sort=id+desc,id+desc".
1. It doesn't make sense to have a sort on "id" in descending order twice.
2. Be aware that the id field has the highest cadinality.
3. To speedup sorting have a separate field with docValues=true for sorting.
E.g.
Regards
Bernd
Am 10.05.1
