2015-10-31 01:22:58 +08:00
|
|
|
@echo off
|
|
|
|
|
|
|
|
|
|
REM Scopes the variables to the current batch file
|
|
|
|
|
REM setlocal
|
|
|
|
|
|
|
|
|
|
rem Preserve values that might contain exclamation marks before
|
|
|
|
|
rem enabling delayed expansion
|
|
|
|
|
set TDP0=%~dp0
|
|
|
|
|
REM setlocal enabledelayedexpansion
|
|
|
|
|
|
|
|
|
|
REM SCRIPT_DIR=`dirname $SCRIPT_PATH`
|
|
|
|
|
REM RABBITMQ_HOME="${SCRIPT_DIR}/.."
|
|
|
|
|
set SCRIPT_DIR=%TDP0%
|
|
|
|
|
set SCRIPT_NAME=%1
|
2019-08-06 23:29:23 +08:00
|
|
|
for /f "delims=" %%F in ("%SCRIPT_DIR%..") do set RABBITMQ_HOME=%%~dpF%%~nF%%~xF
|
2015-10-31 01:22:58 +08:00
|
|
|
|
Move most of shell scripts to Erlang code
A large part of the rabbitmq-server(8) and CLI scripts, both
Bourne-shell and Windows Batch versions, was moved to Erlang code and
the RabbitMQ startup procedure was reorganized to be closer to a regular
Erlang application.
A new application called `rabbitmq_prelaunch` is responsible for:
1. Querying the environment variables to initialize important
variables (using the new `rabbit_env` module in rabbitmq-common).
2. Checking the compatibility with the Erlang/OTP runtime.
3. Configuring Erlang distribution.
5. Writing the PID file.
The application is started early (i.e. it is started before `rabbit`).
The `rabbit` application runs the second half of the prelaunch sequence
at the beginning of the application `start()` function. This second
phase is responsible for the following steps:
1. Preparing the feature flags registry.
2. Reading and validating the configuration.
3. Configuring logging.
4. Running the various cluster checks.
In addition to this prelaunch sequence, the `rabbit` application start
procedure ends with a "postlaunch" sequence which takes care of
starting enabled plugins.
Thanks to this, RabbitMQ can be started with `application:start(rabbit)`
as any other Erlang application. The only caveats are:
* Mnesia must be stopped at the time `rabbit_prelaunch` is started,
and must remain stopped when `rabbit` is started, to allow the
Erlang distribution setup and cluster checks. `rabbit` takes care of
starting Mnesia.
* Likewise for Ra, because it relies on the `ra` application
environment to be configured.
Transitioning from scripts to Erlang code has the following benefits:
* RabbitMQ start behavior should be identical between Unix and
Windows. Also, features should be on par now. For instance, RabbitMQ
now writes a PID file on Windows, like it always did on Unix-based
systems.
* The difference between published packages and a development
environment are greatly reduced. In fact, we removed all the "if
this is a dev working copy, then ..." blocks.
As part of that, the `rabbit` application is now treated like its
plugins: it is packaged as an `.ez` archive and written to the
`plugins` directory (even though it is not technically a plugin).
Also in a development copy, the CLI is copied to the top-level
project. So when testing a plugin for instance, the CLI to use is
`sbin/rabbitmqctl` in the current directory, not the master copy in
`rabbit/scripts`.
* As a consequence of the previous two points, maintaining and testing
on Windows is now made easy. It should even be possible to setup CI
on Windows.
* There are less issues with paths containing non-US-ASCII characters,
which can happen on Windows because RabbitMQ stores its data in user
directories by default.
This process brings at least one more benefit: we now have early logging
during this prelaunch phase, which eases diagnostics and debugging.
There are also behavior changes:
* The new format configuration files used to be converted to an
Erlang-term-based file by the Cuttlefish CLI. To do that,
configuration schemas were copied to a temporary directory and the
generated configuration file was written to RabbitMQ data directory.
Now, Cuttlefish is used as a library: everything happens in memory.
No schemas are copied, no generated configuration is written to
disk.
* The PID file is removed when the Erlang VM exits.
* The `rabbit_config` module was trimmed significantly because most of
the configuration handling is done in `rabbit_prelaunch_conf` now.
* The RabbitMQ nodename does not appear on the command line, therefore
it is missing from ps(1) and top(1) output.
* The `rabbit:start()` function will probably behave differently in
some ways because it defers everything to the Erlang application
controller (instead of reimplementing it).
2019-05-15 22:27:51 +08:00
|
|
|
if defined ERL_LIBS (
|
2020-06-08 21:42:03 +08:00
|
|
|
set "ERL_LIBS=%RABBITMQ_HOME%\plugins;%ERL_LIBS%"
|
Move most of shell scripts to Erlang code
A large part of the rabbitmq-server(8) and CLI scripts, both
Bourne-shell and Windows Batch versions, was moved to Erlang code and
the RabbitMQ startup procedure was reorganized to be closer to a regular
Erlang application.
A new application called `rabbitmq_prelaunch` is responsible for:
1. Querying the environment variables to initialize important
variables (using the new `rabbit_env` module in rabbitmq-common).
2. Checking the compatibility with the Erlang/OTP runtime.
3. Configuring Erlang distribution.
5. Writing the PID file.
The application is started early (i.e. it is started before `rabbit`).
The `rabbit` application runs the second half of the prelaunch sequence
at the beginning of the application `start()` function. This second
phase is responsible for the following steps:
1. Preparing the feature flags registry.
2. Reading and validating the configuration.
3. Configuring logging.
4. Running the various cluster checks.
In addition to this prelaunch sequence, the `rabbit` application start
procedure ends with a "postlaunch" sequence which takes care of
starting enabled plugins.
Thanks to this, RabbitMQ can be started with `application:start(rabbit)`
as any other Erlang application. The only caveats are:
* Mnesia must be stopped at the time `rabbit_prelaunch` is started,
and must remain stopped when `rabbit` is started, to allow the
Erlang distribution setup and cluster checks. `rabbit` takes care of
starting Mnesia.
* Likewise for Ra, because it relies on the `ra` application
environment to be configured.
Transitioning from scripts to Erlang code has the following benefits:
* RabbitMQ start behavior should be identical between Unix and
Windows. Also, features should be on par now. For instance, RabbitMQ
now writes a PID file on Windows, like it always did on Unix-based
systems.
* The difference between published packages and a development
environment are greatly reduced. In fact, we removed all the "if
this is a dev working copy, then ..." blocks.
As part of that, the `rabbit` application is now treated like its
plugins: it is packaged as an `.ez` archive and written to the
`plugins` directory (even though it is not technically a plugin).
Also in a development copy, the CLI is copied to the top-level
project. So when testing a plugin for instance, the CLI to use is
`sbin/rabbitmqctl` in the current directory, not the master copy in
`rabbit/scripts`.
* As a consequence of the previous two points, maintaining and testing
on Windows is now made easy. It should even be possible to setup CI
on Windows.
* There are less issues with paths containing non-US-ASCII characters,
which can happen on Windows because RabbitMQ stores its data in user
directories by default.
This process brings at least one more benefit: we now have early logging
during this prelaunch phase, which eases diagnostics and debugging.
There are also behavior changes:
* The new format configuration files used to be converted to an
Erlang-term-based file by the Cuttlefish CLI. To do that,
configuration schemas were copied to a temporary directory and the
generated configuration file was written to RabbitMQ data directory.
Now, Cuttlefish is used as a library: everything happens in memory.
No schemas are copied, no generated configuration is written to
disk.
* The PID file is removed when the Erlang VM exits.
* The `rabbit_config` module was trimmed significantly because most of
the configuration handling is done in `rabbit_prelaunch_conf` now.
* The RabbitMQ nodename does not appear on the command line, therefore
it is missing from ps(1) and top(1) output.
* The `rabbit:start()` function will probably behave differently in
some ways because it defers everything to the Erlang application
controller (instead of reimplementing it).
2019-05-15 22:27:51 +08:00
|
|
|
) else (
|
2020-06-08 21:42:03 +08:00
|
|
|
set "ERL_LIBS=%RABBITMQ_HOME%\plugins"
|
Move most of shell scripts to Erlang code
A large part of the rabbitmq-server(8) and CLI scripts, both
Bourne-shell and Windows Batch versions, was moved to Erlang code and
the RabbitMQ startup procedure was reorganized to be closer to a regular
Erlang application.
A new application called `rabbitmq_prelaunch` is responsible for:
1. Querying the environment variables to initialize important
variables (using the new `rabbit_env` module in rabbitmq-common).
2. Checking the compatibility with the Erlang/OTP runtime.
3. Configuring Erlang distribution.
5. Writing the PID file.
The application is started early (i.e. it is started before `rabbit`).
The `rabbit` application runs the second half of the prelaunch sequence
at the beginning of the application `start()` function. This second
phase is responsible for the following steps:
1. Preparing the feature flags registry.
2. Reading and validating the configuration.
3. Configuring logging.
4. Running the various cluster checks.
In addition to this prelaunch sequence, the `rabbit` application start
procedure ends with a "postlaunch" sequence which takes care of
starting enabled plugins.
Thanks to this, RabbitMQ can be started with `application:start(rabbit)`
as any other Erlang application. The only caveats are:
* Mnesia must be stopped at the time `rabbit_prelaunch` is started,
and must remain stopped when `rabbit` is started, to allow the
Erlang distribution setup and cluster checks. `rabbit` takes care of
starting Mnesia.
* Likewise for Ra, because it relies on the `ra` application
environment to be configured.
Transitioning from scripts to Erlang code has the following benefits:
* RabbitMQ start behavior should be identical between Unix and
Windows. Also, features should be on par now. For instance, RabbitMQ
now writes a PID file on Windows, like it always did on Unix-based
systems.
* The difference between published packages and a development
environment are greatly reduced. In fact, we removed all the "if
this is a dev working copy, then ..." blocks.
As part of that, the `rabbit` application is now treated like its
plugins: it is packaged as an `.ez` archive and written to the
`plugins` directory (even though it is not technically a plugin).
Also in a development copy, the CLI is copied to the top-level
project. So when testing a plugin for instance, the CLI to use is
`sbin/rabbitmqctl` in the current directory, not the master copy in
`rabbit/scripts`.
* As a consequence of the previous two points, maintaining and testing
on Windows is now made easy. It should even be possible to setup CI
on Windows.
* There are less issues with paths containing non-US-ASCII characters,
which can happen on Windows because RabbitMQ stores its data in user
directories by default.
This process brings at least one more benefit: we now have early logging
during this prelaunch phase, which eases diagnostics and debugging.
There are also behavior changes:
* The new format configuration files used to be converted to an
Erlang-term-based file by the Cuttlefish CLI. To do that,
configuration schemas were copied to a temporary directory and the
generated configuration file was written to RabbitMQ data directory.
Now, Cuttlefish is used as a library: everything happens in memory.
No schemas are copied, no generated configuration is written to
disk.
* The PID file is removed when the Erlang VM exits.
* The `rabbit_config` module was trimmed significantly because most of
the configuration handling is done in `rabbit_prelaunch_conf` now.
* The RabbitMQ nodename does not appear on the command line, therefore
it is missing from ps(1) and top(1) output.
* The `rabbit:start()` function will probably behave differently in
some ways because it defers everything to the Erlang application
controller (instead of reimplementing it).
2019-05-15 22:27:51 +08:00
|
|
|
)
|
|
|
|
|
|
2015-10-31 01:22:58 +08:00
|
|
|
REM If ERLANG_HOME is not defined, check if "erl.exe" is available in
|
|
|
|
|
REM the path and use that.
|
|
|
|
|
if not defined ERLANG_HOME (
|
2020-01-04 05:35:45 +08:00
|
|
|
for /f "delims=" %%F in ('powershell.exe -NoLogo -NoProfile -NonInteractive -Command "(Get-Command erl.exe).Definition"') do @set ERL_PATH=%%F
|
2015-10-31 01:22:58 +08:00
|
|
|
if exist "!ERL_PATH!" (
|
|
|
|
|
for /f "delims=" %%F in ("!ERL_PATH!") do set ERL_DIRNAME=%%~dpF
|
2019-08-06 23:29:23 +08:00
|
|
|
for /f "delims=" %%F in ("!ERL_DIRNAME!\..") do @set ERLANG_HOME=%%~dpF%%~nF%%~xF
|
2015-10-31 01:22:58 +08:00
|
|
|
)
|
|
|
|
|
set ERL_PATH=
|
|
|
|
|
set ERL_DIRNAME=
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
REM ## Set defaults
|
|
|
|
|
call "%SCRIPT_DIR%\rabbitmq-defaults.bat"
|
|
|
|
|
|
2018-02-24 03:49:25 +08:00
|
|
|
if "!RABBITMQ_CONF_ENV_FILE!"=="" (
|
2019-08-06 23:29:23 +08:00
|
|
|
set RABBITMQ_CONF_ENV_FILE=!CONF_ENV_FILE:"=!
|
|
|
|
|
) else (
|
|
|
|
|
set RABBITMQ_CONF_ENV_FILE=!RABBITMQ_CONF_ENV_FILE:"=!
|
2018-02-24 03:49:25 +08:00
|
|
|
)
|
2016-07-14 18:19:17 +08:00
|
|
|
|
2018-02-24 03:49:25 +08:00
|
|
|
if exist "!RABBITMQ_CONF_ENV_FILE!" (
|
|
|
|
|
call "!RABBITMQ_CONF_ENV_FILE!"
|
|
|
|
|
)
|
|
|
|
|
|
2019-09-24 03:51:53 +08:00
|
|
|
rem Bump ETS table limit to 50000
|
|
|
|
|
if "!ERL_MAX_ETS_TABLES!"=="" (
|
|
|
|
|
set ERL_MAX_ETS_TABLES=50000
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
rem Default is defined here:
|
|
|
|
|
rem https://github.com/erlang/otp/blob/master/erts/emulator/beam/erl_port.h
|
|
|
|
|
if "!ERL_MAX_PORTS!"=="" (
|
|
|
|
|
set ERL_MAX_PORTS=65536
|
|
|
|
|
)
|
|
|
|
|
|
2018-02-24 03:49:25 +08:00
|
|
|
set DEFAULT_SCHEDULER_BIND_TYPE=db
|
|
|
|
|
if "!RABBITMQ_SCHEDULER_BIND_TYPE!"=="" (
|
|
|
|
|
set RABBITMQ_SCHEDULER_BIND_TYPE=!SCHEDULER_BIND_TYPE!
|
|
|
|
|
)
|
2016-07-14 18:19:17 +08:00
|
|
|
if "!RABBITMQ_SCHEDULER_BIND_TYPE!"=="" (
|
|
|
|
|
set RABBITMQ_SCHEDULER_BIND_TYPE=!DEFAULT_SCHEDULER_BIND_TYPE!
|
|
|
|
|
)
|
|
|
|
|
|
2017-07-27 23:28:02 +08:00
|
|
|
set DEFAULT_DISTRIBUTION_BUFFER_SIZE=128000
|
2018-02-24 03:49:25 +08:00
|
|
|
if "!RABBITMQ_DISTRIBUTION_BUFFER_SIZE!"=="" (
|
|
|
|
|
set RABBITMQ_DISTRIBUTION_BUFFER_SIZE=!DISTRIBUTION_BUFFER_SIZE!
|
|
|
|
|
)
|
2016-09-12 17:48:37 +08:00
|
|
|
if "!RABBITMQ_DISTRIBUTION_BUFFER_SIZE!"=="" (
|
|
|
|
|
set RABBITMQ_DISTRIBUTION_BUFFER_SIZE=!DEFAULT_DISTRIBUTION_BUFFER_SIZE!
|
|
|
|
|
)
|
|
|
|
|
|
2018-02-24 03:49:25 +08:00
|
|
|
set DEFAULT_MAX_NUMBER_OF_PROCESSES=1048576
|
|
|
|
|
if "!RABBITMQ_MAX_NUMBER_OF_PROCESSES!"=="" (
|
|
|
|
|
set RABBITMQ_MAX_NUMBER_OF_PROCESSES=!MAX_NUMBER_OF_PROCESSES!
|
|
|
|
|
)
|
|
|
|
|
if "!RABBITMQ_MAX_NUMBER_OF_PROCESSES!"=="" (
|
|
|
|
|
set RABBITMQ_MAX_NUMBER_OF_PROCESSES=!DEFAULT_MAX_NUMBER_OF_PROCESSES!
|
2016-04-05 20:58:36 +08:00
|
|
|
)
|
|
|
|
|
|
2018-02-24 03:49:25 +08:00
|
|
|
set DEFAULT_MAX_NUMBER_OF_ATOMS=5000000
|
|
|
|
|
if "!RABBITMQ_MAX_NUMBER_OF_ATOMS!"=="" (
|
|
|
|
|
set RABBITMQ_MAX_NUMBER_OF_ATOMS=!MAX_NUMBER_OF_ATOMS!
|
|
|
|
|
)
|
|
|
|
|
if "!RABBITMQ_MAX_NUMBER_OF_ATOMS!"=="" (
|
|
|
|
|
set RABBITMQ_MAX_NUMBER_OF_ATOMS=!DEFAULT_MAX_NUMBER_OF_ATOMS!
|
2015-10-31 01:22:58 +08:00
|
|
|
)
|
|
|
|
|
|
2021-02-10 19:35:12 +08:00
|
|
|
set DEFAULT_SCHEDULER_BUSY_WAIT_THRESHOLD=none
|
|
|
|
|
if "!RABBITMQ_SCHEDULER_BUSY_WAIT_THRESHOLD!"=="" (
|
|
|
|
|
set RABBITMQ_SCHEDULER_BUSY_WAIT_THRESHOLD=!SCHEDULER_BUSY_WAIT_THRESHOLD!
|
|
|
|
|
)
|
|
|
|
|
if "!RABBITMQ_SCHEDULER_BUSY_WAIT_THRESHOLD!"=="" (
|
|
|
|
|
set RABBITMQ_SCHEDULER_BUSY_WAIT_THRESHOLD=!DEFAULT_SCHEDULER_BUSY_WAIT_THRESHOLD!
|
|
|
|
|
)
|
|
|
|
|
|
Move most of shell scripts to Erlang code
A large part of the rabbitmq-server(8) and CLI scripts, both
Bourne-shell and Windows Batch versions, was moved to Erlang code and
the RabbitMQ startup procedure was reorganized to be closer to a regular
Erlang application.
A new application called `rabbitmq_prelaunch` is responsible for:
1. Querying the environment variables to initialize important
variables (using the new `rabbit_env` module in rabbitmq-common).
2. Checking the compatibility with the Erlang/OTP runtime.
3. Configuring Erlang distribution.
5. Writing the PID file.
The application is started early (i.e. it is started before `rabbit`).
The `rabbit` application runs the second half of the prelaunch sequence
at the beginning of the application `start()` function. This second
phase is responsible for the following steps:
1. Preparing the feature flags registry.
2. Reading and validating the configuration.
3. Configuring logging.
4. Running the various cluster checks.
In addition to this prelaunch sequence, the `rabbit` application start
procedure ends with a "postlaunch" sequence which takes care of
starting enabled plugins.
Thanks to this, RabbitMQ can be started with `application:start(rabbit)`
as any other Erlang application. The only caveats are:
* Mnesia must be stopped at the time `rabbit_prelaunch` is started,
and must remain stopped when `rabbit` is started, to allow the
Erlang distribution setup and cluster checks. `rabbit` takes care of
starting Mnesia.
* Likewise for Ra, because it relies on the `ra` application
environment to be configured.
Transitioning from scripts to Erlang code has the following benefits:
* RabbitMQ start behavior should be identical between Unix and
Windows. Also, features should be on par now. For instance, RabbitMQ
now writes a PID file on Windows, like it always did on Unix-based
systems.
* The difference between published packages and a development
environment are greatly reduced. In fact, we removed all the "if
this is a dev working copy, then ..." blocks.
As part of that, the `rabbit` application is now treated like its
plugins: it is packaged as an `.ez` archive and written to the
`plugins` directory (even though it is not technically a plugin).
Also in a development copy, the CLI is copied to the top-level
project. So when testing a plugin for instance, the CLI to use is
`sbin/rabbitmqctl` in the current directory, not the master copy in
`rabbit/scripts`.
* As a consequence of the previous two points, maintaining and testing
on Windows is now made easy. It should even be possible to setup CI
on Windows.
* There are less issues with paths containing non-US-ASCII characters,
which can happen on Windows because RabbitMQ stores its data in user
directories by default.
This process brings at least one more benefit: we now have early logging
during this prelaunch phase, which eases diagnostics and debugging.
There are also behavior changes:
* The new format configuration files used to be converted to an
Erlang-term-based file by the Cuttlefish CLI. To do that,
configuration schemas were copied to a temporary directory and the
generated configuration file was written to RabbitMQ data directory.
Now, Cuttlefish is used as a library: everything happens in memory.
No schemas are copied, no generated configuration is written to
disk.
* The PID file is removed when the Erlang VM exits.
* The `rabbit_config` module was trimmed significantly because most of
the configuration handling is done in `rabbit_prelaunch_conf` now.
* The RabbitMQ nodename does not appear on the command line, therefore
it is missing from ps(1) and top(1) output.
* The `rabbit:start()` function will probably behave differently in
some ways because it defers everything to the Erlang application
controller (instead of reimplementing it).
2019-05-15 22:27:51 +08:00
|
|
|
REM Common server defaults
|
2021-02-10 19:35:12 +08:00
|
|
|
set SERVER_ERL_ARGS=+P !RABBITMQ_MAX_NUMBER_OF_PROCESSES! +t !RABBITMQ_MAX_NUMBER_OF_ATOMS! +stbt !RABBITMQ_SCHEDULER_BIND_TYPE! +zdbbl !RABBITMQ_DISTRIBUTION_BUFFER_SIZE! +sbwt !RABBITMQ_SCHEDULER_BUSY_WAIT_THRESHOLD! +sbwtdcpu !RABBITMQ_SCHEDULER_BUSY_WAIT_THRESHOLD! +sbwtdio !RABBITMQ_SCHEDULER_BUSY_WAIT_THRESHOLD!
|
2018-02-24 03:49:25 +08:00
|
|
|
|
2015-10-31 01:22:58 +08:00
|
|
|
REM ##--- Set environment vars RABBITMQ_<var_name> to defaults if not set
|
|
|
|
|
|
|
|
|
|
REM [ "x" = "x$RABBITMQ_SERVER_ERL_ARGS" ] && RABBITMQ_SERVER_ERL_ARGS=${SERVER_ERL_ARGS}
|
2016-07-14 18:19:17 +08:00
|
|
|
if "!RABBITMQ_SERVER_ERL_ARGS!"=="" (
|
|
|
|
|
set RABBITMQ_SERVER_ERL_ARGS=!SERVER_ERL_ARGS!
|
|
|
|
|
)
|
2015-10-31 01:22:58 +08:00
|
|
|
|
|
|
|
|
REM [ "x" = "x$RABBITMQ_SERVER_START_ARGS" ] && RABBITMQ_SERVER_START_ARGS=${SERVER_START_ARGS}
|
2018-08-09 04:37:35 +08:00
|
|
|
if "!RABBITMQ_SERVER_START_ARGS!"=="" (
|
|
|
|
|
if not "!SERVER_START_ARGS!"=="" (
|
|
|
|
|
set RABBITMQ_SERVER_START_ARGS=!SERVER_START_ARGS!
|
|
|
|
|
)
|
|
|
|
|
)
|
2015-10-31 01:22:58 +08:00
|
|
|
|
|
|
|
|
REM [ "x" = "x$RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS" ] && RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS=${SERVER_ADDITIONAL_ERL_ARGS}
|
2018-08-09 04:37:35 +08:00
|
|
|
if "!RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS!"=="" (
|
|
|
|
|
if not "!SERVER_ADDITIONAL_ERL_ARGS!"=="" (
|
|
|
|
|
set RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS=!SERVER_ADDITIONAL_ERL_ARGS!
|
|
|
|
|
)
|
|
|
|
|
)
|
2015-10-31 01:22:58 +08:00
|
|
|
|
|
|
|
|
REM [ "x" = "x$RABBITMQ_BOOT_MODULE" ] && RABBITMQ_BOOT_MODULE=${BOOT_MODULE}
|
|
|
|
|
if "!RABBITMQ_BOOT_MODULE!"=="" (
|
2015-10-31 01:29:57 +08:00
|
|
|
if "!BOOT_MODULE!"=="" (
|
|
|
|
|
set RABBITMQ_BOOT_MODULE=rabbit
|
|
|
|
|
) else (
|
|
|
|
|
set RABBITMQ_BOOT_MODULE=!BOOT_MODULE!
|
|
|
|
|
)
|
2015-10-31 01:22:58 +08:00
|
|
|
)
|
|
|
|
|
|
|
|
|
|
REM [ "x" = "x$RABBITMQ_CTL_ERL_ARGS" ] && RABBITMQ_CTL_ERL_ARGS=${CTL_ERL_ARGS}
|
2018-01-30 23:56:12 +08:00
|
|
|
if "!RABBITMQ_CTL_ERL_ARGS!"=="" (
|
2015-10-31 01:29:57 +08:00
|
|
|
if not "!CTL_ERL_ARGS!"=="" (
|
|
|
|
|
set RABBITMQ_CTL_ERL_ARGS=!CTL_ERL_ARGS!
|
|
|
|
|
)
|
2015-10-31 01:22:58 +08:00
|
|
|
)
|
|
|
|
|
|
2020-06-25 21:20:23 +08:00
|
|
|
if "!RABBITMQ_CTL_DIST_PORT_MIN!"=="" (
|
|
|
|
|
if not "!CTL_DIST_PORT_MIN!"=="" (
|
|
|
|
|
set RABBITMQ_CTL_DIST_PORT_MIN=!CTL_DIST_PORT_MIN!
|
|
|
|
|
)
|
|
|
|
|
)
|
|
|
|
|
if "!RABBITMQ_CTL_DIST_PORT_MAX!"=="" (
|
|
|
|
|
if not "!CTL_DIST_PORT_MAX!"=="" (
|
|
|
|
|
set RABBITMQ_CTL_DIST_PORT_MAX=!CTL_DIST_PORT_MAX!
|
|
|
|
|
)
|
|
|
|
|
)
|
|
|
|
|
if "!RABBITMQ_CTL_DIST_PORT_MIN!"=="" (
|
|
|
|
|
set RABBITMQ_CTL_DIST_PORT_MIN=35672
|
|
|
|
|
)
|
|
|
|
|
if "!RABBITMQ_CTL_DIST_PORT_MAX!"=="" (
|
|
|
|
|
set /a RABBITMQ_CTL_DIST_PORT_MAX=10+!RABBITMQ_CTL_DIST_PORT_MIN!
|
|
|
|
|
)
|
|
|
|
|
|
2015-10-31 01:22:58 +08:00
|
|
|
REM ADDITIONAL WINDOWS ONLY CONFIG ITEMS
|
|
|
|
|
|
|
|
|
|
if "!RABBITMQ_SERVICENAME!"=="" (
|
2015-10-31 01:29:57 +08:00
|
|
|
if "!SERVICENAME!"=="" (
|
|
|
|
|
set RABBITMQ_SERVICENAME=RabbitMQ
|
|
|
|
|
) else (
|
|
|
|
|
set RABBITMQ_SERVICENAME=!SERVICENAME!
|
|
|
|
|
)
|
2015-10-31 01:22:58 +08:00
|
|
|
)
|
|
|
|
|
|
2015-12-14 20:52:47 +08:00
|
|
|
REM Environment cleanup
|
|
|
|
|
set BOOT_MODULE=
|
|
|
|
|
set CONFIG_FILE=
|
2019-01-23 01:02:40 +08:00
|
|
|
set FEATURE_FLAGS_FILE=
|
2015-12-14 20:52:47 +08:00
|
|
|
set ENABLED_PLUGINS_FILE=
|
|
|
|
|
set LOG_BASE=
|
|
|
|
|
set MNESIA_BASE=
|
|
|
|
|
set PLUGINS_DIR=
|
|
|
|
|
set SCRIPT_DIR=
|
|
|
|
|
set SCRIPT_NAME=
|
|
|
|
|
set TDP0=
|
2015-10-31 01:22:58 +08:00
|
|
|
|
|
|
|
|
REM ##--- End of overridden <var_name> variables
|
Move most of shell scripts to Erlang code
A large part of the rabbitmq-server(8) and CLI scripts, both
Bourne-shell and Windows Batch versions, was moved to Erlang code and
the RabbitMQ startup procedure was reorganized to be closer to a regular
Erlang application.
A new application called `rabbitmq_prelaunch` is responsible for:
1. Querying the environment variables to initialize important
variables (using the new `rabbit_env` module in rabbitmq-common).
2. Checking the compatibility with the Erlang/OTP runtime.
3. Configuring Erlang distribution.
5. Writing the PID file.
The application is started early (i.e. it is started before `rabbit`).
The `rabbit` application runs the second half of the prelaunch sequence
at the beginning of the application `start()` function. This second
phase is responsible for the following steps:
1. Preparing the feature flags registry.
2. Reading and validating the configuration.
3. Configuring logging.
4. Running the various cluster checks.
In addition to this prelaunch sequence, the `rabbit` application start
procedure ends with a "postlaunch" sequence which takes care of
starting enabled plugins.
Thanks to this, RabbitMQ can be started with `application:start(rabbit)`
as any other Erlang application. The only caveats are:
* Mnesia must be stopped at the time `rabbit_prelaunch` is started,
and must remain stopped when `rabbit` is started, to allow the
Erlang distribution setup and cluster checks. `rabbit` takes care of
starting Mnesia.
* Likewise for Ra, because it relies on the `ra` application
environment to be configured.
Transitioning from scripts to Erlang code has the following benefits:
* RabbitMQ start behavior should be identical between Unix and
Windows. Also, features should be on par now. For instance, RabbitMQ
now writes a PID file on Windows, like it always did on Unix-based
systems.
* The difference between published packages and a development
environment are greatly reduced. In fact, we removed all the "if
this is a dev working copy, then ..." blocks.
As part of that, the `rabbit` application is now treated like its
plugins: it is packaged as an `.ez` archive and written to the
`plugins` directory (even though it is not technically a plugin).
Also in a development copy, the CLI is copied to the top-level
project. So when testing a plugin for instance, the CLI to use is
`sbin/rabbitmqctl` in the current directory, not the master copy in
`rabbit/scripts`.
* As a consequence of the previous two points, maintaining and testing
on Windows is now made easy. It should even be possible to setup CI
on Windows.
* There are less issues with paths containing non-US-ASCII characters,
which can happen on Windows because RabbitMQ stores its data in user
directories by default.
This process brings at least one more benefit: we now have early logging
during this prelaunch phase, which eases diagnostics and debugging.
There are also behavior changes:
* The new format configuration files used to be converted to an
Erlang-term-based file by the Cuttlefish CLI. To do that,
configuration schemas were copied to a temporary directory and the
generated configuration file was written to RabbitMQ data directory.
Now, Cuttlefish is used as a library: everything happens in memory.
No schemas are copied, no generated configuration is written to
disk.
* The PID file is removed when the Erlang VM exits.
* The `rabbit_config` module was trimmed significantly because most of
the configuration handling is done in `rabbit_prelaunch_conf` now.
* The RabbitMQ nodename does not appear on the command line, therefore
it is missing from ps(1) and top(1) output.
* The `rabbit:start()` function will probably behave differently in
some ways because it defers everything to the Erlang application
controller (instead of reimplementing it).
2019-05-15 22:27:51 +08:00
|
|
|
|
2015-10-31 01:22:58 +08:00
|
|
|
REM # Since we source this elsewhere, don't accidentally stop execution
|
|
|
|
|
REM true
|
