Processor (Hazelcast Root 5.0.5 API)

All Known Implementing Classes:

AbstractProcessor, LongStreamSourceP, ParallelBatchP, ParallelStreamP
```
public interface Processor
```
When Jet executes a DAG, it creates one or more instances of Processor on each cluster member to do the work of a given vertex. The vertex's localParallelism property controls the number of processors per member.
The processor is a single-threaded processing unit that performs the computation needed to transform zero or more input data streams into zero or more output streams. Each input/output stream corresponds to an edge on the vertex. The correspondence between a stream and an edge is established via the edge's ordinal.
The special case of zero input streams applies to a source vertex, which gets its data from the environment. The special case of zero output streams applies to a sink vertex, which pushes its data to the environment.
The processor accepts input from instances of Inbox and pushes its output to an instance of Outbox.
See the isCooperative() for important restrictions to how the processor should work.
Processing methods
When the documentation in this class refers to processing methods, we mean all methods except for these:
Transactional processors
If this processor communicates with an external transactional store, after the snapshot is restored and before it executes any code in a processing method, it should rollback all transactions that this processor created. It should only rollback transactions created by this vertex and this job; it can use the vertex name and job ID passed to the init(com.hazelcast.jet.core.Outbox, com.hazelcast.jet.core.Processor.Context) method in the context to filter.
Determining the list of transactions to rollback
You can't store the IDs of the created transactions to the snapshot, as one might intuitively think. The job might run for a while after creating a snapshot and start a new transaction and we need to roll that one too. The job might even fail before it creates the first snapshot.
There are multiple ways to tackle this:
- enumerate all pending transactions in the external system and rollback those that were created by this processor. For example, a file sink can list files in the directory it is writing to
- if the remote system doesn't allow us to enumerate transactions, we can use deterministic scheme for transaction ID and probe all IDs that could be used by this processor. For example: jobId + vertexId + globalProcessorIndex + sequence
How the methods are called
Besides init(com.hazelcast.jet.core.Outbox, com.hazelcast.jet.core.Processor.Context), close() and isCooperative() the methods are called in a tight loop with a possibly short back-off if the method does no work. "No work" is defined as adding nothing to outbox and taking nothing from inbox. If you do heavy work on each call (such as querying a remote service), you can do additional back-off: use sleep in a non-cooperative processor or do nothing if sufficient time didn't elapse.
Since:

Jet 3.0

Nested Class Summary

Nested Classes
Modifier and Type Interface and Description

static interface Processor.Context
Context passed to the processor in the init() call.

Nested Classes
Modifier and Type	Interface and Description
`static interface`	`Processor.Context` Context passed to the processor in the `init()` call.

Method Summary

All Methods Instance Methods Abstract Methods Default Methods
Modifier and Type	Method and Description
`default void`	`close()` Called as the last method in the processor lifecycle.
`default boolean`	`closeIsCooperative()` Returns `true` if the `close()` method of this processor is cooperative.
`default boolean`	`complete()` Called after all the inbound edges' streams are exhausted.
`default boolean`	`completeEdge(int ordinal)` Called after the edge input with the supplied `ordinal` is exhausted.
`default boolean`	`finishSnapshotRestore()` Called after a job was restarted from a snapshot and the processor has consumed all the snapshot data in `restoreFromSnapshot(com.hazelcast.jet.core.Inbox)`.
`default void`	`init(Outbox outbox, Processor.Context context)` Initializes this processor with the outbox that the processing methods must use to deposit their output items.
`default boolean`	`isCooperative()` Tells whether this processor is able to participate in cooperative multithreading.
`default void`	`process(int ordinal, Inbox inbox)` Called with a batch of items retrieved from an inbound edge's stream.
`default void`	`restoreFromSnapshot(Inbox inbox)` Called when a batch of items is received during the "restore from snapshot" operation.
`default boolean`	`saveToSnapshot()` Stores the processor's state to a state snapshot by adding items to the outbox's snapshot bucket.
`default boolean`	`snapshotCommitFinish(boolean success)` This is the second phase of a two-phase commit.
`default boolean`	`snapshotCommitPrepare()` Prepares the transactions for commit after the snapshot is completed.
`default boolean`	`tryProcess()` This method will be called periodically and only when the current batch of items in the inbox has been exhausted.
`boolean`	`tryProcessWatermark(Watermark watermark)` Tries to process the supplied watermark.

