Install & Run: http://dev.docs.grakn.ai/docs/running-grakn/install-and-run
New Features
-
Include the Type of each Thing sent over RPC
Previously, obtaining theType
of eachThing
from a query (say, a Match query) meant adding a second network roundtrip to callgetType
on theThing
. For queries, this could be worked around by usingisa!
but this was cumbersome and in some cases, impossible (when building client libraries such as Workbase that needed to support any arbitrary query).
Now, we include theType
of eachThing
sent over RPC, meaning thatgetType
can now be implemented on local Concepts in clients. -
Asynchronous RPC Transaction Executor based on Event Loops
Previously, GRPC executed all incoming requests on a "main" fixed-size thread pool, serially. When dealing with high throughput, this serial execution of the request will cause some "wait time" between the last request execution completed, and the next request received. This delay is enough to create noticeable thread inactivities, holding back the server from fully utilising the CPU cores of the machine.
Bugs Fixed
-
Prevent rare segfaults with storage read-write lock
To prevent segfaults that can occur when a transaction has asynchronous work callingput()
orget()
on storage, after another thread has calledclose()
on storage. To prevent this, we insert a read-write lock that needs to be obtained before each storage operation. Benchmark simulations show this isn't a major performance bottleneck, but we should still move towards more efficient implementations if possible (starting with investigating the use of Optimistic locking for low-contention locks) -
Fix rule satisfiability validation
We previously checked that a rule is coherent/satisfiability by checking each variable in thewhen
and thethen
. However, we no longer set the satisfiability of a variable at all, instead setting onlyisCoherent
at the conjunction. This PR updates Rule validation to reflect this change and removesisSatisfiable
fromVariable
Fixes #6227 -
Fully remove rule indexes when undefining a rule
As outlined in #6228, undefining a rule and committing appears to not completely clear the rule indices, causing subsequent null pointer exceptions. This PR actually deletes persisted rule indexes when undefining rules. -
Rule materialisation lookups should use relation type
We incorrectly fail to use the relation type when performing a traversal to lookup whether the rule conclusion is already satisfied with a given set of concepts. This PR includes the relation type correctly in the lookup, fixing several reasoning BDD scenarios (notably, recursion tests). -
Remove offset and limit from reasoner
It's incorrect to apply offset and limit inside reasoner, as we cannot sort natively. To do this properly, we keep offset and limit only at the top level iterator, and the caller is responsible for making sure that reasoner is not going to "over-compute" when a limit is present.
Code Refactors
-
Use isX, not 'instanceof' to check type encodings
We refactored the codebase to ensure theisX
methods of the subclasses ofConcept
are used consistently, notinstanceof
. -
Type resolver marks non-schema queries as not coherent
During query exection, we now throw an exception when any part of a query is not satisfiable (now known as not coherent), as detected by recursive type resolution. However, we only run type resolution on queries that may touch data, and set the non coherent flag on such queries. -
Resolver track per-request state with non-generic data structures
To clean up the resolutionResolver
architecture, we need to get rid of the overly-generic data structure that was used by all resolvers to track responses per request. To allow resolvers to share some structure, we parametrise Compound resolvers by the type of response data structure they will use. -
Only use Mapped answer state when resolvers change variables
TheMapped
answer state should only be used when mapping between variable spaces, ie. only when using aConcludableResolver
. More simple use cases that stay in the same variable space, possibly with a filter, should useFiltered
.
Other Improvements
- **Parallel configuration is available in all options **
To enable setting parallel execution above solely the query level, we push theparallel
option fromOptions.Query
up to the parent classOptions
, making it available in all types of Options.
Please refer to full release notes of 2.0.0-alpha to see the changes in 2.0.0.