diff --git a/multi/multi__addressing_all_instances_of_a_service.html b/multi/multi__addressing_all_instances_of_a_service.html index d5d8d26..ff921d3 100644 --- a/multi/multi__addressing_all_instances_of_a_service.html +++ b/multi/multi__addressing_all_instances_of_a_service.html @@ -1,3 +1,6 @@ - 3. Addressing all instances of a service
3. Addressing all instances of a service
Prev   Next

3. Addressing all instances of a service

The "destination" parameter is used in a Spring PathMatcher (with the path separator as a colon :) to determine if an instance will process the message. Using the example from above, "/bus/refresh?destination=customers:**" will target all instances of the "customers" service regardless of the rest of the service ID.

Prev   Next
2. Addressing an Instance Home 4. Service ID must be unique
\ No newline at end of file + 3. Addressing All Instances of a Service
3. Addressing All Instances of a Service
Prev   Next

3. Addressing All Instances of a Service

The “destination” parameter is used in a Spring PathMatcher (with the path separator +as a colon — :) to determine if an instance processes the message. Using the example +from earlier, /bus/refresh?destination=customers:** targets all instances of the +“customers” service regardless of the rest of the service ID.

Prev   Next
2. Addressing an Instance Home 4. Service ID Must Be Unique
\ No newline at end of file diff --git a/multi/multi__addressing_an_instance.html b/multi/multi__addressing_an_instance.html index 73fd0a0..e67a14a 100644 --- a/multi/multi__addressing_an_instance.html +++ b/multi/multi__addressing_an_instance.html @@ -1,3 +1,12 @@ - 2. Addressing an Instance
2. Addressing an Instance
Prev   Next

2. Addressing an Instance

Each instance of the application has a service ID, whose value can be set using spring.cloud.bus.id, and whose value is expected to be a colon-separated list of identifiers, in order of least specific to most specific. The default value is constructed from the environment as a combination of the spring.application.name and server.port (or spring.application.index if set). The default value of the ID is constructed in the form app:index:id where:

The HTTP endpoints accept a "destination" parameter, e.g. "/bus/refresh?destination=customers:9000", where the destination is a service ID. If the ID is owned by an instance on the Bus then it will process the message and all other instances will ignore it.

Prev   Next
1. Quick Start Home 3. Addressing all instances of a service
\ No newline at end of file + 2. Addressing an Instance
2. Addressing an Instance
Prev   Next

2. Addressing an Instance

Each instance of the application has a service ID, whose value can be set with +spring.cloud.bus.id and whose value is expected to be a colon-separated list of +identifiers, in order from least specific to most specific. The default value is +constructed from the environment as a combination of the spring.application.name and +server.port (or spring.application.index, if set). The default value of the ID is +constructed in the form of app:index:id, where:

The HTTP endpoints accept a “destination” parameter, such as +/bus/refresh?destination=customers:9000, where destination is a service ID. If the ID +is owned by an instance on the bus, it processes the message, and all other instances +ignore it.

Prev   Next
1. Quick Start Home 3. Addressing All Instances of a Service
\ No newline at end of file diff --git a/multi/multi__broadcasting_your_own_events.html b/multi/multi__broadcasting_your_own_events.html index e23288b..5154097 100644 --- a/multi/multi__broadcasting_your_own_events.html +++ b/multi/multi__broadcasting_your_own_events.html @@ -1,28 +1,27 @@ - 7. Broadcasting Your Own Events
7. Broadcasting Your Own Events
Prev   

7. Broadcasting Your Own Events

The Bus can carry any event of type RemoteApplicationEvent, but the -default transport is JSON and the deserializer needs to know which -types are going to be used ahead of time. To register a new type it -needs to be in a subpackage of org.springframework.cloud.bus.event.

To customise the event name you can use @JsonTypeName on your custom class -or rely on the default strategy which is to use the simple name of the class. -Note that both the producer and the consumer will need access to the class -definition.

7.1 Registering events in custom packages

If you cannot or don’t want to use a subpackage of org.springframework.cloud.bus.event -for your custom events, you must specify which packages to scan for events of -type RemoteApplicationEvent using @RemoteApplicationEventScan. Packages -specified with @RemoteApplicationEventScan include subpackages.

For example, if you have a custom event called FooEvent:

package com.acme;
+   7. Broadcasting Your Own Events
7. Broadcasting Your Own Events
Prev   
7. Broadcasting Your Own Events
The Bus can carry any event of type RemoteApplicationEvent. The default transport is
+JSON, and the deserializer needs to know which types are going to be used ahead of time.
+To register a new type, you must put it in a subpackage of
+org.springframework.cloud.bus.event.
To customise the event name, you can use @JsonTypeName on your custom class or rely on
+the default strategy, which is to use the simple name of the class.
[Note]Note
Both the producer and the consumer need access to the class definition.
7.1 Registering events in custom packages
If you cannot or do not want to use a subpackage of org.springframework.cloud.bus.event
+for your custom events, you must specify which packages to scan for events of type
+RemoteApplicationEvent by using the @RemoteApplicationEventScan annotation. Packages
+specified with @RemoteApplicationEventScan include subpackages.
For example, consider the following custom event, called MyEvent:
package com.acme;
 
-public class FooEvent extends RemoteApplicationEvent {
+public class MyEvent extends RemoteApplicationEvent {
     ...
-}
you can register this event with the deserializer in the following way:
package com.acme;
+}
You can register that event with the deserializer in the following way:
package com.acme;
 
 @Configuration
 @RemoteApplicationEventScan
 public class BusConfiguration {
     ...
 }
