Skip to content

Commit

Permalink
Replacing "master" and "slave"
Browse files Browse the repository at this point in the history 
Per a request from Michael Minella, I replaced "master" with "manager" and "slave" with "worker" in the Spring Batch Reference Guide. I heartily concur with replacing terms that have such dark connotations.
  • Loading branch information
@mminella
Jay Bryant authored and mminella committed Aug 2, 2019
1 parent 3743894 commit 85b3e90
Show file tree
Hide file tree
Showing 5 changed files with 59 additions and 59 deletions.
Binary file modified spring-batch-docs/asciidoc/images/partitioning-overview.png
View file
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file modified spring-batch-docs/asciidoc/images/remote-chunking.png
View file
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
18 changes: 9 additions & 9 deletions spring-batch-docs/asciidoc/jsr-352.adoc
View file
Original file line number Diff line number Diff line change
Expand Up @@ -559,7 +559,7 @@ Traditional Spring Batch jobs have four ways of scaling (the last two capable of
* Multiple threads - Executing a single step via multiple threads.


* Partitioning - Dividing the data up for parallel processing (master/slave).
* Partitioning - Dividing the data up for parallel processing (manager/worker).


* Remote Chunking - Executing the processor piece of logic remotely.
Expand All @@ -584,8 +584,8 @@ JSR-352 provides two options for scaling batch jobs. Both options support only
==== Partitioning

Conceptually, partitioning in JSR-352 is the same as it is in Spring Batch. Meta-data is provided
to each slave to identify the input to be processed with the slaves reporting back to the master the
results upon completion. However, there are some important differences:
to each worker to identify the input to be processed, with the workers reporting back to the manager the
results upon completion. However, there are some important differences:

* Partitioned `Batchlet` - This will run multiple instances of the
configured `Batchlet` on multiple threads. Each instance will have
Expand All @@ -610,10 +610,10 @@ Conceptually, partitioning in JSR-352 is the same as it is in Spring Batch. Met


* `StepExecutions` - In Spring Batch, partitioned steps are run as
master/slave. Within JSR-352, the same configuration occurs. However, the slave steps do
manager/worker. Within JSR-352, the same configuration occurs. However, the worker steps do
not get official `StepExecutions`. Because of that, calls to
`JsrJobOperator#getStepExecutions(long jobExecutionId)` will only
return the `StepExecution` for the master.
return the `StepExecution` for the manager.

[NOTE]
====
Expand All @@ -623,16 +623,16 @@ via the `JobExplorer` and Spring Batch Admin.
====


* Compensating logic - Since Spring Batch implements the master/slave logic of
* Compensating logic - Since Spring Batch implements the manager/worker logic of
partitioning using steps, `StepExecutionListeners` can be used to
handle compensating logic if something goes wrong. However, since the slaves JSR-352
handle compensating logic if something goes wrong. However, since the workers JSR-352
provides a collection of other components for the ability to provide compensating logic when
errors occur and to dynamically set the exit status. These components include the following:

|===============
|__Artifact Interface__|__Description__
|`javax.batch.api.partition.PartitionCollector`|Provides a way for slave steps to send information back to the
master. There is one instance per slave thread.
|`javax.batch.api.partition.PartitionCollector`|Provides a way for worker steps to send information back to the
manager. There is one instance per worker thread.
|`javax.batch.api.partition.PartitionAnalyzer`|End point that receives the information collected by the
`PartitionCollector` as well as the resulting
statuses from a completed partition.
Expand Down
34 changes: 17 additions & 17 deletions spring-batch-docs/asciidoc/scalability.adoc
View file
Original file line number Diff line number Diff line change
Expand Up @@ -238,13 +238,13 @@ pattern:
.Remote Chunking
image::{batch-asciidoc}images/remote-chunking.png[Remote Chunking, scaledwidth="60%"]

The master component is a single process, and the slaves are multiple remote processes.
This pattern works best if the master is not a bottleneck, so the processing must be more
The manager component is a single process, and the workers are multiple remote processes.
This pattern works best if the manager is not a bottleneck, so the processing must be more
expensive than the reading of items (as is often the case in practice).

The master is an implementation of a Spring Batch `Step` with the `ItemWriter` replaced
The manager is an implementation of a Spring Batch `Step` with the `ItemWriter` replaced
by a generic version that knows how to send chunks of items to the middleware as
messages. The slaves are standard listeners for whatever middleware is being used (for
messages. The workers are standard listeners for whatever middleware is being used (for
example, with JMS, they would be `MesssageListener` implementations), and their role is
to process the chunks of items using a standard `ItemWriter` or `ItemProcessor` plus
`ItemWriter`, through the `ChunkProcessor` interface. One of the advantages of using this
Expand Down Expand Up @@ -274,12 +274,12 @@ pattern:
image::{batch-asciidoc}images/partitioning-overview.png[Partitioning Overview, scaledwidth="60%"]

The `Job` runs on the left-hand side as a sequence of `Step` instances, and one of the
`Step` instances is labeled as a master. The slaves in this picture are all identical
instances of a `Step`, which could in fact take the place of the master, resulting in the
same outcome for the `Job`. The slaves are typically going to be remote services but
could also be local threads of execution. The messages sent by the master to the slaves
`Step` instances is labeled as a manager. The workers in this picture are all identical
instances of a `Step`, which could in fact take the place of the manager, resulting in the
same outcome for the `Job`. The workers are typically going to be remote services but
could also be local threads of execution. The messages sent by the manager to the workers
in this pattern do not need to be durable or have guaranteed delivery. Spring Batch
metadata in the `JobRepository` ensures that each slave is executed once and only once for
metadata in the `JobRepository` ensures that each worker is executed once and only once for
each `Job` execution.

The SPI in Spring Batch consists of a special implementation of `Step` (called the
Expand All @@ -290,7 +290,7 @@ and their role is shown in the following sequence diagram:
.Partitioning SPI
image::{batch-asciidoc}images/partitioning-spi.png[Partitioning SPI, scaledwidth="60%"]

The `Step` on the right in this case is the "remote" slave, so, potentially, there are
The `Step` on the right in this case is the "`remote`" worker, so, potentially, there are
many objects and or processes playing this role, and the `PartitionStep` is shown driving
the execution.

Expand All @@ -299,7 +299,7 @@ The following example shows the `PartitionStep` configuration:

[source, xml, role="xmlContent"]
----
<step id="step1.master">
<step id="step1.manager">
<partition step="step1" partitioner="partitioner">
<handler grid-size="10" task-executor="taskExecutor"/>
</partition>
Expand All @@ -313,8 +313,8 @@ The following example shows the `PartitionStep` configuration using java configu
[source, java, role="javaContent"]
----
@Bean
public Step step1Master() {
return stepBuilderFactory.get("step1.master")
public Step step1Manager() {
return stepBuilderFactory.get("step1.manager")
.<String, String>partitioner("step1", partitioner())
.step(step1())
.gridSize(10)
Expand All @@ -332,7 +332,7 @@ https://github.com/spring-projects/spring-batch/tree/master/spring-batch-samples
Batch Samples] (see `Partition*Job.xml` configuration).

Spring Batch creates step executions for the partitions called "step1:partition0", and so
on. Many people prefer to call the master step "step1:master" for consistency. You can
on. Many people prefer to call the manager step "step1:manager" for consistency. You can
use an alias for the step (by specifying the `name` attribute instead of the `id`
attribute).

Expand Down Expand Up @@ -367,7 +367,7 @@ following example:

[source, xml, role="xmlContent"]
----
<step id="step1.master">
<step id="step1.manager">
<partition step="step1" handler="handler"/>
</step>
Expand All @@ -386,8 +386,8 @@ as shown in the following example:
[source, java, role="javaContent"]
----
@Bean
public Step step1Master() {
return stepBuilderFactory.get("step1.master")
public Step step1Manager() {
return stepBuilderFactory.get("step1.manager")
.partitioner("step1", partitioner())
.partitionHandler(partitionHandler())
.build();
Expand Down
66 changes: 33 additions & 33 deletions spring-batch-docs/asciidoc/spring-batch-integration.adoc
View file
Original file line number Diff line number Diff line change
Expand Up @@ -718,12 +718,12 @@ public Job chunkJob() {
----

The `ItemReader` reference points to the bean you want
to use for reading data on the master. The `ItemWriter` reference
to use for reading data on the manager. The `ItemWriter` reference
points to a special `ItemWriter`
(called `ChunkMessageChannelItemWriter`),
as described above. The processor (if any) is left off the
master configuration, as it is configured on the worker. The
following configuration provides a basic master setup. You
manager configuration, as it is configured on the worker. The
following configuration provides a basic manager setup. You
should check any additional component properties, such as
throttle limits and so on, when implementing your use case.

Expand Down Expand Up @@ -878,7 +878,7 @@ public org.apache.activemq.ActiveMQConnectionFactory connectionFactory() {
}
/*
* Configure inbound flow (requests coming from the master)
* Configure inbound flow (requests coming from the manager)
*/
@Bean
public DirectChannel requests() {
Expand All @@ -894,7 +894,7 @@ public IntegrationFlow inboundFlow(ActiveMQConnectionFactory connectionFactory)
}
/*
* Configure outbound flow (replies going to the master)
* Configure outbound flow (replies going to the manager)
*/
@Bean
public DirectChannel replies() {
Expand Down Expand Up @@ -925,15 +925,15 @@ public ChunkProcessorChunkHandler<Integer> chunkProcessorChunkHandler() {
----

Most of these configuration items should look familiar from the
master configuration. Workers do not need access to
manager configuration. Workers do not need access to
the Spring Batch `JobRepository` nor
to the actual job configuration file. The main bean of interest
is the `chunkProcessorChunkHandler`. The
`chunkProcessor` property of `ChunkProcessorChunkHandler` takes a
configured `SimpleChunkProcessor`, which is where you would provide a reference to your
`ItemWriter` (and, optionally, your
`ItemProcessor`) that will run on the worker
when it receives chunks from the master.
when it receives chunks from the manager.

For more information, see the section of the "Scalability" chapter on
link:$$https://docs.spring.io/spring-batch/reference/html/scalability.html#remoteChunking$$[Remote Chunking].
Expand All @@ -942,16 +942,16 @@ Starting from version 4.1, Spring Batch Integration introduces the `@EnableBatch
annotation that can be used to simplify a remote chunking setup. This annotation provides
two beans that can be autowired in the application context:

* `RemoteChunkingMasterStepBuilderFactory`: used to configure the master step
* `RemoteChunkingMasterStepBuilderFactory`: used to configure the manager step
* `RemoteChunkingWorkerBuilder`: used to configure the remote worker integration flow

These APIs take care of configuring a number of components as described in the following diagram:

.Remote Chunking Configuration
image::{batch-asciidoc}images/remote-chunking-config.png[Remote Chunking Configuration, scaledwidth="80%"]

On the master side, the `RemoteChunkingMasterStepBuilderFactory` allows you to
configure a master step by declaring:
On the manager side, the `RemoteChunkingMasterStepBuilderFactory` lets you
configure a manager step by declaring:

* the item reader to read items and send them to workers
* the output channel ("Outgoing requests") to send requests to workers
Expand All @@ -962,10 +962,10 @@ A `ChunkMessageChannelItemWriter` and the `MessagingTemplate` are not needed to

On the worker side, the `RemoteChunkingWorkerBuilder` allows you to configure a worker to:

* listen to requests sent by the master on the input channel ("Incoming requests")
* listen to requests sent by the manager on the input channel ("Incoming requests")
* call the `handleChunk` method of `ChunkProcessorChunkHandler` for each request
with the configured `ItemProcessor` and `ItemWriter`
* send replies on the output channel ("Outgoing replies") to the master
* send replies on the output channel ("Outgoing replies") to the manager

There is no need to explicitly configure the `SimpleChunkProcessor`
and the `ChunkProcessorChunkHandler` (Those can be explicitly configured if required).
Expand All @@ -979,14 +979,14 @@ The following example shows how to use these APIs:
public class RemoteChunkingJobConfiguration {
@Configuration
public static class MasterConfiguration {
public static class ManagerConfiguration {
@Autowired
private RemoteChunkingMasterStepBuilderFactory masterStepBuilderFactory;
private RemoteChunkingMasterStepBuilderFactory managerStepBuilderFactory;
@Bean
public TaskletStep masterStep() {
return this.masterStepBuilderFactory.get("masterStep")
public TaskletStep managerStep() {
return this.managerStepBuilderFactory.get("managerStep")
.chunk(100)
.reader(itemReader())
.outputChannel(requests()) // requests sent to workers
Expand All @@ -1009,8 +1009,8 @@ public class RemoteChunkingJobConfiguration {
return this.workerBuilder
.itemProcessor(itemProcessor())
.itemWriter(itemWriter())
.inputChannel(requests()) // requests received from the master
.outputChannel(replies()) // replies sent to the master
.inputChannel(requests()) // requests received from the manager
.outputChannel(replies()) // replies sent to the manager
.build();
}
Expand Down Expand Up @@ -1130,7 +1130,7 @@ configuration:
----
/*
* Configuration of the master side
* Configuration of the manager side
*/
@Bean
public PartitionHandler partitionHandler() {
Expand Down Expand Up @@ -1239,7 +1239,7 @@ You must also ensure that the partition `handler` attribute maps to the `partiti
[source, xml, role="xmlContent"]
----
<job id="personJob">
<step id="step1.master">
<step id="step1.manager">
<partition partitioner="partitioner" handler="partitionHandler"/>
...
</step>
Expand All @@ -1251,7 +1251,7 @@ You must also ensure that the partition `handler` attribute maps to the `partiti
----
public Job personJob() {
return jobBuilderFactory.get("personJob")
.start(stepBuilderFactory.get("step1.master")
.start(stepBuilderFactory.get("step1.manager")
.partitioner("step1.worker", partitioner())
.partitionHandler(partitionHandler())
.build())
Expand All @@ -1265,7 +1265,7 @@ link:$$https://github.com/spring-projects/spring-batch/tree/master/spring-batch-
The `@EnableBatchIntegration` annotation that can be used to simplify a remote
partitioning setup. This annotation provides two beans useful for remote partitioning:

* `RemotePartitioningMasterStepBuilderFactory`: used to configure the master step
* `RemotePartitioningMasterStepBuilderFactory`: used to configure the manager step
* `RemotePartitioningWorkerStepBuilderFactory`: used to configure the worker step

These APIs take care of configuring a number of components as described in the following diagram:
Expand All @@ -1276,8 +1276,8 @@ image::{batch-asciidoc}images/remote-partitioning-polling-config.png[Remote Part
.Remote Partitioning Configuration (with replies aggregation)
image::{batch-asciidoc}images/remote-partitioning-aggregation-config.png[Remote Partitioning Configuration (with replies aggregation), scaledwidth="80%"]

On the master side, the `RemotePartitioningMasterStepBuilderFactory` allows you to
configure a master step by declaring:
On the manager side, the `RemotePartitioningMasterStepBuilderFactory` allows you to
configure a manager step by declaring:

* the `Partitioner` used to partition data
* the output channel ("Outgoing requests") to send requests to workers
Expand All @@ -1289,9 +1289,9 @@ The `MessageChannelPartitionHandler` and the `MessagingTemplate` are not needed

On the worker side, the `RemotePartitioningWorkerStepBuilderFactory` allows you to configure a worker to:

* listen to requests sent by the master on the input channel ("Incoming requests")
* listen to requests sent by the manager on the input channel ("Incoming requests")
* call the `handle` method of `StepExecutionRequestHandler` for each request
* send replies on the output channel ("Outgoing replies") to the master
* send replies on the output channel ("Outgoing replies") to the manager

There is no need to explicitly configure the `StepExecutionRequestHandler` (which can be explicitly configured if required).

Expand All @@ -1305,15 +1305,15 @@ The following example shows how to use these APIs:
public class RemotePartitioningJobConfiguration {
@Configuration
public static class MasterConfiguration {
public static class ManagerConfiguration {
@Autowired
private RemotePartitioningMasterStepBuilderFactory masterStepBuilderFactory;
private RemotePartitioningMasterStepBuilderFactory managerStepBuilderFactory;
@Bean
public Step masterStep() {
return this.masterStepBuilderFactory
.get("masterStep")
public Step managerStep() {
return this.managerStepBuilderFactory
.get("managerStep")
.partitioner("workerStep", partitioner())
.gridSize(10)
.outputChannel(outgoingRequestsToWorkers())
Expand All @@ -1335,8 +1335,8 @@ public class RemotePartitioningJobConfiguration {
public Step workerStep() {
return this.workerStepBuilderFactory
.get("workerStep")
.inputChannel(incomingRequestsFromMaster())
.outputChannel(outgoingRepliesToMaster())
.inputChannel(incomingRequestsFromManager())
.outputChannel(outgoingRepliesToManager())
.chunk(100)
.reader(itemReader())
.processor(itemProcessor())
Expand Down

0 comments on commit 85b3e90

Please sign in to comment.