- May 26, 2023
-
-
-
Daniel Lyons authored
Except for delivery, because why not.
-
Daniel Lyons authored
-
Daniel Lyons authored
-
- Apr 26, 2023
-
-
- Apr 25, 2023
-
-
Daniel Lyons authored
-
- Apr 04, 2023
-
-
Brittany Faciane authored
-
- Apr 03, 2023
-
- Jan 10, 2023
-
-
Nathan Bockisch authored
-
- Nov 09, 2022
-
-
Charlotte Hausman authored
-
- Oct 10, 2022
-
-
Charlotte Hausman authored
-
- Sep 07, 2022
-
-
Charlotte Hausman authored
-
- Jun 07, 2022
-
-
Jim Sheckard authored
-
-
- May 23, 2022
-
-
Jim Sheckard authored
-
- May 17, 2022
-
-
Jim Sheckard authored
-
- May 10, 2022
-
-
Charlotte Hausman authored
-
Charlotte Hausman authored
-
- Dec 21, 2021
-
-
Nathan Hertz authored
-
- Oct 20, 2021
-
-
Andrew Kapuscinski authored
-
- Oct 12, 2021
-
-
- Sep 28, 2021
-
-
Janet Goldstein authored
-
- Sep 27, 2021
-
-
Janet Goldstein authored
-
- Sep 07, 2021
-
-
Daniel Lyons authored
This is two lines of thought combined into one merge: 1. AMQP clients should either receive messages or send messages 2. Capability queues are based on a database-backed queue manager rather than keeping state in-memory Most of the work relating to the first idea comes in refactoring the Router to not be a message sender. Many places in the code now either instantiate a MessageSender instead, or use both a Router and a MessageSender if they truly needed both functionalities. The previous implementation appears to have caused messages to arrive out of order because facilities like `wf_monitor` that only send messages were also trying to receive messages, and either not handling them at all or putting them into a buffer of some kind to be dropped on the floor when the process ended. The work relating to the second idea changes the way that steps are processed in the capability service and eliminates the capability engine concept. Now when PrepareAndRunWorkflow steps are reached, the capability is simply moved into the Waiting state and the queue manager is signaled. Whenever the queue manager is awakened, it checks to see if any queues have slots available and requests waiting. If they do, the number of available slots are used to get requests and start executing them. When an execution exits the cluster, the queue manager is signaled again, so the process continues until all the jobs are processed. As a stability benefit, we check this on startup as well.
-
- Aug 19, 2021
-
-
- Jun 09, 2021
-
-
Nathan Hertz authored
-
Janet Goldstein authored
-
- Jun 03, 2021
-
-
Charlotte Hausman authored
-
- May 19, 2021
-
-
Nathan Hertz authored
- Local cluster can now run download workflows - wf_monitor's timeout functionality now works the way we expect it to
-
- May 17, 2021
-
-
Nathan Hertz authored
-
- Mar 31, 2021
-
-
Charlotte Hausman authored
changing default spl to smaller image spl
-
- Mar 22, 2021
-
-
- Datafetcher runs in container and retrieves data - Delivery can deliver data to a directory within the container
-
- Mar 18, 2021
-
-
Messaging system is now running on a more robust foundation: - `kombu` package for AMQP networking - New Messenger and Router objects - New message format - Easy-to-use callback subscribing - Can now get messages anywhere in the system easily and send replies back easily
-
- Feb 17, 2021
-
-
Daniel Lyons authored
-
- Feb 02, 2021
-
-
Nathan Hertz authored
-
- Jan 28, 2021
-
-
Nathan Hertz authored
All enabled tests are now true unit tests with no external dependencies; new `requirements.txt` file in `test/` that installs testing requirements (`pytest`, `pytest-mock`, etc.); and `run-tests.sh` now has an extra step that installs these
-
- Jan 26, 2021
-
-
Nathan Hertz authored
-
- Jan 22, 2021
-
-
Nathan Hertz authored
All enabled tests now pass. TODO: Refactor integration tests into unit tests; add more test coverage
-
- Jan 21, 2021
-
-
Nathan Hertz authored
-
- Jan 08, 2021
-
-
Janet Goldstein authored
system since I figure that's on its way out the door)
-