The LatLonShape field and LatLonShape query classes added the ability to index and search geospatial
geometries in the WGS-84 latitude, longitude coordinate reference system. The foundation for this
capability is provided by the Tessellator that converts an array of vertices describing a Point Line
or Polygon into a stream of 3 vertex triangles that are encoded as a seven dimension point and
indexed using the BKD POINT structure. A nice property of the Tessellator is that lat, lon
restrictions are artificial and really only bound by the API.
This commit builds on top of / abstracts the Tessellator LatLonShape and LatLonShapeQuery classes to
provide the ability to index & search general cartesian (non WGS84 lat,lon restricted) geometry.
It does so by introducing two new base classes: ShapeField and ShapeQuery that provide the indexing
and search foundation for LatLonShape and the LatLonShape derived query classes
(LatLonShapeBoundingBoxQuery, LatLonShapeLineQuery, LatLonShapePolygonQuery) and introducing a new
XYShape factory class along with XYShape derived query classes (XYShapeBoundingBoxQuery,
XYShapeLineQuery, XYShapePolygonQuery). The heart of the cartesian indexing is achieved through
XYShapeEncodingUtils that converts the double precision vertices into an integer encoded seven
dimension point (similar to LatLonShape).
The test framework is also further abstracted and extended to provide a full test suite for the
new XYShape capability that works the same way as the LatLonShape test suite (but applied to non
GIS geometries).
group.query after execution forms QueryCommandResult. In case of
group.main=true or group.format=simple, QueryCommandResult was not
consumed in EndResultTransformer. Also, MainEndResultTransformer assumed
that always group.field would be specified. When group.field not specified
it failed with AIOOBE. After adding suppport for QueryCommandResult in
EndResultTransformers and handling AIOOBE, group.query started giving results
Working on tests exposed few other issues. Results differed b/w standalone
& distributed mode.
* One of the reason is that TopGroupShardResponseProcessor doesn't consider correct
limit and offset when group format is simple. In case of simple, start and rows should be used
as limit and offset instead of group.limit and group.offset.
* Secondly, In distributed second phase grouping, computing docsToCollect didn't consider
group response format. This issue is again similar to above issue
* offset(group.offset or start) not being considered during TopDocs#merge caused
different results. The fix was to use to offset in merge process
* group.offset doesn't support negative values but there is no checks on the value.
In case of negative values AIOOBE. Now, checks are added for negative values and
returns proper error message(this change is for both standalone and distrbuted).
Validation is done only in case of group.format=grouped as that is only case when
group.offset is consumed.
Fixing above issues resolved the differences b/w standalone and distributed mode.
* When ramPerThreadHardLimitMB is not specified, then Lucene's
default value 1945 is used. The specified value should be
greater than 0 and less than 2048MB
This commit introduces a mechanism to track the dynamic memory
utilization of Collectors and allow setting collector level limits
for memory usage. A new bitset collecting Collector is introduced
which supports the memory tracker functionality