- Method Detail
  - isCooperative
```
default boolean isCooperative()
```
    Tells whether this processor is able to participate in cooperative multithreading. If this processor declares itself cooperative, it will share a thread with other cooperative processors. Otherwise it will run in a dedicated Java thread.
    There are specific requirements that all processing methods of a cooperative processor must follow:
    - each call must take a reasonably small amount of time (up to a millisecond). Violations will manifest as increased latency due to slower switching of processors.
    - should also not attempt any blocking operations, such as I/O operations, waiting for locks/semaphores or sleep operations. Violations of this rule will manifest as less than 100% CPU usage under maximum load (note that this is possible for other reasons too, for example if the network is the bottleneck or if parking time is too high). The processor must also return as soon as the outbox rejects an item (that is when the offer() method returns false).
    Non-cooperative processors are allowed to block, but still must return at least once per second (that is, they should not block indeterminately). If they block longer, snapshots will take longer to complete and job will respond more slowly to termination: Jet doesn't interrupt the dedicated threads if it wants them to cancel, it waits for them to return.
    Jet prefers cooperative processors because they result in a greater overall throughput. A processor should be non-cooperative only if it involves blocking operations, which would cause all other processors on the same shared thread to starve.
    Processor instances of a single vertex are allowed to return different values, but a single processor instance must always return the same value.
    The default implementation returns true.
  - init
