Bug 1124716 - JDG640.RemoteQuerying.Java
Summary: JDG640.RemoteQuerying.Java
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Data Grid 6
Classification: JBoss
Component: Server
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: DR1
: 6.4.0
Assignee: Adrian Nistor
QA Contact: Martin Gencur
URL:
Whiteboard:
Depends On:
Blocks: 1124710
TreeView+ depends on / blocked
 
Reported: 2014-07-30 07:24 UTC by Tristan Tarrant
Modified: 2015-01-28 13:30 UTC (History)
0 users

Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)

Description Tristan Tarrant 2014-07-30 07:24:22 UTC
Requirement:
	

Move Remote Querying via Hot Rod Java client from Tech Preview to Full Support. 

Following features should be supported:

1) Keyword and range queries

2) Wildcard queries

3) Combining queries: 'and', 'not', 'or' operations

4) Sorting, filtering, and pagination of results

Ease-of-use in configuration (minimize number of configuration steps and dependencies) and comparable performance to Embedded Querying (within 15%).

Priority:
	

P1

Status:
	

Partial Commit (see comments)

Originator:
	

Product Management

Responsible team:
	

Infinispan Engineering Team

Comments:
	

Qualified commit:

Note: the points below apply to both embedded and remote query DSL, both being supported.

1) Keyword and range queries - YES

2) Wildcard queries - we can support the "like" statement

3) Combining queries: 'and', 'not', 'or' operations - YES

4) Sorting, filtering, and pagination of results - YES for sorting and filtering

Regarding the pagination of results: we support pagination, but without stitching. In other words, a user can execute a query specifying a page size and requesting only the 5th page of the result set, but in order to get the 6th page the query needs to be re-executed with different page number. In other words we don't support executing the query once, and getting pages on-demand from the server after that.

B. Ease-of-use in configuration

Following items cause a bad user experience and are fixable in the scope of JDG 6.4 (Dec '14).

- Select which protobuf fields to be indexed (ISPN-3718) Allows for customized, partial indexing

- Automatically setup shared indexing when indexing is enabled (ISPN-4340). User is no longer required configure  indexing by default. Very laborious procedure ATM

- Use a specific cache for managing protofiles (ISPN-4357). This would replace the current JMX approach and make schema administration much easier

- Use protoparser lib instead of relying on binary descriptors generated by protoc (ISPN-3480) Compiling protofiles and uploading binary content through JMX in no longer needed

C. Performance

The execution of a remote query is made out of the execution of an embedded query to which following steps are added:

- a round trip RPC over the hotrod client

- query string parsing and conversion to a lucene query

We estimate these steps being a fixed time addition for every query. However the 2nd step is a complex one, relies on external libraries (antlr) and hasn't been properly tested, especially under load. Starting the performance testing in the early stages of the 6.4 release cycle (July) is critical in order to detect and fix all the 3rd party performance issues.

The 15% performance guarantee the PRD mentions can't be made without this proper testing.

 

D. Limitations and risks

- during the execution, the full result of a query ends up on a single node at a point in time (no streaming of query results). If the query selects a large amount of data, this causes an OOM on either the server or the client. Would be good to ask the field if this is an acceptable limitation

- having performance testing running early in the 6.4 timeline is critical in order to  give us time to fix all the potential 3rd party issues found.


Note You need to log in before you can comment on or make changes to this bug.