projection

package projection

Ordering

Alphabetic

Visibility

Public
All

Type Members

sealed trait ProjectionConfig extends AnyRef

Annotations
@InternalApi()
class ProjectionRegistryActor extends Actor with ActorLogging
Build an in-memory, CRDT-backed representation of the status of each projection worker.
Build an in-memory, CRDT-backed representation of the status of each projection worker. Each instance of this actor communicates with the
```
WorkerCoordinator
```
running locally to propagate requests and retrieve status of the actual worker actor. The retrieved data for requested and observed status is propagated to other peers.
See also https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md
WorkerCoordinator }}} requests and retrieve status of the actual worker actor. The retrieved data for requested and observed status is propagated to other peers.
See also https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md
sealed trait WorkerConfig extends AnyRef

Annotations
@InternalApi()
class WorkerCoordinator extends Actor with ActorLogging
The WorkerCoordinator actor spawns as soon as it receives
The WorkerCoordinator actor spawns as soon as it receives
```
EnsureActive(tagName)
```
messages from the cluster and remains alive forever. Even when the requested status for given
```
WorkerCoordinates
```
dictate the status to be
```
Stopped
```
the
```
WorkerCoordinator
```
will exist. When getting the first EnsureActive message, the WorkerCoordinator pings back to the
```
ProjectionRegistryActor
```
to indicate “I’m here, I represent a worker for this WorkerCoordinates”. That is, when the cluster starts up there are as many instances of
```
WorkerCoordinator
```
as (numProjections x numTags). The same is not true for the actual worker actors running the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
ProjectionRegistryActor }}} worker for this WorkerCoordinates”. That is, when the cluster starts up there are as many instances of
```
WorkerCoordinator
```
as (numProjections x numTags). The same is not true for the actual worker actors running the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} message, the WorkerCoordinator pings back to the
```
ProjectionRegistryActor
```
to indicate “I’m here, I represent a worker for this WorkerCoordinates”. That is, when the cluster starts up there are as many instances of
```
WorkerCoordinator
```
as (numProjections x numTags). The same is not true for the actual worker actors running the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
ProjectionRegistryActor }}} worker for this WorkerCoordinates”. That is, when the cluster starts up there are as many instances of
```
WorkerCoordinator
```
as (numProjections x numTags). The same is not true for the actual worker actors running the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
Stopped }}} message, the WorkerCoordinator pings back to the
```
ProjectionRegistryActor
```
to indicate “I’m here, I represent a worker for this WorkerCoordinates”. That is, when the cluster starts up there are as many instances of
```
WorkerCoordinator
```
as (numProjections x numTags). The same is not true for the actual worker actors running the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
ProjectionRegistryActor }}} worker for this WorkerCoordinates”. That is, when the cluster starts up there are as many instances of
```
WorkerCoordinator
```
as (numProjections x numTags). The same is not true for the actual worker actors running the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinates }}} the status to be
```
Stopped
```
the
```
WorkerCoordinator
```
will exist. When getting the first EnsureActive message, the WorkerCoordinator pings back to the
```
ProjectionRegistryActor
```
to indicate “I’m here, I represent a worker for this WorkerCoordinates”. That is, when the cluster starts up there are as many instances of
```
WorkerCoordinator
```
as (numProjections x numTags). The same is not true for the actual worker actors running the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
ProjectionRegistryActor }}} worker for this WorkerCoordinates”. That is, when the cluster starts up there are as many instances of
```
WorkerCoordinator
```
as (numProjections x numTags). The same is not true for the actual worker actors running the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} message, the WorkerCoordinator pings back to the
```
ProjectionRegistryActor
```
to indicate “I’m here, I represent a worker for this WorkerCoordinates”. That is, when the cluster starts up there are as many instances of
```
WorkerCoordinator
```
as (numProjections x numTags). The same is not true for the actual worker actors running the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
ProjectionRegistryActor }}} worker for this WorkerCoordinates”. That is, when the cluster starts up there are as many instances of
```
WorkerCoordinator
```
as (numProjections x numTags). The same is not true for the actual worker actors running the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
Stopped }}} message, the WorkerCoordinator pings back to the
```
ProjectionRegistryActor
```
to indicate “I’m here, I represent a worker for this WorkerCoordinates”. That is, when the cluster starts up there are as many instances of
```
WorkerCoordinator
```
as (numProjections x numTags). The same is not true for the actual worker actors running the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
ProjectionRegistryActor }}} worker for this WorkerCoordinates”. That is, when the cluster starts up there are as many instances of
```
WorkerCoordinator
```
as (numProjections x numTags). The same is not true for the actual worker actors running the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
EnsureActive(tagName) }}} cluster and remains alive forever. Even when the requested status for given
```
WorkerCoordinates
```
dictate the status to be
```
Stopped
```
the
```
WorkerCoordinator
```
will exist. When getting the first EnsureActive message, the WorkerCoordinator pings back to the
```
ProjectionRegistryActor
```
to indicate “I’m here, I represent a worker for this WorkerCoordinates”. That is, when the cluster starts up there are as many instances of
```
WorkerCoordinator
```
as (numProjections x numTags). The same is not true for the actual worker actors running the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
ProjectionRegistryActor }}} worker for this WorkerCoordinates”. That is, when the cluster starts up there are as many instances of
```
WorkerCoordinator
```
as (numProjections x numTags). The same is not true for the actual worker actors running the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} message, the WorkerCoordinator pings back to the
```
ProjectionRegistryActor
```
to indicate “I’m here, I represent a worker for this WorkerCoordinates”. That is, when the cluster starts up there are as many instances of
```
WorkerCoordinator
```
as (numProjections x numTags). The same is not true for the actual worker actors running the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
ProjectionRegistryActor }}} worker for this WorkerCoordinates”. That is, when the cluster starts up there are as many instances of
```
WorkerCoordinator
```
as (numProjections x numTags). The same is not true for the actual worker actors running the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
Stopped }}} message, the WorkerCoordinator pings back to the
```
ProjectionRegistryActor
```
to indicate “I’m here, I represent a worker for this WorkerCoordinates”. That is, when the cluster starts up there are as many instances of
```
WorkerCoordinator
```
as (numProjections x numTags). The same is not true for the actual worker actors running the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
ProjectionRegistryActor }}} worker for this WorkerCoordinates”. That is, when the cluster starts up there are as many instances of
```
WorkerCoordinator
```
as (numProjections x numTags). The same is not true for the actual worker actors running the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinates }}} the status to be
```
Stopped
```
the
```
WorkerCoordinator
```
will exist. When getting the first EnsureActive message, the WorkerCoordinator pings back to the
```
ProjectionRegistryActor
```
to indicate “I’m here, I represent a worker for this WorkerCoordinates”. That is, when the cluster starts up there are as many instances of
```
WorkerCoordinator
```
as (numProjections x numTags). The same is not true for the actual worker actors running the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
ProjectionRegistryActor }}} worker for this WorkerCoordinates”. That is, when the cluster starts up there are as many instances of
```
WorkerCoordinator
```
as (numProjections x numTags). The same is not true for the actual worker actors running the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} message, the WorkerCoordinator pings back to the
```
ProjectionRegistryActor
```
to indicate “I’m here, I represent a worker for this WorkerCoordinates”. That is, when the cluster starts up there are as many instances of
```
WorkerCoordinator
```
as (numProjections x numTags). The same is not true for the actual worker actors running the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
ProjectionRegistryActor }}} worker for this WorkerCoordinates”. That is, when the cluster starts up there are as many instances of
```
WorkerCoordinator
```
as (numProjections x numTags). The same is not true for the actual worker actors running the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
Stopped }}} message, the WorkerCoordinator pings back to the
```
ProjectionRegistryActor
```
to indicate “I’m here, I represent a worker for this WorkerCoordinates”. That is, when the cluster starts up there are as many instances of
```
WorkerCoordinator
```
as (numProjections x numTags). The same is not true for the actual worker actors running the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
ProjectionRegistryActor }}} worker for this WorkerCoordinates”. That is, when the cluster starts up there are as many instances of
```
WorkerCoordinator
```
as (numProjections x numTags). The same is not true for the actual worker actors running the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor
WorkerCoordinator }}} the queryByTag streams. The actual worker actors are only started when requested and are stopped when requested.
An advantage of this pattern is that, because a WorkerCoordinator actor will know the projectionName and the tagName before the actual worker actor is created we can now make up a unique repeatable name for the worker actor. This unique String is called the workerKey. The workerKey is used in the worker actor name. This is useful in monitoring since the information regarding projection and tagName is easily accessible, but also because the ActorSystem can't run two actors with the same name. Trying to spawn the same worker in a single node will cause a failure.
See https://github.com/playframework/play-meta/blob/master/docs/design/projections-design.md#workercoordinator-actor

Value Members

object ProjectionConfig

Annotations
@InternalApi()
object ProjectionRegistryActor

Annotations
@ApiMayChange()
object WorkerConfig
object WorkerCoordinator

Packages

projection

package projection

Type Members

Value Members

Ungrouped

Packages

projection 

package projection

Type Members

Value Members

Ungrouped

projection