public class ChunkedRunningQuery extends AbstractRunningQuery
IRunningQueryimplementation based on the assignment of
IChunkMessage(s) to an operator task. Operators (other than those with "operator-at-once" evaluation semantics) will typically executed multiple times, consuming at least one
IChunkMessageeach time they are evaluated.
IChunkMessages target a specific operator (bopId) and shard (shardId). In scale-out, binding sets will be mapped across the target access path and may be replicated to one or more nodes depending on the distribution of the shards. This evaluation strategy is compatible with both the
Journal(aka standalone) and the
IBigdataFederation(aka clustered or scale-out).
Note: The challenge with this implementation is managing the amount of data
buffered on the JVM heap without introducing control structures which can
result in deadlock or starvation. This has been addressed to a large extent
by sharing a lock between this class and the per-operator input work queues
using modified version of the JSR 166 classes. For high volume operator at
once evaluation, we need to buffer the data on the native process heap using
|Constructor and Description|
|Modifier and Type||Method and Description|
Make a chunk of binding sets available for consumption by the query.
Cancel any running operators for this query on this node (internal API).
Return the effective
Factory returns the effective
Return a summary of the work queue for the operators in this query (non-blocking).
Overridden to attempt to consume another chunk each time an operator reports that it has halted evaluation.
addChild, cancel, cancelQueryOnPeers, checkDeadline, doLastPass, get, get, getAsThrownCause, getAttributes, getBOp, getBOpIndex, getCause, getChildren, getDeadline, getDoneTime, getElapsed, getFederation, getFuture, getLocalIndexManager, getMemoryManager, getQuery, getQueryBuffer, getQueryController, getQueryEngine, getQueryId, getRunningCount, getRunState, getStartedOnCount, getStartTime, getStaticAnalysisStats, getStats, getStats, halt, halt, isAtOnceReady, isCancelled, isController, isDone, isRootCauseInterrupt, iterator, newQueryBuffer, releaseNativeMemoryForOperator, releaseNativeMemoryForQuery, runStateString, setDeadline, setStaticAnalysisStats, startOp, startQuery, toString, tryGetRunState
public ChunkedRunningQuery(QueryEngine queryEngine, UUID queryId, boolean controller, IQueryClient clientProxy, PipelineOp query, IChunkMessage<IBindingSet> realSource)
QueryEngineon which the query is running. In scale-out, a query is typically instantiated on many
queryId- The identifier for that query.
QueryEngineis the query controller for this query (the
QueryEnginewhich will coordinate the query evaluation).
clientProxy- The query controller. In standalone, this is the same as the queryEngine. In scale-out, this is a proxy for the query controller whenever the query is instantiated on a node other than the query controller itself.
query- The query.
saStats- Statistics object containing static analysis statistics
IllegalArgumentException- if any argument is
IllegalArgumentException- if the readTimestamp is
ITx.UNISOLATED(queries may not read on the unisolated indices).
IllegalArgumentException- if the writeTimestamp is neither
ITx.UNISOLATEDnor a read-write transaction identifier.
protected boolean acceptChunk(IChunkMessage<IBindingSet> msg)
Note: this is invoked by
protected void consumeChunk()
IRunningQueryto consume an
IChunkMessagealready on its input queue..
Examines the input queue for each (bopId,partitionId). If there is work available and no task is currently running, then drain the work queue and submit a task to consume that work.
protected void haltOp(IHaltOpMessage msg)
protected boolean cancelRunningOperators(boolean mayInterruptIfRunning)
protected void releaseAcceptedMessages()
IChunkMessages which have been accepted for this queue on this node (internal API).
Note: This must be invoked while holding a lock which is exclusive with
the lock used to hand off
IChunkMessages to operator tasks
otherwise we could wind up invoking
from on an
IAsynchronousIterator running in a different thread.
That would cause visibility problems in the close() semantics unless the
IAsynchronousIterator is thread-safe for close (e.g., volatile
write, synchronized, etc.). The appropriate lock for this is
AbstractRunningQuery.lock. This method is only invoked out of
AbstractRunningQuery.cancel(boolean) which owns that lock.
protected Map<Integer,QueueStats> getQueueStats()
Note: For a cluster, there is one work queue per (operator,shard) pair.
protected IChunkHandler getChunkHandler(QueryEngine queryEngine, PipelineOp query)
IChunkHandlerfor this query.
Copyright © 2006–2016 SYSTAP, LLC DBA Blazegraph. All rights reserved.