Without specifying a value, the package of the class where @RemoteApplicationEventScan
-is used will be registered. In this example com.acme will be registered using the
-package of BusConfiguration.
You can also explicitly specify the packages to scan using the value, basePackages or
-basePackageClasses properties on @RemoteApplicationEventScan. For example:
package com.acme;
+is used is registered. In this example, com.acme is registered by using the package of
+BusConfiguration.
You can also explicitly specify the packages to scan by using the value, basePackages
+or basePackageClasses properties on @RemoteApplicationEventScan, as shown in the
+following example:
package com.acme;
 
 @Configuration
 //@RemoteApplicationEventScan({"com.acme", "foo.bar"})
@@ -30,7 +29,6 @@ package of BusConfiguration.
You can also exp
 @RemoteApplicationEventScan(basePackageClasses = BusConfiguration.class)
 public class BusConfiguration {
     ...
-}
All examples of @RemoteApplicationEventScan above are equivalent,
-in that the com.acme package will be registered by explicitly specifying the
-packages on @RemoteApplicationEventScan. Note, you can specify multiple base
-packages to scan.
Prev   
6. Tracing Bus Events Home 

\ No newline at end of file
+}

All of the preceding examples of @RemoteApplicationEventScan are equivalent, in that the +com.acme package is registered by explicitly specifying the packages on +@RemoteApplicationEventScan.

[Note]Note

You can specify multiple base packages to scan.

Prev   
6. Tracing Bus Events Home 
\ No newline at end of file diff --git a/multi/multi__customizing_the_message_broker.html b/multi/multi__customizing_the_message_broker.html index 5bb25ba..a2ebcc8 100644 --- a/multi/multi__customizing_the_message_broker.html +++ b/multi/multi__customizing_the_message_broker.html @@ -1,17 +1,13 @@ - 5. Customizing the Message Broker
5. Customizing the Message Broker
Prev   Next

5. Customizing the Message Broker

Spring Cloud Bus uses -Spring Cloud Stream to -broadcast the messages so to get messages to flow you only need to -include the binder implementation of your choice in the -classpath. There are convenient starters specifically for the bus with -AMQP (RabbitMQ) and Kafka -(spring-cloud-starter-bus-[amqp,kafka]). Generally speaking -Spring Cloud Stream relies on Spring Boot autoconfiguration -conventions for configuring middleware, so for instance the AMQP -broker address can be changed with spring.rabbitmq.* -configuration properties. Spring Cloud Bus has a handful of native -configuration properties in spring.cloud.bus.* -(e.g. spring.cloud.bus.destination is the name of the topic to use -the the externall middleware). Normally the defaults will suffice.

To lean more about how to customize the message broker settings -consult the Spring Cloud Stream documentation.

Prev   Next
4. Service ID must be unique Home 6. Tracing Bus Events
\ No newline at end of file + 5. Customizing the Message Broker
5. Customizing the Message Broker
Prev   Next

5. Customizing the Message Broker

Spring Cloud Bus uses Spring Cloud Stream to +broadcast the messages. So, to get messages to flow, you need only include the binder +implementation of your choice in the classpath. There are convenient starters for the bus +with AMQP (RabbitMQ) and Kafka (spring-cloud-starter-bus-[amqp|kafka]). Generally +speaking, Spring Cloud Stream relies on Spring Boot autoconfiguration conventions for +configuring middleware. For instance, the AMQP broker address can be changed with +spring.rabbitmq.* configuration properties. Spring Cloud Bus has a handful of +native configuration properties in spring.cloud.bus.* (for example, +spring.cloud.bus.destination is the name of the topic to use as the external +middleware). Normally, the defaults suffice.

To learn more about how to customize the message broker settings, consult the Spring Cloud +Stream documentation.

Prev   Next
4. Service ID Must Be Unique Home 6. Tracing Bus Events
\ No newline at end of file diff --git a/multi/multi__quick_start.html b/multi/multi__quick_start.html index 4a64615..082fb34 100644 --- a/multi/multi__quick_start.html +++ b/multi/multi__quick_start.html @@ -1,10 +1,23 @@ - 1. Quick Start
1. Quick Start
Prev   Next

1. Quick Start

Spring Cloud Bus works by adding Spring Boot autconfiguration if it detects itself on the classpath. All you need to do to enable the bus is to add spring-cloud-starter-bus-amqp or spring-cloud-starter-bus-kafka to your dependency management and Spring Cloud takes care of the rest. Make sure the broker (RabbitMQ or Kafka) is available and configured: running on localhost you shouldn’t have to do anything, but if you are running remotely use Spring Cloud Connectors, or Spring Boot conventions to define the broker credentials, e.g. for Rabbit

application.yml.  + 1. Quick Start

1. Quick Start
Prev   Next

1. Quick Start

Spring Cloud Bus works by adding Spring Boot autconfiguration if it detects itself on the +classpath. To enable the bus, add spring-cloud-starter-bus-amqp or +spring-cloud-starter-bus-kafka to your dependency management. Spring Cloud takes care of +the rest. Make sure the broker (RabbitMQ or Kafka) is available and configured. When +running on localhost, you need not do anything. If you run remotely, use Spring Cloud +Connectors or Spring Boot conventions to define the broker credentials, as shown in the +following example for Rabbit:

application.yml.  

spring:
   rabbitmq:
     host: mybroker.com
     port: 5672
     username: user
     password: secret

-

