Chapter 9. Changes in clustering
Chapter 9. Changes in clustering This section explains the changes in clustering. 9.1. Clustered flag removed from options classes The methods and boolean value that were used to specify, get, and set clustering in Eclipse Vert.x applications have been removed from VertxOptions and EventBusOptions classes. 9.2. Changes in Infinispan cluster manager The following section describes the changes in the Infinispan cluster manager. 9.2.1. Updates in custom configurations The Infinispan cluster manager is based on Infinispan 12. In Eclipse Vert.x 4, the clustering SPI has been redesigned. The subscription data model has changed. As a result of this, Eclipse Vert.x 3.x nodes and Eclipse Vert.x 4 nodes cannot be added together in the same Infinispan cluster. The Eclipse Vert.x applications are not impacted by this change as the EventBus and SharedData APIs remain the same. If you had a custom Infinispan configuration file in your Eclipse Vert.x 3.x application: Change the __vertx.subs cache type to replicated instead of distributed. Add the replicated cache __vertx.nodeInfo . If you run an Eclipse Vert.x cluster on Openshift, the infinispan-cloud JAR is no longer needed. The JAR has been removed from the dependencies section of the build file. The configuration files that were bundled in this JAR are now included in the infinispan-core JAR. 9.3. Migrating clusters It is important to decide the migration strategy for your codebase. This is because you cannot add Eclipse Vert.x 3.x nodes and Eclipse Vert.x 4 nodes together in a single cluster for the following reasons: Cluster manager upgrades - Major version upgrades in cluster managers prevent backward compatibility. Subscription data changes - Eclipse Vert.x has changed the format of the EventBus subscription data stored in cluster managers. Transport protocol changes - Eclipse Vert.x has changed some fields in the message transport protocol in the cluster. If you have an Eclipse Vert.x cluster for a single application or for some closely related microservices, you can migrate the entire codebase to the new cluster at one time. However, if you cannot migrate the codebase at one time, use the recommendations in this section to migrate an Eclipse Vert.x 3.x codebase to Eclipse Vert.x 4. 9.3.1. Splitting the cluster If you have a cluster where different teams have deployed verticles for their applications, you can consider splitting the Eclipse Vert.x 3.x cluster into smaller ones. Note that after splitting the cluster, the separated components will not be able to communicate using the clustering features. You can split the cluster using the following components: EventBus request and reply - HTTP or RESTful web services, gRPC EventBus send and publish - Messaging systems, Postgres LISTEN and NOTIFY , Redis Pub and Sub Shared Data - Redis, Infinispan After you split the cluster, each team can move to Eclipse Vert.x 4 when they are ready or if required. 9.3.2. Using Eclipse Vert.x EventBus Link If you cannot split your cluster, then use Vert.x EventBus Link to migrate your codebase incrementally. Vert.x EventBus Link is a tool that connects an Eclipse Vert.x 3.x clustered EventBus to an Eclipse Vert.x 4 clustered EventBus. Warning The migration of shared data API, that is, maps, counters and locks is not supported. The tool creates an EventBusLink object that implements the EventBus interface. An instance of EventBusLink is created on at least one node of each cluster. The instance is created by providing a set of addresses and its behavior depends on the message paradigm: fire and forget and request and reply - The message is sent to the remote cluster. publish - The message is sent to both this cluster and the remote cluster. The Eclipse Vert.x EventBus Link creates a WebSocket server to receive messages and uses a WebSocket client to send them. See the sections get started and using for more details.
<cache-container default-cache="distributed-cache"> <distributed-cache name="distributed-cache"/> <replicated-cache name="__vertx.subs"/> <replicated-cache name="__vertx.haInfo"/> <replicated-cache name="__vertx.nodeInfo"/> <distributed-cache-configuration name="__vertx.distributed.cache.configuration"/> </cache-container>