```
default void init(@Nonnull
                  Outbox outbox,
                  @Nonnull
                  Processor.Context context)
           throws Exception
```
    Initializes this processor with the outbox that the processing methods must use to deposit their output items. This method will be called exactly once and strictly before any calls to other methods (except for the isCooperative() method.
    Even if this processor is cooperative, this method is allowed to do blocking operations.
    The default implementation does nothing.
    
    Parameters:
    
    context - useful environment information
    
    Throws:
    
    Exception
  - process
```
default void process(int ordinal,
                     @Nonnull
                     Inbox inbox)
```
    Called with a batch of items retrieved from an inbound edge's stream. The items are in the inbox and this method may process zero or more of them, removing each item after it is processed. Does not remove an item until it is done with it.
    If the method returns with items still present in the inbox, it will be called again before proceeding to call any other method (except for snapshotCommitFinish(boolean)), with the same items. In other words, no more items are added to the inbox if the previous call didn't return an empty inbox.
    There is at least one item in the inbox when this method is called.
    The default implementation throws an exception, it is suitable for source processors.
    
    Parameters:
    
    ordinal - ordinal of the inbound edge
    
    inbox - the inbox containing the pending items
  - tryProcessWatermark
```
boolean tryProcessWatermark(@Nonnull
                            Watermark watermark)
```
    Tries to process the supplied watermark. The value is always greater than in the previous call. The watermark is delivered for processing after it has been received from all the edges.
    The implementation may choose to process only partially and return false, in which case it will be called again later with the same timestamp before any other processing method is called. Before the method returns true, it should emit the watermark to the downstream processors. Sink processors can ignore the watermark and simply return true.
    Caution for Jobs With the At-Least-Once Guarantee
    Jet propagates the value of the watermark by sending watermark items interleaved with the regular stream items. If a job configured with the at-least-once processing guarantee gets restarted, the same watermark, like any other stream item, can be delivered again. Therefore the processor may be asked to process a watermark older than the one it had already processed before the restart.
    
    Parameters:
    
    watermark - watermark to be processed
    
    Returns:
    
    true if this watermark has now been processed, false to call this method again with the same watermark
  - tryProcess
```
default boolean tryProcess()
```
    This method will be called periodically and only when the current batch of items in the inbox has been exhausted. It can be used to produce output in the absence of input or to do general maintenance work. If the job restores state from a snapshot, this method is called for the first time after finishSnapshotRestore().
    If the call returns false, it will be called again before proceeding to call any other processing method. Default implementation returns true.
  - completeEdge
```
default boolean completeEdge(int ordinal)
```
    Called after the edge input with the supplied ordinal is exhausted. If it returns false, it will be called again before proceeding to call any other method.
    If this method tried to offer to the outbox and the offer call returned false, this method must also return false and retry the offer in the next call.
    
    Returns:
    
    true if the processor is now done completing the edge, false to call this method again
  - complete
```
default boolean complete()
```
    Called after all the inbound edges' streams are exhausted. If it returns false, it will be invoked again until it returns true. For example, a streaming source processor will return false forever. Unlike other methods which guarantee that no other method is called until they return true, saveToSnapshot() can be called even though this method returned false.
    After this method is called, no other processing methods are called on this processor, except for snapshotCommitFinish(boolean).
    Non-cooperative processors are required to return from this method from time to time to give the system a chance to check for snapshot requests and job cancellation. The time the processor spends in this method affects the latency of snapshots and job cancellations.
    
    Returns:
    
    true if the completing step is now done, false to call this method again
  - saveToSnapshot
```
default boolean saveToSnapshot()
```
    Stores the processor's state to a state snapshot by adding items to the outbox's snapshot bucket. If this method returns false, it will be called again before proceeding to call any other method.
    This method will only be called after a call to process() returns with an empty inbox. After all the input is exhausted, it is also called between complete() calls. Once complete() returns true, this method won't be called anymore.
    The default implementation does nothing and returns true.
    
    Returns:
    
    true if this step is done, false to call this method again
  - snapshotCommitPrepare
```
default boolean snapshotCommitPrepare()
```
    Prepares the transactions for commit after the snapshot is completed. If the processor doesn't use transactions, it can just return true or rely on the no-op default implementation. This is the first phase of a two-phase commit.
    This method is called right after saveToSnapshot(). After this method returns true, Jet will return to call the processing methods again. Some time later, snapshotCommitFinish(boolean) will be called.
    When this processor communicates with an external transactional store, it should do the following:
    - mark the current active transaction with the external system as prepared and stop using it. The prepared transaction will be committed when snapshotCommitFinish(boolean) with commitTransactions == true is called
    - store IDs of the pending transaction(s) to the snapshot. Note that there can be multiple prepared transactions if the previous snapshot completed with commitTransactions == false
    - optionally, start a new active transaction that will be used to handle input or produce output until onSnapshotCompleted() is called. If the implementation doesn't start a new active transaction, it can opt to not process more input or emit any output
    This method is skipped if the snapshot was initiated using Job.exportSnapshot(java.lang.String). If this method is skipped, snapshotCommitFinish(boolean) will be skipped too.
    Returns:
    
    true if this step is done, false to call this method again
    
    Since:
    
    Jet 4.0
  - snapshotCommitFinish
```
default boolean snapshotCommitFinish(boolean success)
```
    This is the second phase of a two-phase commit. Jet calls it after the snapshot was successfully saved on all other processors in the job on all cluster members.
    This method can be called even when the process() method didn't process the items in the inbox. For this reason this method must not add any items to the outbox. It is also called between complete() calls. Once complete() returns true, this method can still be called to finish the snapshot that was started before this processor completed.
    The processor should do the following:
    - if success == true, it should commit the prepared transactions. It must not continue to use the just-committed transaction ID - we stored it in the latest snapshot and after restart we commit the transactions with IDs found in the snapshot - we would commit the items written after the snapshot.
    - if success == false, it should do nothing to the prepared transactions. If it didn't create a new active transaction in saveToSnapshot(), it can continue to use the last active transaction as active.
    The method is called repeatedly until it eventually returns true. No other method on this processor will be called before it returns true.
    Error handling
    The two-phase commit protocol requires that the second phase must eventually succeed. If you're not able to commit your transactions now, you should either return false and try again later, or you can throw a RestartableException to cause a job restart; the processor is required to commit the transactions with IDs stored in the state snapshot after the restart in restoreFromSnapshot(com.hazelcast.jet.core.Inbox). This is necessary to ensure exactly-once processing of transactional processors.
    The default implementation takes no action and returns true.
    Parameters:
    
    success - true, if the first snapshot phase completed successfully
    
    Returns:
    
    true if this step is done, false to call this method again
    
    Since:
    
    Jet 4.0
  - restoreFromSnapshot
```
default void restoreFromSnapshot(@Nonnull
                                 Inbox inbox)
```
    Called when a batch of items is received during the "restore from snapshot" operation. The type of items in the inbox is Map.Entry, key and value types are exactly as they were saved in saveToSnapshot(). This method may emit items to the outbox.
    If this method returns with items still present in the inbox, it will be called again before proceeding to call any other methods. No more items are added to the inbox if the method didn't return with an empty inbox. It is never called with an empty inbox. After all items are processed, finishSnapshotRestore() is called.
    If a transaction ID saved in snapshotCommitPrepare() is restored, this method should commit that transaction. If the processor is unable to commit those transactions, data loss or duplication might occur. The processor must be ready to restore a transaction ID that no longer exists in the remote system: either because the transaction was already committed (this is the most common case) or because the transaction timed out in the remote system. Also the job ID, if it's part of the transaction ID, can be different from the current job ID, if the job was started from an exported state. These cases should be handled gracefully.
    The default implementation throws an exception - if you emit something in saveToSnapshot(), you must be able to handle it here. If you don't override saveToSnapshot(), throwing an exception here will never happen.
  - finishSnapshotRestore
```
default boolean finishSnapshotRestore()
```
    Called after a job was restarted from a snapshot and the processor has consumed all the snapshot data in restoreFromSnapshot(com.hazelcast.jet.core.Inbox).
    If this method returns false, it will be called again before proceeding to call any other methods.
    If this method tried to offer to the outbox and the offer call returned false, this method must also return false and retry the offer in the next call.
    The default implementation takes no action and returns true.
    
    Returns:
    
    true if this step is done, false to call this method again
  - close
```
default void close()
            throws Exception
```
    Called as the last method in the processor lifecycle. It is called whether the job was successful or not, and strictly before ProcessorSupplier.close(java.lang.Throwable) is called on this member. The method might get called even if init(com.hazelcast.jet.core.Outbox, com.hazelcast.jet.core.Processor.Context) method was not yet called.
    The method will be called right after complete() returns true, that is before the job is finished. The job might still be running other processors.
    See closeIsCooperative() regarding the cooperative behavior of this method.
    If this method throws an exception, it is logged but it won't be reported as a job failure or cause the job to fail.
    The default implementation does nothing.
    
    Throws:
    
    Exception
  - closeIsCooperative
```
default boolean closeIsCooperative()
```
    Returns true if the close() method of this processor is cooperative. If it's not, the call to the close() method is off-loaded to another thread.
    This flag is ignored for non-cooperative processors.

Interface Processor

Processing methods

Transactional processors

How the methods are called

Nested Class Summary

Method Summary

Method Detail

isCooperative

init

process

tryProcessWatermark

Caution for Jobs With the At-Least-Once Guarantee

tryProcess

completeEdge

complete

saveToSnapshot

snapshotCommitPrepare

snapshotCommitFinish

Error handling

restoreFromSnapshot

finishSnapshotRestore

close

closeIsCooperative