The bus currently supports sending messages to all nodes listening or all nodes for a particular service (as defined by Eureka). More selector criteria may be added in the future (ie. only service X nodes in data center Y, etc…​). There are also some http endpoints under the /bus/* actuator namespace. There are currently two implemented. The first, /bus/env, sends key/value pairs to update each node’s Spring Environment. The second, /bus/refresh, will reload each application’s configuration, just as if they had all been pinged on their /refresh endpoint.

[Note]Note

The Bus starters cover Rabbit and Kafka, because those are the two most common implementations, but Spring Cloud Stream is quite flexible and binder will work combined with spring-cloud-bus.

Prev   Next
 Home 2. Addressing an Instance
\ No newline at end of file +

The bus currently supports sending messages to all nodes listening or all nodes for a +particular service (as defined by Eureka). The /bus/* actuator namespace has some HTTP +endpoints. Currently, two are implemented. The first, /bus/env, sends key/value pairs to +update each node’s Spring Environment. The second, /bus/refresh, reloads each +application’s configuration, as though they had all been pinged on their /refresh +endpoint.

[Note]Note

The Spring Cloud Bus starters cover Rabbit and Kafka, because those are the two most +common implementations. However, Spring Cloud Stream is quite flexible, and the binder +works with spring-cloud-bus.

Prev   Next
 Home 2. Addressing an Instance
\ No newline at end of file diff --git a/multi/multi__service_id_must_be_unique.html b/multi/multi__service_id_must_be_unique.html index 167ae27..f39aafd 100644 --- a/multi/multi__service_id_must_be_unique.html +++ b/multi/multi__service_id_must_be_unique.html @@ -1,3 +1,9 @@ - 4. Service ID must be unique
4. Service ID must be unique
Prev   Next

4. Service ID must be unique

The bus tries to eliminate processing an event twice, once from the original ApplicationEvent and once from the queue. To do this, it checks the sending service ID againts the current service ID. If multiple instances of a service have the same ID, events will not be processed. Running on a local machine, each service will be on a different port and that will be part of the ID. Cloud Foundry supplies an index to differentiate. To ensure that the ID is unique outside Cloud Foundry, set spring.application.index to something unique for each instance of a service.

Prev   Next
3. Addressing all instances of a service Home 5. Customizing the Message Broker
\ No newline at end of file + 4. Service ID Must Be Unique
4. Service ID Must Be Unique
Prev   Next

4. Service ID Must Be Unique

The bus tries twice to eliminate processing an event — once from the original +ApplicationEvent and once from the queue. To do so, it checks the sending service ID +against the current service ID. If multiple instances of a service have the same ID, +events are not processed. When running on a local machine, each service is on a different +port, and that port is part of the ID. Cloud Foundry supplies an index to differentiate. +To ensure that the ID is unique outside Cloud Foundry, set spring.application.index to +something unique for each instance of a service.

Prev   Next
3. Addressing All Instances of a Service Home 5. Customizing the Message Broker
\ No newline at end of file diff --git a/multi/multi__tracing_bus_events.html b/multi/multi__tracing_bus_events.html index 3416088..e5bf36c 100644 --- a/multi/multi__tracing_bus_events.html +++ b/multi/multi__tracing_bus_events.html @@ -1,10 +1,9 @@ - 6. Tracing Bus Events
6. Tracing Bus Events
Prev   Next

6. Tracing Bus Events

Bus events (subclasses of RemoteApplicationEvent) can be traced by -setting spring.cloud.bus.trace.enabled=true. If you do this then the -Spring Boot TraceRepository (if it is present) will show each event -sent and all the acks from each service instance. Example (from the -/trace endpoint):

{
+   6. Tracing Bus Events
6. Tracing Bus Events
Prev   Next
6. Tracing Bus Events
Bus events (subclasses of RemoteApplicationEvent) can be traced by setting
+spring.cloud.bus.trace.enabled=true. If you do so, the Spring Boot TraceRepository
+(if it is present) shows each event sent and all the acks from each service instance. The
+following example comes from the /trace endpoint:
{
   "timestamp": "2015-11-26T10:24:44.411+0000",
   "info": {
     "signal": "spring.cloud.bus.ack",
@@ -33,11 +32,11 @@ sent and all the acks from each service instance. Example (from the
     "origin": "customers:9000",
     "destination": "*:**"
   }
-}
This trace shows that a RefreshRemoteApplicationEvent was sent from
-customers:9000, broadcast to all services, and it was received
-(acked) by customers:9000 and stores:8081.
To handle the ack signals yourself you could add an @EventListener
-for the AckRemoteApplicationEvent and SentApplicationEvent types
-to your app (and enable tracing). Or you could tap into the
-TraceRepository and mine the data from there.
[Note]Note
Any Bus application can trace acks, but sometimes it will be
+}
The preceding trace shows that a RefreshRemoteApplicationEvent was sent from
+customers:9000, broadcast to all services, and received (acked) by customers:9000 and
+stores:8081.
To handle the ack signals yourself, you could add an @EventListener for the
+AckRemoteApplicationEvent and SentApplicationEvent types to your app (and enable
+tracing). Alternatively, you could tap into the TraceRepository and mine the data from
+there.
[Note]Note
Any Bus application can trace acks. However, sometimes, it is
 useful to do this in a central service that can do more complex
-queries on the data. Or forward it to a specialized tracing service.
Prev   Next
5. Customizing the Message Broker Home 7. Broadcasting Your Own Events

\ No newline at end of file
+queries on the data or forward it to a specialized tracing service.
Prev   Next
5. Customizing the Message Broker Home 7. Broadcasting Your Own Events

\ No newline at end of file
diff --git a/multi/multi_pr01.html b/multi/multi_pr01.html
index 69a2b2e..1e178ff 100644
--- a/multi/multi_pr01.html
+++ b/multi/multi_pr01.html
@@ -1,3 +1,8 @@
 
       
-   
Prev   Next
Spring Cloud Bus links nodes of a distributed system with a lightweight message broker. This can then be used to broadcast state changes (e.g. configuration changes) or other management instructions. A key idea is that the Bus is like a distributed Actuator for a Spring Boot application that is scaled out, but it can also be used as a communication channel between apps. Starters are provided for an AMQP broker as the transport or for Kafka, but the same basic feature set (and some more depending on the transport) is on the roadmap for other transports.
[Note]Note
Spring Cloud is released under the non-restrictive Apache 2.0 license. If you would like to contribute to this section of the documentation or if you find an error, please find the source code and issue trackers in the project at github.
Prev   Next
Spring Cloud Bus Home 1. Quick Start

\ No newline at end of file
+   
Prev   Next
Spring Cloud Bus links the nodes of a distributed system with a lightweight message
+broker. This broker can then be used to broadcast state changes (such as configuration
+changes) or other management instructions. A key idea is that the bus is like a
+distributed actuator for a Spring Boot application that is scaled out. However, it can
+also be used as a communication channel between apps. This project provides starters for
+either an AMQP broker or Kafka as the transport.
[Note]Note
Spring Cloud is released under the non-restrictive Apache 2.0 license. If you would like to contribute to this section of the documentation or if you find an error, please find the source code and issue trackers in the project at github.
Prev   Next
Spring Cloud Bus Home 1. Quick Start

\ No newline at end of file
diff --git a/multi/multi_spring-cloud-bus.html b/multi/multi_spring-cloud-bus.html
index 2af7334..feb7483 100644
--- a/multi/multi_spring-cloud-bus.html
+++ b/multi/multi_spring-cloud-bus.html
@@ -1,3 +1,3 @@
 
       
-   Spring Cloud Bus
Spring Cloud Bus
   Next
Spring Cloud Bus
Table of Contents
1. Quick Start
2. Addressing an Instance
3. Addressing all instances of a service
4. Service ID must be unique
5. Customizing the Message Broker
6. Tracing Bus Events
7. Broadcasting Your Own Events
7.1. Registering events in custom packages
   Next
   

\ No newline at end of file
+   Spring Cloud Bus
Spring Cloud Bus
   Next
Spring Cloud Bus
Table of Contents
1. Quick Start
2. Addressing an Instance
3. Addressing All Instances of a Service
4. Service ID Must Be Unique
5. Customizing the Message Broker
6. Tracing Bus Events
7. Broadcasting Your Own Events
7.1. Registering events in custom packages
   Next
   

\ No newline at end of file
diff --git a/single/spring-cloud-bus.html b/single/spring-cloud-bus.html
index a5b1507..bc9e572 100644
--- a/single/spring-cloud-bus.html
+++ b/single/spring-cloud-bus.html
@@ -1,31 +1,62 @@
 
       
-   Spring Cloud Bus
Spring Cloud Bus
Table of Contents
1. Quick Start
2. Addressing an Instance
3. Addressing all instances of a service
4. Service ID must be unique
5. Customizing the Message Broker
6. Tracing Bus Events
7. Broadcasting Your Own Events
7.1. Registering events in custom packages
Spring Cloud Bus links nodes of a distributed system with a lightweight message broker. This can then be used to broadcast state changes (e.g. configuration changes) or other management instructions. A key idea is that the Bus is like a distributed Actuator for a Spring Boot application that is scaled out, but it can also be used as a communication channel between apps. Starters are provided for an AMQP broker as the transport or for Kafka, but the same basic feature set (and some more depending on the transport) is on the roadmap for other transports.
[Note]Note
Spring Cloud is released under the non-restrictive Apache 2.0 license. If you would like to contribute to this section of the documentation or if you find an error, please find the source code and issue trackers in the project at github.
1. Quick Start
Spring Cloud Bus works by adding Spring Boot autconfiguration if it detects itself on the classpath. All you need to do to enable the bus is to add spring-cloud-starter-bus-amqp or spring-cloud-starter-bus-kafka to your dependency management and Spring Cloud takes care of the rest. Make sure the broker (RabbitMQ or Kafka) is available and configured: running on localhost you shouldn’t have to do anything, but if you are running remotely use Spring Cloud Connectors, or Spring Boot conventions to define the broker credentials, e.g. for Rabbit
application.yml. 
+   Spring Cloud Bus
Spring Cloud Bus
Table of Contents
1. Quick Start
2. Addressing an Instance
3. Addressing All Instances of a Service
4. Service ID Must Be Unique
5. Customizing the Message Broker
6. Tracing Bus Events
7. Broadcasting Your Own Events
7.1. Registering events in custom packages
Spring Cloud Bus links the nodes of a distributed system with a lightweight message
+broker. This broker can then be used to broadcast state changes (such as configuration
+changes) or other management instructions. A key idea is that the bus is like a
+distributed actuator for a Spring Boot application that is scaled out. However, it can
+also be used as a communication channel between apps. This project provides starters for
+either an AMQP broker or Kafka as the transport.
[Note]Note
Spring Cloud is released under the non-restrictive Apache 2.0 license. If you would like to contribute to this section of the documentation or if you find an error, please find the source code and issue trackers in the project at github.
1. Quick Start
Spring Cloud Bus works by adding Spring Boot autconfiguration if it detects itself on the
+classpath. To enable the bus, add spring-cloud-starter-bus-amqp or
+spring-cloud-starter-bus-kafka to your dependency management. Spring Cloud takes care of
+the rest. Make sure the broker (RabbitMQ or Kafka) is available and configured. When
+running on localhost, you need not do anything. If you run remotely, use Spring Cloud
+Connectors or Spring Boot conventions to define the broker credentials, as shown in the
+following example for Rabbit:
application.yml. 
 
spring:
   rabbitmq:
     host: mybroker.com
     port: 5672
     username: user
     password: secret

-
The bus currently supports sending messages to all nodes listening or all nodes for a particular service (as defined by Eureka).  More selector criteria may be added in the future (ie. only service X nodes in data center Y, etc…​). There are also some http endpoints under the /bus/* actuator namespace.  There are currently two implemented.  The first, /bus/env, sends key/value pairs to update each node’s Spring Environment.  The second, /bus/refresh, will reload each application’s configuration, just as if they had all been pinged on their /refresh endpoint.
[Note]Note
The Bus starters cover Rabbit and Kafka, because those are the two most common implementations, but Spring Cloud Stream is quite flexible and binder will work combined with spring-cloud-bus.
2. Addressing an Instance
Each instance of the application has a service ID, whose value can be set using spring.cloud.bus.id, and whose value is expected to be a colon-separated list of identifiers, in order of least specific to most specific. The default value is constructed from the environment as a combination of the spring.application.name and server.port (or spring.application.index if set). The default value of the ID is constructed in the form app:index:id where:
  • app is the vcap.application.name if it exists, or spring.application.name
  • index is the vcap.application.instance_index if it exists, or else spring.application.index, or else local.server.port (or server.port or 0).
  • id is the vcap.application.instance_id if it exists, or else a random value.
The HTTP endpoints accept a "destination" parameter, e.g. "/bus/refresh?destination=customers:9000", where the destination is a service ID. If the ID is owned by an instance on the Bus then it will process the message and all other instances will ignore it.
3. Addressing all instances of a service
The "destination" parameter is used in a Spring PathMatcher (with the path separator as a colon :) to determine if an instance will process the message.   Using the example from above, "/bus/refresh?destination=customers:**" will  target  all instances of the "customers" service regardless of the rest of the service ID.
4. Service ID must be unique
The bus tries to eliminate processing an event twice, once from the original ApplicationEvent and once from the queue.  To do this, it checks the sending service ID againts the current service ID.  If multiple instances of a service have the same ID, events will not be processed.  Running on a local machine, each service will be on a different port and that will be part of the ID.  Cloud Foundry supplies an index to differentiate.  To ensure that the ID is unique outside Cloud Foundry, set spring.application.index to something unique for each instance of a service.
5. Customizing the Message Broker
Spring Cloud Bus uses
-Spring Cloud Stream to
-broadcast the messages so to get messages to flow you only need to
-include the binder implementation of your choice in the
-classpath. There are convenient starters specifically for the bus with
-AMQP (RabbitMQ) and Kafka
-(spring-cloud-starter-bus-[amqp,kafka]). Generally speaking
-Spring Cloud Stream relies on Spring Boot autoconfiguration
-conventions for configuring middleware, so for instance the AMQP
-broker address can be changed with spring.rabbitmq.*
-configuration properties. Spring Cloud Bus has a handful of native
-configuration properties in spring.cloud.bus.*
-(e.g. spring.cloud.bus.destination is the name of the topic to use
-the the externall middleware). Normally the defaults will suffice.
To lean more about how to customize the message broker settings
-consult the Spring Cloud Stream documentation.
6. Tracing Bus Events
Bus events (subclasses of RemoteApplicationEvent) can be traced by
-setting spring.cloud.bus.trace.enabled=true. If you do this then the
-Spring Boot TraceRepository (if it is present) will show each event
-sent and all the acks from each service instance. Example (from the
-/trace endpoint):
{
+
The bus currently supports sending messages to all nodes listening or all nodes for a
+particular service (as defined by Eureka). The /bus/* actuator namespace has some HTTP
+endpoints. Currently, two are implemented. The first, /bus/env, sends key/value pairs to
+update each node’s Spring Environment. The second, /bus/refresh, reloads each
+application’s configuration, as though they had all been pinged on their /refresh
+endpoint.
[Note]Note
The Spring Cloud Bus starters cover Rabbit and Kafka, because those are the two most
+common implementations. However, Spring Cloud Stream is quite flexible, and the binder
+works with spring-cloud-bus.
2. Addressing an Instance
Each instance of the application has a service ID, whose value can be set with
+spring.cloud.bus.id and whose value is expected to be a colon-separated list of
+identifiers, in order from least specific to most specific. The default value is
+constructed from the environment as a combination of the spring.application.name and
+server.port (or spring.application.index, if set). The default value of the ID is
+constructed in the form of app:index:id, where:
  • app is the vcap.application.name, if it exists, or spring.application.name
  • index is the vcap.application.instance_index, if it exists,
+spring.application.index, local.server.port, server.port, or 0 (in that order).
  • id is the vcap.application.instance_id, if it exists, or a random value.
The HTTP endpoints accept a “destination” parameter, such as
+/bus/refresh?destination=customers:9000, where destination is a service ID. If the ID
+is owned by an instance on the bus, it processes the message, and all other instances
+ignore it.
3. Addressing All Instances of a Service
The “destination” parameter is used in a Spring PathMatcher (with the path separator
+as a colon — :) to determine if an instance processes the message. Using the example
+from earlier, /bus/refresh?destination=customers:** targets all instances of the
+“customers” service regardless of the rest of the service ID.
4. Service ID Must Be Unique
The bus tries twice to eliminate processing an event — once from the original
+ApplicationEvent and once from the queue. To do so, it checks the sending service ID
+against the current service ID. If multiple instances of a service have the same ID,
+events are not processed. When running on a local machine, each service is on a different
+port, and that port is part of the ID. Cloud Foundry supplies an index to differentiate.
+To ensure that the ID is unique outside Cloud Foundry, set spring.application.index to
+something unique for each instance of a service.
5. Customizing the Message Broker
Spring Cloud Bus uses Spring Cloud Stream to
+broadcast the messages. So, to get messages to flow, you need only include the binder
+implementation of your choice in the classpath. There are convenient starters for the bus
+with AMQP (RabbitMQ) and Kafka (spring-cloud-starter-bus-[amqp|kafka]). Generally
+speaking, Spring Cloud Stream relies on Spring Boot autoconfiguration conventions for
+configuring middleware. For instance, the AMQP broker address can be changed with
+spring.rabbitmq.* configuration properties. Spring Cloud Bus has a handful of
+native configuration properties in spring.cloud.bus.* (for example,
+spring.cloud.bus.destination is the name of the topic to use as the external
+middleware). Normally, the defaults suffice.
To learn more about how to customize the message broker settings, consult the Spring Cloud
+Stream documentation.
6. Tracing Bus Events
Bus events (subclasses of RemoteApplicationEvent) can be traced by setting
+spring.cloud.bus.trace.enabled=true. If you do so, the Spring Boot TraceRepository
+(if it is present) shows each event sent and all the acks from each service instance. The
+following example comes from the /trace endpoint:
{
   "timestamp": "2015-11-26T10:24:44.411+0000",
   "info": {
     "signal": "spring.cloud.bus.ack",
@@ -54,36 +85,35 @@ sent and all the acks from each service instance. Example (from the
     "origin": "customers:9000",
     "destination": "*:**"
   }
-}
This trace shows that a RefreshRemoteApplicationEvent was sent from
-customers:9000, broadcast to all services, and it was received
-(acked) by customers:9000 and stores:8081.
To handle the ack signals yourself you could add an @EventListener
-for the AckRemoteApplicationEvent and SentApplicationEvent types
-to your app (and enable tracing). Or you could tap into the
-TraceRepository and mine the data from there.
[Note]Note
Any Bus application can trace acks, but sometimes it will be
+}
The preceding trace shows that a RefreshRemoteApplicationEvent was sent from
+customers:9000, broadcast to all services, and received (acked) by customers:9000 and
+stores:8081.
To handle the ack signals yourself, you could add an @EventListener for the
+AckRemoteApplicationEvent and SentApplicationEvent types to your app (and enable
+tracing). Alternatively, you could tap into the TraceRepository and mine the data from
+there.
[Note]Note
Any Bus application can trace acks. However, sometimes, it is
 useful to do this in a central service that can do more complex
-queries on the data. Or forward it to a specialized tracing service.
7. Broadcasting Your Own Events
The Bus can carry any event of type RemoteApplicationEvent, but the
-default transport is JSON and the deserializer needs to know which
-types are going to be used ahead of time. To register a new type it
-needs to be in a subpackage of org.springframework.cloud.bus.event.
To customise the event name you can use @JsonTypeName on your custom class
-or rely on the default strategy which is to use the simple name of the class.
-Note that both the producer and the consumer will need access to the class
-definition.
7.1 Registering events in custom packages
If you cannot or don’t want to use a subpackage of org.springframework.cloud.bus.event
-for your custom events, you must specify which packages to scan for events of
-type RemoteApplicationEvent using @RemoteApplicationEventScan. Packages
-specified with @RemoteApplicationEventScan include subpackages.
For example, if you have a custom event called FooEvent:
package com.acme;
+queries on the data or forward it to a specialized tracing service.
7. Broadcasting Your Own Events
The Bus can carry any event of type RemoteApplicationEvent. The default transport is
+JSON, and the deserializer needs to know which types are going to be used ahead of time.
+To register a new type, you must put it in a subpackage of
+org.springframework.cloud.bus.event.
To customise the event name, you can use @JsonTypeName on your custom class or rely on
+the default strategy, which is to use the simple name of the class.
[Note]Note
Both the producer and the consumer need access to the class definition.
7.1 Registering events in custom packages
If you cannot or do not want to use a subpackage of org.springframework.cloud.bus.event
+for your custom events, you must specify which packages to scan for events of type
+RemoteApplicationEvent by using the @RemoteApplicationEventScan annotation. Packages
+specified with @RemoteApplicationEventScan include subpackages.
For example, consider the following custom event, called MyEvent:
package com.acme;
 
-public class FooEvent extends RemoteApplicationEvent {
+public class MyEvent extends RemoteApplicationEvent {
     ...
-}
you can register this event with the deserializer in the following way:
package com.acme;
+}
You can register that event with the deserializer in the following way:
package com.acme;
 
 @Configuration
 @RemoteApplicationEventScan
 public class BusConfiguration {
     ...
 }
Without specifying a value, the package of the class where @RemoteApplicationEventScan
-is used will be registered. In this example com.acme will be registered using the
-package of BusConfiguration.
You can also explicitly specify the packages to scan using the value, basePackages or
-basePackageClasses properties on @RemoteApplicationEventScan. For example:
package com.acme;
+is used is registered. In this example, com.acme is registered by using the package of
+BusConfiguration.
You can also explicitly specify the packages to scan by using the value, basePackages
+or basePackageClasses properties on @RemoteApplicationEventScan, as shown in the
+following example:
package com.acme;
 
 @Configuration
 //@RemoteApplicationEventScan({"com.acme", "foo.bar"})
@@ -91,7 +121,6 @@ package of BusConfiguration.
You can also exp
 @RemoteApplicationEventScan(basePackageClasses = BusConfiguration.class)
 public class BusConfiguration {
     ...
-}
All examples of @RemoteApplicationEventScan above are equivalent,
-in that the com.acme package will be registered by explicitly specifying the
-packages on @RemoteApplicationEventScan. Note, you can specify multiple base
-packages to scan.

\ No newline at end of file
+}

All of the preceding examples of @RemoteApplicationEventScan are equivalent, in that the +com.acme package is registered by explicitly specifying the packages on +@RemoteApplicationEventScan.

[Note]Note

You can specify multiple base packages to scan.

\ No newline at end of file diff --git a/spring-cloud-bus.xml b/spring-cloud-bus.xml index f5aebe2..9a5e7a5 100644 --- a/spring-cloud-bus.xml +++ b/spring-cloud-bus.xml @@ -8,14 +8,25 @@ -Spring Cloud Bus links nodes of a distributed system with a lightweight message broker. This can then be used to broadcast state changes (e.g. configuration changes) or other management instructions. A key idea is that the Bus is like a distributed Actuator for a Spring Boot application that is scaled out, but it can also be used as a communication channel between apps. Starters are provided for an AMQP broker as the transport or for Kafka, but the same basic feature set (and some more depending on the transport) is on the roadmap for other transports. +Spring Cloud Bus links the nodes of a distributed system with a lightweight message +broker. This broker can then be used to broadcast state changes (such as configuration +changes) or other management instructions. A key idea is that the bus is like a +distributed actuator for a Spring Boot application that is scaled out. However, it can +also be used as a communication channel between apps. This project provides starters for +either an AMQP broker or Kafka as the transport. Spring Cloud is released under the non-restrictive Apache 2.0 license. If you would like to contribute to this section of the documentation or if you find an error, please find the source code and issue trackers in the project at github. Quick Start -Spring Cloud Bus works by adding Spring Boot autconfiguration if it detects itself on the classpath. All you need to do to enable the bus is to add spring-cloud-starter-bus-amqp or spring-cloud-starter-bus-kafka to your dependency management and Spring Cloud takes care of the rest. Make sure the broker (RabbitMQ or Kafka) is available and configured: running on localhost you shouldn’t have to do anything, but if you are running remotely use Spring Cloud Connectors, or Spring Boot conventions to define the broker credentials, e.g. for Rabbit +Spring Cloud Bus works by adding Spring Boot autconfiguration if it detects itself on the +classpath. To enable the bus, add spring-cloud-starter-bus-amqp or +spring-cloud-starter-bus-kafka to your dependency management. Spring Cloud takes care of +the rest. Make sure the broker (RabbitMQ or Kafka) is available and configured. When +running on localhost, you need not do anything. If you run remotely, use Spring Cloud +Connectors or Spring Boot conventions to define the broker credentials, as shown in the +following example for Rabbit: application.yml @@ -27,61 +38,81 @@ password: secret -The bus currently supports sending messages to all nodes listening or all nodes for a particular service (as defined by Eureka). More selector criteria may be added in the future (ie. only service X nodes in data center Y, etc…​). There are also some http endpoints under the /bus/* actuator namespace. There are currently two implemented. The first, /bus/env, sends key/value pairs to update each node’s Spring Environment. The second, /bus/refresh, will reload each application’s configuration, just as if they had all been pinged on their /refresh endpoint. +The bus currently supports sending messages to all nodes listening or all nodes for a +particular service (as defined by Eureka). The /bus/* actuator namespace has some HTTP +endpoints. Currently, two are implemented. The first, /bus/env, sends key/value pairs to +update each node’s Spring Environment. The second, /bus/refresh, reloads each +application’s configuration, as though they had all been pinged on their /refresh +endpoint. -The Bus starters cover Rabbit and Kafka, because those are the two most common implementations, but Spring Cloud Stream is quite flexible and binder will work combined with spring-cloud-bus. +The Spring Cloud Bus starters cover Rabbit and Kafka, because those are the two most +common implementations. However, Spring Cloud Stream is quite flexible, and the binder +works with spring-cloud-bus. Addressing an Instance -Each instance of the application has a service ID, whose value can be set using spring.cloud.bus.id, and whose value is expected to be a colon-separated list of identifiers, in order of least specific to most specific. The default value is constructed from the environment as a combination of the spring.application.name and server.port (or spring.application.index if set). The default value of the ID is constructed in the form app:index:id where: +Each instance of the application has a service ID, whose value can be set with +spring.cloud.bus.id and whose value is expected to be a colon-separated list of +identifiers, in order from least specific to most specific. The default value is +constructed from the environment as a combination of the spring.application.name and +server.port (or spring.application.index, if set). The default value of the ID is +constructed in the form of app:index:id, where: -app is the vcap.application.name if it exists, or spring.application.name +app is the vcap.application.name, if it exists, or spring.application.name -index is the vcap.application.instance_index if it exists, or else spring.application.index, or else local.server.port (or server.port or 0). +index is the vcap.application.instance_index, if it exists, +spring.application.index, local.server.port, server.port, or 0 (in that order). -id is the vcap.application.instance_id if it exists, or else a random value. +id is the vcap.application.instance_id, if it exists, or a random value. -The HTTP endpoints accept a "destination" parameter, e.g. "/bus/refresh?destination=customers:9000", where the destination is a service ID. If the ID is owned by an instance on the Bus then it will process the message and all other instances will ignore it. +The HTTP endpoints accept a “destination” parameter, such as +/bus/refresh?destination=customers:9000, where destination is a service ID. If the ID +is owned by an instance on the bus, it processes the message, and all other instances +ignore it. -Addressing all instances of a service -The "destination" parameter is used in a Spring PathMatcher (with the path separator as a colon :) to determine if an instance will process the message. Using the example from above, "/bus/refresh?destination=customers:**" will target all instances of the "customers" service regardless of the rest of the service ID. +Addressing All Instances of a Service +The “destination” parameter is used in a Spring PathMatcher (with the path separator +as a colon — :) to determine if an instance processes the message. Using the example +from earlier, /bus/refresh?destination=customers:** targets all instances of the +“customers” service regardless of the rest of the service ID. -Service ID must be unique -The bus tries to eliminate processing an event twice, once from the original ApplicationEvent and once from the queue. To do this, it checks the sending service ID againts the current service ID. If multiple instances of a service have the same ID, events will not be processed. Running on a local machine, each service will be on a different port and that will be part of the ID. Cloud Foundry supplies an index to differentiate. To ensure that the ID is unique outside Cloud Foundry, set spring.application.index to something unique for each instance of a service. +Service ID Must Be Unique +The bus tries twice to eliminate processing an event — once from the original +ApplicationEvent and once from the queue. To do so, it checks the sending service ID +against the current service ID. If multiple instances of a service have the same ID, +events are not processed. When running on a local machine, each service is on a different +port, and that port is part of the ID. Cloud Foundry supplies an index to differentiate. +To ensure that the ID is unique outside Cloud Foundry, set spring.application.index to +something unique for each instance of a service. Customizing the Message Broker -Spring Cloud Bus uses -Spring Cloud Stream to -broadcast the messages so to get messages to flow you only need to -include the binder implementation of your choice in the -classpath. There are convenient starters specifically for the bus with -AMQP (RabbitMQ) and Kafka -(spring-cloud-starter-bus-[amqp,kafka]). Generally speaking -Spring Cloud Stream relies on Spring Boot autoconfiguration -conventions for configuring middleware, so for instance the AMQP -broker address can be changed with spring.rabbitmq.* -configuration properties. Spring Cloud Bus has a handful of native -configuration properties in spring.cloud.bus.* -(e.g. spring.cloud.bus.destination is the name of the topic to use -the the externall middleware). Normally the defaults will suffice. -To lean more about how to customize the message broker settings -consult the Spring Cloud Stream documentation. +Spring Cloud Bus uses Spring Cloud Stream to +broadcast the messages. So, to get messages to flow, you need only include the binder +implementation of your choice in the classpath. There are convenient starters for the bus +with AMQP (RabbitMQ) and Kafka (spring-cloud-starter-bus-[amqp|kafka]). Generally +speaking, Spring Cloud Stream relies on Spring Boot autoconfiguration conventions for +configuring middleware. For instance, the AMQP broker address can be changed with +spring.rabbitmq.* configuration properties. Spring Cloud Bus has a handful of +native configuration properties in spring.cloud.bus.* (for example, +spring.cloud.bus.destination is the name of the topic to use as the external +middleware). Normally, the defaults suffice. +To learn more about how to customize the message broker settings, consult the Spring Cloud +Stream documentation. Tracing Bus Events -Bus events (subclasses of RemoteApplicationEvent) can be traced by -setting spring.cloud.bus.trace.enabled=true. If you do this then the -Spring Boot TraceRepository (if it is present) will show each event -sent and all the acks from each service instance. Example (from the -/trace endpoint): +Bus events (subclasses of RemoteApplicationEvent) can be traced by setting +spring.cloud.bus.trace.enabled=true. If you do so, the Spring Boot TraceRepository +(if it is present) shows each event sent and all the acks from each service instance. The +following example comes from the /trace endpoint: { "timestamp": "2015-11-26T10:24:44.411+0000", "info": { @@ -112,42 +143,43 @@ sent and all the acks from each service instance. Example (from the "destination": "*:**" } } -This trace shows that a RefreshRemoteApplicationEvent was sent from -customers:9000, broadcast to all services, and it was received -(acked) by customers:9000 and stores:8081. -To handle the ack signals yourself you could add an @EventListener -for the AckRemoteApplicationEvent and SentApplicationEvent types -to your app (and enable tracing). Or you could tap into the -TraceRepository and mine the data from there. +The preceding trace shows that a RefreshRemoteApplicationEvent was sent from +customers:9000, broadcast to all services, and received (acked) by customers:9000 and +stores:8081. +To handle the ack signals yourself, you could add an @EventListener for the +AckRemoteApplicationEvent and SentApplicationEvent types to your app (and enable +tracing). Alternatively, you could tap into the TraceRepository and mine the data from +there. -Any Bus application can trace acks, but sometimes it will be +Any Bus application can trace acks. However, sometimes, it is useful to do this in a central service that can do more complex -queries on the data. Or forward it to a specialized tracing service. +queries on the data or forward it to a specialized tracing service. Broadcasting Your Own Events -The Bus can carry any event of type RemoteApplicationEvent, but the -default transport is JSON and the deserializer needs to know which -types are going to be used ahead of time. To register a new type it -needs to be in a subpackage of org.springframework.cloud.bus.event. -To customise the event name you can use @JsonTypeName on your custom class -or rely on the default strategy which is to use the simple name of the class. -Note that both the producer and the consumer will need access to the class -definition. +The Bus can carry any event of type RemoteApplicationEvent. The default transport is +JSON, and the deserializer needs to know which types are going to be used ahead of time. +To register a new type, you must put it in a subpackage of +org.springframework.cloud.bus.event. +To customise the event name, you can use @JsonTypeName on your custom class or rely on +the default strategy, which is to use the simple name of the class. + +Both the producer and the consumer need access to the class definition. +
Registering events in custom packages -If you cannot or don’t want to use a subpackage of org.springframework.cloud.bus.event -for your custom events, you must specify which packages to scan for events of -type RemoteApplicationEvent using @RemoteApplicationEventScan. Packages +If you cannot or do not want to use a subpackage of org.springframework.cloud.bus.event +for your custom events, you must specify which packages to scan for events of type +RemoteApplicationEvent by using the @RemoteApplicationEventScan annotation. Packages specified with @RemoteApplicationEventScan include subpackages. -For example, if you have a custom event called FooEvent: +For example, consider the following custom event, called MyEvent: package com.acme; -public class FooEvent extends RemoteApplicationEvent { +public class MyEvent extends RemoteApplicationEvent { ... } -you can register this event with the deserializer in the following way: +You can register that event with the deserializer in the following way: package com.acme; @Configuration @@ -156,10 +188,11 @@ public class BusConfiguration { ... } Without specifying a value, the package of the class where @RemoteApplicationEventScan -is used will be registered. In this example com.acme will be registered using the -package of BusConfiguration. -You can also explicitly specify the packages to scan using the value, basePackages or -basePackageClasses properties on @RemoteApplicationEventScan. For example: +is used is registered. In this example, com.acme is registered by using the package of +BusConfiguration. +You can also explicitly specify the packages to scan by using the value, basePackages +or basePackageClasses properties on @RemoteApplicationEventScan, as shown in the +following example: package com.acme; @Configuration @@ -169,10 +202,12 @@ package of BusConfiguration. public class BusConfiguration { ... } -All examples of @RemoteApplicationEventScan above are equivalent, -in that the com.acme package will be registered by explicitly specifying the -packages on @RemoteApplicationEventScan. Note, you can specify multiple base -packages to scan. +All of the preceding examples of @RemoteApplicationEventScan are equivalent, in that the +com.acme package is registered by explicitly specifying the packages on +@RemoteApplicationEventScan. + +You can specify multiple base packages to scan. +
\ No newline at end of file