Starting the Diffusion server
After you have installed and configured your Diffusion™ server, you can start it using one of a number of methods.
Use the provided Diffusion start scripts
Your Diffusion installation includes The diffusion.sh or diffusion.bat command (issued in the bin directory) starts Diffusion . An optional properties directory can be specified as a parameter to be used instead of the default ../etc directory.
Use a script in init.d
On Linux , Diffusion can be started using a script in your /etc/init.d folder that starts your Diffusion server when the host server starts.
If you installed your Diffusion server using RPM, this script already exists in your /etc/init.d folder.
If you installed your Diffusion using another method, you can use the sample script files in the tools/init.d directory of your Diffusion . Edit the sample script file to include the location of your installation and make any other changes that are required. Copy the edited script file to /etc/init.d. Ensure that the file is executable.
When your host server starts, it starts your Diffusion server.
Use Docker®
Diffusion is provided as a Docker image on DockerHub. When you use Docker to run this image, the Diffusion server inside the image is started.
For more information, see Installing the Diffusion server using Docker.
Run embedded in a Java™ process
You can run the Diffusion server from within a Java process by including the diffusion.jar on the classpath of the Java process.
For more information, see Running from within a Java application.
Starting and Closing Servers in a Cluster
When Diffusion replication is in use, there will be several servers in a single cluster of servers. It is recommended that a cluster has at least 3 members.
Adding additional members will not significantly decrease memory utilization on each server (as the topic tree is replicated on each member), however the Hazelcast logging overhead will decrease as more members are added. Additional members are usually added to scale to larger numbers of client connections.
Starting and Closing Cluster Members
- Always keep at least one server in the cluster running, making sure you don't lose any hazelcast data. (For example, shutdown servers one at a time, waiting for hazelcast to report partition stability). Doing this will ensure that new servers joining the cluster will receive populated partitions from the existing servers and discard topics that only exist in their local persistence file.
- When starting a cluster from nothing, start one server and let it fully recover from its persistence file, before starting another. This is a special case of the first strategy.
- To do a controlled restart of a cluster, shut down the servers one by one, and then start the last server to shut down before starting the rest.