Package akka.persistence.query.typed.javadsl

Class EventsBySliceFirehoseQuery

java.lang.Object

akka.persistence.query.typed.javadsl.EventsBySliceFirehoseQuery

All Implemented Interfaces:

ReadJournal, EventsBySliceQuery, EventsBySliceStartingFromSnapshotsQuery, EventTimestampQuery, LoadEventQuery

public final class EventsBySliceFirehoseQuery
extends java.lang.Object
implements ReadJournal, EventsBySliceQuery, EventsBySliceStartingFromSnapshotsQuery, EventTimestampQuery, LoadEventQuery

This wrapper of EventsBySliceQuery gives better scalability when many consumers retrieve the same events, for example many Projections of the same entity type. The purpose is to share the stream of events from the database and fan out to connected consumer streams. Thereby fewer queries and loading of events from the database.

It is retrieved with:

 EventsBySliceQuery queries =
   PersistenceQuery.get(system).getReadJournalFor(EventsBySliceQuery.class, EventsBySliceFirehoseQuery.Identifier());
 

Corresponding Scala API is in EventsBySliceFirehoseQuery.

Configuration settings can be defined in the configuration section with the absolute path corresponding to the identifier, which is "akka.persistence.query.events-by-slice-firehose" for the default Identifier(). See reference.conf.

Constructor Summary

Constructors

Constructor	Description
EventsBySliceFirehoseQuery(EventsBySliceFirehoseQuery delegate)

Method Summary

Modifier and Type	Method	Description
<Event> Source<EventEnvelope<Event>,NotUsed>	eventsBySlices(java.lang.String entityType, int minSlice, int maxSlice, Offset offset)	Query events for given slices.
<Snapshot,Event> Source<EventEnvelope<Event>,NotUsed>	eventsBySlicesStartingFromSnapshots(java.lang.String entityType, int minSlice, int maxSlice, Offset offset, java.util.function.Function<Snapshot,Event> transformSnapshot)	Same as EventsBySliceQuery but with the purpose to use snapshots as starting points and thereby reducing number of events that have to be loaded.
static java.lang.String	Identifier()
<Event> java.util.concurrent.CompletionStage<EventEnvelope<Event>>	loadEnvelope(java.lang.String persistenceId, long sequenceNr)	Load a single event on demand.
int	sliceForPersistenceId(java.lang.String persistenceId)
java.util.List<Pair<java.lang.Integer,java.lang.Integer>>	sliceRanges(int numberOfRanges)
java.util.concurrent.CompletionStage<java.util.Optional<java.time.Instant>>	timestampOf(java.lang.String persistenceId, long sequenceNr)

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

EventsBySliceFirehoseQuery

public EventsBySliceFirehoseQuery(EventsBySliceFirehoseQuery delegate)

Method Detail

Identifier

public static java.lang.String Identifier()

sliceForPersistenceId

public int sliceForPersistenceId(java.lang.String persistenceId)

Specified by:

sliceForPersistenceId in interface EventsBySliceQuery

Specified by:

sliceForPersistenceId in interface EventsBySliceStartingFromSnapshotsQuery

eventsBySlices

public <Event> Source<EventEnvelope<Event>,NotUsed> eventsBySlices(java.lang.String entityType,
                                                                         int minSlice,
                                                                         int maxSlice,
                                                                         Offset offset)

Description copied from interface: EventsBySliceQuery

Query events for given slices. A slice is deterministically defined based on the persistence id. The purpose is to evenly distribute all persistence ids over the slices.

The consumer can keep track of its current position in the event stream by storing the offset and restart the query from a given offset after a crash/restart.

The exact meaning of the offset depends on the journal and must be documented by the read journal plugin. It may be a sequential id number that uniquely identifies the position of each event within the event stream. Distributed data stores cannot easily support those semantics and they may use a weaker meaning. For example it may be a timestamp (taken when the event was created or stored). Timestamps are not unique and not strictly ordered, since clocks on different machines may not be synchronized.

In strongly consistent stores, where the offset is unique and strictly ordered, the stream should start from the next event after the offset. Otherwise, the read journal should ensure that between an invocation that returned an event with the given offset, and this invocation, no events are missed. Depending on the journal implementation, this may mean that this invocation will return events that were already returned by the previous invocation, including the event with the passed in offset.

The returned event stream should be ordered by offset if possible, but this can also be difficult to fulfill for a distributed data store. The order must be documented by the read journal plugin.

The stream is not completed when it reaches the end of the currently stored events, but it continues to push new events when new events are persisted. Corresponding query that is completed when it reaches the end of the currently stored events is provided by CurrentEventsBySliceQuery.currentEventsBySlices.

Specified by:

eventsBySlices in interface EventsBySliceQuery

eventsBySlicesStartingFromSnapshots

public <Snapshot,Event> Source<EventEnvelope<Event>,NotUsed> eventsBySlicesStartingFromSnapshots(java.lang.String entityType,
                                                                                                             int minSlice,
                                                                                                             int maxSlice,
                                                                                                             Offset offset,
                                                                                                             java.util.function.Function<Snapshot,Event> transformSnapshot)

Description copied from interface: EventsBySliceStartingFromSnapshotsQuery

Same as EventsBySliceQuery but with the purpose to use snapshots as starting points and thereby reducing number of events that have to be loaded. This can be useful if the consumer start from zero without any previously processed offset or if it has been disconnected for a long while and its offset is far behind.

Specified by:

eventsBySlicesStartingFromSnapshots in interface EventsBySliceStartingFromSnapshotsQuery

sliceRanges

public java.util.List<Pair<java.lang.Integer,java.lang.Integer>> sliceRanges(int numberOfRanges)

Specified by:

sliceRanges in interface EventsBySliceQuery

Specified by:

sliceRanges in interface EventsBySliceStartingFromSnapshotsQuery

timestampOf

public java.util.concurrent.CompletionStage<java.util.Optional<java.time.Instant>> timestampOf(java.lang.String persistenceId,
                                                                                               long sequenceNr)

Specified by:

timestampOf in interface EventTimestampQuery

loadEnvelope

public <Event> java.util.concurrent.CompletionStage<EventEnvelope<Event>> loadEnvelope(java.lang.String persistenceId,
                                                                                       long sequenceNr)

Description copied from interface: LoadEventQuery

Load a single event on demand. The CompletionStage is completed with a NoSuchElementException if the event for the given persistenceId and sequenceNr doesn't exist.

Specified by:

loadEnvelope in interface LoadEventQuery