Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Single queue #12

Merged
merged 4 commits into from
Nov 11, 2022
Merged

Single queue #12

merged 4 commits into from
Nov 11, 2022

Conversation

krulis-martin
Copy link
Member

No description provided.

janbuchar
janbuchar previously approved these changes Nov 11, 2022
Copy link
Member

@janbuchar janbuchar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems legit!

CMakeLists.txt Show resolved Hide resolved
README.md Outdated
@@ -144,6 +144,7 @@ The default location for broker configuration file is
`err`, `warn`, `notice`, `info` and `debug`
- _max-size_ -- maximal size of log file before rotating
- _rotations_ -- number of rotation kept
- _queue_manager_ -- selection of the queue manager implementation responsible for assigning jobs to workers. Currently only `single` (the default) and `multi` queue managers are in production version. Single-queue manager has one queue and dispatches jobs on demand as workers become available. Multi-queue manager has a queue for every worker, jobs are assigned immediately and cannot be re-assigned unless failure occurs. I.e., `single` provides better load balancing, `mutli` has lower dispatching overhead.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tpyo

@@ -127,7 +128,17 @@ void broker_core::broker_init()
logger_->info("Initializing broker connection...");
workers_ = std::make_shared<worker_registry>();
context_ = std::make_shared<zmq::context_t>(1);
queue_ = std::make_shared<multi_queue_manager>();

// Yes, this may be done better, but it will do for now.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I were pedantic, I would ask you to elaborate on what's the better way. But I'm not, so keep your secrets if you want.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can create a static map<string, obj>, where the obj is either factory, prototype, or singleton. This map can be then filled by static constructors (so the "registration" for translation is done along with the declaration and will not be forgotten when extensions are implemented). However, for 2 or 3 manager classes, it does not worth implementing.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

heh, that sounds like so much of an overkill I'd even remove the comment

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I have a personal grudge against extensive if-else branching, so I shall keep it :)

src/queuing/queue_manager_interface.h Show resolved Hide resolved
return a.arrived_at < b.arrived_at;
}

void drop_caches() {}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe we can safely remove this - it was there to speed up the simulation of another comparator (OAGM, if I recall correctly), which wasn't that great anyways.

if (!is_request_assignable(job.request)) {
// the job cannot be accomodated anymore...
result->push_back(job.request);
job.request = nullptr; // mark the job for removal
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's... unusual. In such short code though... I guess it's alright

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is unusual? The marking for deletion? If you have a better way, I would be happy to entertain it, but I am quite sure that deleting items from a container in a for-each loop (over that container) is not something you want to do...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I went with the "mark for deletion" route, I'd probably make a separate collection of stuff to remove. As I said, the current implementation works just fine and it's unlikely the method will ever grow enough for it to become unmaintainable.

An alternative idea I have is to use stable_partition to push the unsatisfiable request to the edge of the queue and then snip them off.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's what remove_if does ... I guess I have become too biased towards functional JS-like solutions ;)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well, you can call mutating the queue items in place many names, but functional isn't one of them 🙂

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, I mutated the objects inside, but the collection was intact until filtered by erase-remove, which is functional (that's what I meant).

@codecov-commenter
Copy link

Codecov Report

Merging #12 (31fe7fa) into master (1faa3b1) will increase coverage by 1.32%.
The diff coverage is 93.33%.

@@            Coverage Diff             @@
##           master      #12      +/-   ##
==========================================
+ Coverage   79.78%   81.10%   +1.32%     
==========================================
  Files          38       40       +2     
  Lines        1385     1535     +150     
==========================================
+ Hits         1105     1245     +140     
- Misses        280      290      +10     
Impacted Files Coverage Δ
src/config/broker_config.cpp 57.53% <0.00%> (-3.34%) ⬇️
src/config/broker_config.h 100.00% <ø> (ø)
src/queuing/queue_manager_interface.h 100.00% <ø> (ø)
src/queuing/single_queue_manager.h 90.76% <90.76%> (ø)
tests/single_queue_manager.cpp 100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@krulis-martin krulis-martin merged commit f9710b5 into master Nov 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants