From 3d1098329fc653c31f4d5d6c40bcf960ada5739c Mon Sep 17 00:00:00 2001 From: Anil Panta Date: Mon, 5 May 2025 14:17:40 -0400 Subject: [PATCH 1/4] Add detailed documentation for Transfers Poller/Receiver daemons #397 --- docs/operator_transfers/transfers_overview.md | 3 +- .../transfers_poller_receiver.md | 60 +++++++++++++++++++ 2 files changed, 62 insertions(+), 1 deletion(-) create mode 100644 docs/operator_transfers/transfers_poller_receiver.md diff --git a/docs/operator_transfers/transfers_overview.md b/docs/operator_transfers/transfers_overview.md index 0ebeaa84a9e..ead0e356dc3 100644 --- a/docs/operator_transfers/transfers_overview.md +++ b/docs/operator_transfers/transfers_overview.md @@ -126,7 +126,8 @@ documentation. The path will be then submitted to the transfertool either in its integrity, if transfertool supports multi-hopping, or in multiple iterations. -The final steps are for the `receiver` or `poller` to monitor the transfer's +The final steps are for the `receiver` or `poller` (refer to [Poller/Receiver](transfers_poller_receiver.md)) +to monitor the transfer's completion in transfertool and `finisher` to mark the transfers as completed. We only described here a simple case, when the transfer is successful on the first try. In case of errors, multiple transitions are possible between diff --git a/docs/operator_transfers/transfers_poller_receiver.md b/docs/operator_transfers/transfers_poller_receiver.md new file mode 100644 index 00000000000..ae2d05598e8 --- /dev/null +++ b/docs/operator_transfers/transfers_poller_receiver.md @@ -0,0 +1,60 @@ +--- +id: transfers_poller_receiver +title: Transfers Poller/Receiver +--- + +`conveyor-poller` / `conveyor-receiver` are daemons responsible for checking the status of transfers and updating their state. + +## Poller + +The `conveyor-poller` daemon periodically queries the transfer tools (such as FTS, Globus, or BitTorrent) directly to retrieve the status of ongoing transfers. +Based on the results, it updates the state of each transfer in the system and/or refreshes the last access time. +The transfer tool to query is determined from the transfer information internally, so **no additional configuration is needed**. + +**If using Globus or BitTorrent as the transfer tool, you need to use the poller.** + +## Receiver + +The `conveyor-receiver` daemon subscribes to an ActiveMQ message queue and continuously listens for transfer status updates. +When it receives a message, it processes the update, changes the transfer's state accordingly, and/or updates the last access time. + +**If FTS is used as the transfer tool, it is recommended to use the receiver, although the poller also works.** +**To set up FTS to send transfer status updates to ActiveMQ, see the instructions [here]().** +First, configure FTS to publish transfer updates to an ActiveMQ broker. More information is available in the [FTS3 Messaging Guide](https://fts3-docs.web.cern.ch/fts3-docs/docs/messaging.html). + +> **Note:** The receiver connects to ActiveMQ using the **STOMP protocol**, so ensure your ActiveMQ instance has STOMP support enabled. + +In your `rucio.cfg`, include the following section: + +```cfg +[messaging-fts3] +# Set to True to use SSL with certificate/key authentication, or False to use username/password +use_ssl = True + +# A comma-separated list of ActiveMQ broker DNS hostnames or aliases +brokers = activemq1.example.org,activemq2.example.org + +# Only required if use_ssl = False +username = your-username +password = your-password + +# Port to use when NOT using SSL (i.e., use_ssl = False) +nonssl_port = 61613 + +# Port to use when using SSL (i.e., use_ssl = True) +port = 61617 + +# Required if use_ssl = True +ssl_key_file = /path/to/hostkey.pem +ssl_cert_file = /path/to/hostcert.pem + +# The message topic or queue where FTS publishes transfer status updates +destination = /topic/transfer.fts_monitoring_queue_state + +# Optional: virtual host name used to connect to the broker +# This is only needed if your ActiveMQ setup requires a virtual host (e.g., in multi-tenant environments) +broker_virtual_host = /atlas +``` + +The topic the receiver daemon subscribes to is the value of `destination` in the configuration. +Make sure it matches the topic or queue FTS3 is publishing to. From 8731c1666f15b2bcea581f8f308d1989fb120875 Mon Sep 17 00:00:00 2001 From: Anil Panta Date: Mon, 5 May 2025 14:29:15 -0400 Subject: [PATCH 2/4] some edits to make it clear at the top #397 --- .../transfers_poller_receiver.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/docs/operator_transfers/transfers_poller_receiver.md b/docs/operator_transfers/transfers_poller_receiver.md index ae2d05598e8..1bae22b8569 100644 --- a/docs/operator_transfers/transfers_poller_receiver.md +++ b/docs/operator_transfers/transfers_poller_receiver.md @@ -3,13 +3,18 @@ id: transfers_poller_receiver title: Transfers Poller/Receiver --- -`conveyor-poller` / `conveyor-receiver` are daemons responsible for checking the status of transfers and updating their state. +`conveyor-poller` and `conveyor-receiver` are daemons responsible for tracking transfer status and updating it in the system. +**You need to run one or both of them** depending on the transfer tool you are using: + +- If you are using only **FTS3**, it is **recommended to use the receiver** for scalability. Although poller also works. +- If you are using only **Globus and/or BitTorrent**, you only need to run the poller. +- If both **FTS3** and **Globus and/or BitTorrent**, you need both receiver and poller. ## Poller The `conveyor-poller` daemon periodically queries the transfer tools (such as FTS, Globus, or BitTorrent) directly to retrieve the status of ongoing transfers. Based on the results, it updates the state of each transfer in the system and/or refreshes the last access time. -The transfer tool to query is determined from the transfer information internally, so **no additional configuration is needed**. +The transfer tool to query is taken from the transfer information internally and **no additional configuration is needed**. **If using Globus or BitTorrent as the transfer tool, you need to use the poller.** @@ -18,7 +23,6 @@ The transfer tool to query is determined from the transfer information internall The `conveyor-receiver` daemon subscribes to an ActiveMQ message queue and continuously listens for transfer status updates. When it receives a message, it processes the update, changes the transfer's state accordingly, and/or updates the last access time. -**If FTS is used as the transfer tool, it is recommended to use the receiver, although the poller also works.** **To set up FTS to send transfer status updates to ActiveMQ, see the instructions [here]().** First, configure FTS to publish transfer updates to an ActiveMQ broker. More information is available in the [FTS3 Messaging Guide](https://fts3-docs.web.cern.ch/fts3-docs/docs/messaging.html). @@ -48,7 +52,7 @@ port = 61617 ssl_key_file = /path/to/hostkey.pem ssl_cert_file = /path/to/hostcert.pem -# The message topic or queue where FTS publishes transfer status updates +# The message topic or queue where FTS publishes transfer status updates. destination = /topic/transfer.fts_monitoring_queue_state # Optional: virtual host name used to connect to the broker @@ -56,5 +60,3 @@ destination = /topic/transfer.fts_monitoring_queue_state broker_virtual_host = /atlas ``` -The topic the receiver daemon subscribes to is the value of `destination` in the configuration. -Make sure it matches the topic or queue FTS3 is publishing to. From ec31d7c80472c985423ac9058c9e6c37cb8f3e0b Mon Sep 17 00:00:00 2001 From: Anil Panta Date: Mon, 5 May 2025 14:33:29 -0400 Subject: [PATCH 3/4] fts messaging link edit #397 --- docs/operator_transfers/transfers_poller_receiver.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/docs/operator_transfers/transfers_poller_receiver.md b/docs/operator_transfers/transfers_poller_receiver.md index 1bae22b8569..e8fa0fc51b3 100644 --- a/docs/operator_transfers/transfers_poller_receiver.md +++ b/docs/operator_transfers/transfers_poller_receiver.md @@ -23,12 +23,11 @@ The transfer tool to query is taken from the transfer information internally and The `conveyor-receiver` daemon subscribes to an ActiveMQ message queue and continuously listens for transfer status updates. When it receives a message, it processes the update, changes the transfer's state accordingly, and/or updates the last access time. -**To set up FTS to send transfer status updates to ActiveMQ, see the instructions [here]().** -First, configure FTS to publish transfer updates to an ActiveMQ broker. More information is available in the [FTS3 Messaging Guide](https://fts3-docs.web.cern.ch/fts3-docs/docs/messaging.html). +To set up FTS to send transfer status updates to ActiveMQ broker, see the instructions [FTS3 Messaging Guide](https://fts3-docs.web.cern.ch/fts3-docs/docs/messaging.html). > **Note:** The receiver connects to ActiveMQ using the **STOMP protocol**, so ensure your ActiveMQ instance has STOMP support enabled. -In your `rucio.cfg`, include the following section: +To configure `conveyor-receiver`, your rucio server config i.e. `rucio.cfg`, include the following section with described options: ```cfg [messaging-fts3] From 1d4b4ea19acc7ac0391c8fb87a1ac6264ffe1541 Mon Sep 17 00:00:00 2001 From: Anil Panta <47672624+panta-123@users.noreply.github.com> Date: Mon, 5 May 2025 23:11:25 +0000 Subject: [PATCH 4/4] add activeMQ note, remove bold and change topic name #397 --- .../operator_transfers/transfers_poller_receiver.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/docs/operator_transfers/transfers_poller_receiver.md b/docs/operator_transfers/transfers_poller_receiver.md index e8fa0fc51b3..0621cb12ff8 100644 --- a/docs/operator_transfers/transfers_poller_receiver.md +++ b/docs/operator_transfers/transfers_poller_receiver.md @@ -6,9 +6,9 @@ title: Transfers Poller/Receiver `conveyor-poller` and `conveyor-receiver` are daemons responsible for tracking transfer status and updating it in the system. **You need to run one or both of them** depending on the transfer tool you are using: -- If you are using only **FTS3**, it is **recommended to use the receiver** for scalability. Although poller also works. -- If you are using only **Globus and/or BitTorrent**, you only need to run the poller. -- If both **FTS3** and **Globus and/or BitTorrent**, you need both receiver and poller. +- If you are using only FTS3, it is **recommended to use the receiver** for scalability. Although poller also works. +- If you are using only Globus and/or BitTorrent, you only need to run the poller. +- If both FTS3 and Globus and/or BitTorrent, you need both receiver and poller. ## Poller @@ -25,7 +25,8 @@ When it receives a message, it processes the update, changes the transfer's stat To set up FTS to send transfer status updates to ActiveMQ broker, see the instructions [FTS3 Messaging Guide](https://fts3-docs.web.cern.ch/fts3-docs/docs/messaging.html). -> **Note:** The receiver connects to ActiveMQ using the **STOMP protocol**, so ensure your ActiveMQ instance has STOMP support enabled. +> **Note:** The receiver connects to ActiveMQ using the **STOMP protocol**, so ensure your ActiveMQ instance has STOMP support enabled. As of this writing (May 2025), CERN FTS uses [ActiveMQ-Classic](https://activemq.apache.org/components/classic/) and +not tested with [ActiveMQ-Artemis](https://activemq.apache.org/components/artemis/). To configure `conveyor-receiver`, your rucio server config i.e. `rucio.cfg`, include the following section with described options: @@ -51,8 +52,8 @@ port = 61617 ssl_key_file = /path/to/hostkey.pem ssl_cert_file = /path/to/hostcert.pem -# The message topic or queue where FTS publishes transfer status updates. -destination = /topic/transfer.fts_monitoring_queue_state +# The message topic or queue where FTS publishes transfer status (complete) updates. +destination = /topic/transfer.fts_monitoring_complete # Optional: virtual host name used to connect to the broker # This is only needed if your ActiveMQ setup requires a virtual host (e.g., in multi-tenant environments)