public abstract class AbstractUnsafeRaftOp extends Operation implements IdentifiedDataSerializable
AbstractUnsafeRaftOp
operation wraps original RaftOp
and executes it outside of Raft algorithm.GENERIC_PARTITION_ID
Modifier and Type | Method and Description |
---|---|
CallStatus |
call()
Call the operation and returns the CallStatus.
|
int |
getFactoryId()
Returns DataSerializableFactory factory ID for this class.
|
CPGroupId |
getGroupId() |
Object |
getResponse()
Called if and only if
Operation.returnsResponse() returned true ,
shortly after Operation.run() returns. |
String |
getServiceName() |
protected void |
readInternal(ObjectDataInput in) |
protected void |
toString(StringBuilder sb)
A template method allows for additional information to be passed into
the
Operation.toString() method. |
protected void |
writeInternal(ObjectDataOutput out) |
afterRun, beforeRun, executedLocally, getCallerAddress, getCallerUuid, getCallId, getCallTimeout, getClientCallId, getConnection, getInvocationTime, getLogger, getNodeEngine, getOperationResponseHandler, getPartitionId, getReplicaIndex, getService, getWaitTimeout, isUrgent, logError, onExecutionFailure, onInvocationException, onSetCallId, readData, requiresExplicitServiceName, returnsResponse, run, sendResponse, setCallerUuid, setClientCallId, setNodeEngine, setOperationResponseHandler, setPartitionId, setReplicaIndex, setService, setServiceName, setValidateTarget, setWaitTimeout, toString, validatesTarget, writeData
clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait
getClassId
readData, writeData
public final CallStatus call() throws Exception
Operation
Operation.run()
methods will be replaced by call
methods.
The call method looks very much like the Operation.run()
method and it is
very close to Runnable.run()
and Callable.call()
.
The main difference between a run and call, is that the returned
CallStatus from the call can tell something about the actual execution.
For example it could tell that some waiting is required in case of a
BlockingOperation
. Or that the actual execution work is
offloaded to some executor in case of an
Offloadable
EntryOperation
.
In the future new types of CallStatus are expected to be added, e.g. for
interleaving.
In the future it is very likely that for regular Operation that want to
return a concrete response, the actual response can be returned directly.
In this case we'll change the return type to Object
to prevent
forcing the response to be wrapped in a CallStatus.DONE_RESPONSE
monad since that would force additional litter to be created.call
in class Operation
Exception
- if something failed while executing 'call'.Operation.run()
public final CPGroupId getGroupId()
public Object getResponse()
Operation
Operation.returnsResponse()
returned true
,
shortly after Operation.run()
returns.getResponse
in class Operation
public final String getServiceName()
getServiceName
in class Operation
protected void writeInternal(ObjectDataOutput out) throws IOException
writeInternal
in class Operation
IOException
protected void readInternal(ObjectDataInput in) throws IOException
readInternal
in class Operation
IOException
public int getFactoryId()
IdentifiedDataSerializable
getFactoryId
in interface IdentifiedDataSerializable
protected void toString(StringBuilder sb)
Operation
Operation.toString()
method. So an Operation subclass can override
this method and add additional debugging content. The default
implementation does nothing so one is not forced to provide an empty
implementation.
It is a good practice to always call the super.toString(stringBuffer)
when implementing this method to make sure that the super class can
inject content if needed.Copyright © 2019 Hazelcast, Inc.. All rights reserved.