Comments (6)
Seems like it's not possible (at least in easy way) define message limits for all message types in a mbox.
Yes, in the current version of SObjectizer message limits should be specified for a particular messages. Moreover, if an agent defines a message limit for just one message it receives it should also define message limits for all other messages it handles. Otherwise, there will be an error during message subscription.
This limitation can be considered a bit strict. But I think it's better to ask a user to specify limits for all messages (even if a limit will be set to MAX_UINT) than to allow to collect too many messages in the queue because a user forgets about some of the messages.
Also, I should correct you: a limit is set per agent, not per mbox. So there could be a mbox "M" and two agents "A" and "B". Agent "A" set a message limit for a message "Msg" and makes a subscription for "Msg" from "M", but agent "B" doesn't define a limit and can also makes the same subscription. Mbox "M" doesn't store the info about message limits. So if "msg" is sent to "M" then the message limit will be applied to "A", but not to "B".
For now I see only one option: inherit all message types from some class generic_message_t and then define limit_and_X<generic_message_t> (I hope it works).
This approach won't work because message limits and subscriptions are made for a particular message type. If you have a base class "my_message_t" with two derived classes "first_t" and "second_t", and then create a subscription to "my_message_t" then you won't receive messages if they are sent as send<first_t>(...)
and send<second_t>(...)
. The same principle with message limits.
from sobjectizer.
But I think it's better to ask a user to specify limits for all messages (even if a limit will be set to MAX_UINT)
On the one hand, you are right. On the another hand in my case a have a lot of message types, which shall be processed by one agent type. And that's not very convenient to define manually limits for every message types (since now I shall specify limits manually for every message type). If I want to set limit for any message type - allowing setting a limit for all messages without manual work will be fine, since it fixes a problem with "Ah, forgot again to define here a limit for new message and got again runtime error-notification about that".
We can discuss more about usefullness of such feature. FMPOV, it's fine to have such mechanism in SObjectizer, but I cannot guess how difficult is implementation of such feature, performance costs, etc (since I am not a SObjectizer dev :)
Also, I should correct you: a limit is set per agent, not per mbox.
Yeah, sorry. You are completely right.
This approach won't work because message limits and subscriptions are made for a particular message type.
Got it. Thank you.
Hmm... Seems like if I want to set a limit for any message types, message chain is the only built-in approach, right? Unfortunately, message chain doesn't support subscription mechanism (for now I am trying to emulate it with receive
and corresponding handlers for message types).
from sobjectizer.
I had an idea about something like default_message_limit
in the past, but it wasn't implemented because message limits are rarely used and nobody asked for such a feature. Maybe it's time to return to that idea. But I'm afraid there won't be free time for it on this week :(
Seems like if I want to set a limit for any message types, message chain is the only built-in approach, right?
Yes. But mchains allow setting a limit for the total amount of messages regardless of their types. So if you create a mchain with capacity 100 there could be 50 messages of type M1 and 50 messages of type M2. Or 100 messages of type M1, but none of type M2.
message chain doesn't support subscription mechanism
This is a feature I didn't find a way to implement yet. It will be cool to have an ability to subscribe an agent to a mchain and deliver messages from mchain to the usual event handlers of the subscribed agent.
from sobjectizer.
But I'm afraid there won't be free time for it on this week
No problem :) Since there is another way for doing the same thing - it's fine for now.
If you are really not against of such feature - I suggest don't close the issue :) Maybe someday it will be implemented and then you can link PR with required functionality with this issue, so I (and other interested in the feature watchers) will get a notification.
Thank you for the answers.
from sobjectizer.
There you can see how the draft version of "generic message limits" looks like:
sobjectizer/dev/sample/so_5/default_message_limits/main.cpp
Lines 158 to 163 in a48c110
from sobjectizer.
Implemented in v.5.7.1.
More info can be found in the Wiki: https://github.com/Stiffstream/sobjectizer/wiki/v.5.7.1 and https://github.com/Stiffstream/sobjectizer/wiki/SO-5.7-InDepth-Message-Limits
from sobjectizer.
Related Issues (20)
- Asynchrony of register_coop HOT 4
- Documentation for message_holder_t has to be extended HOT 1
- A usage example for agent_t::limit_then_redirect method in API Reference HOT 1
- [Design] Your opinion on expressing agent intent HOT 2
- Deprecation of coop_t::deregister and coop_t::deregister_normally methods HOT 1
- [idea] An emergency stop of SOEnv on an exception in noexcept context HOT 1
- `so_evt_finish` not called until `so_evt_start` is running? HOT 2
- Should agent_t::so_drop_subscription* methods be marked as noexcept? HOT 1
- Should delivery filters be checked for noexcept-ness?
- bind_and_transform HOT 10
- so_5::details::make_message_instance_impl metafunction doesn't set message mutability flag properly HOT 1
- limit_then_transform for mutable messages HOT 1
- Allow `const auto &` as an argument for delivery filter in single/multi_sink_binding HOT 1
- Should there be agent_t::so_disp_binder() and agent_t::so_coop_default_disp_binder() methods? HOT 2
- [idea] Make so5extra's revocable timers the default implementation for timers in SObjectizer
- Another constructor for wrapped_env_t that waits completion of init-function HOT 1
- Use of message limits and state_t::time_limit
- Optional name for an agent? HOT 2
- New method `as_string_view` for so_5::stats::prefix_t and so_5::stats::suffix_t HOT 1
- SO_5_TYPE shouldn't be used for so_5::stats::messages::quantity
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sobjectizer.