-
Notifications
You must be signed in to change notification settings - Fork 428
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
Handle accumulated affiliations efficiently #3738
Conversation
This comment was marked as off-topic.
This comment was marked as off-topic.
Codecov Report
@@ Coverage Diff @@
## master #3738 +/- ##
==========================================
+ Coverage 82.59% 82.68% +0.08%
==========================================
Files 529 529
Lines 33945 33947 +2
==========================================
+ Hits 28037 28068 +31
+ Misses 5908 5879 -29
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
Affiliations where stored in the mongoose_acc for atomicity, and performance. If a message processing pipeline in a room starts with certain affiliations at the time of that message, we don't want to have some handlers in the pipeline process the message with certain affs, only to have the affiliations changed concurrently and the next handler, for the same message, be processed with different ones. But the code as currently written was quite redundant. The main call to get the affiliations from the accumulator, was running the hook that would check the acc, the cache, and the DB. We can skip that hook if we're already in the context of muc_light and simply check if the affiliations are already in the accumulator, and only if not then we run the hook. Also take the opportunity to tag the affiliations stored in the accumulator, with the room's jid, just to avoid the (though improbable) chance of more than one room's affiliations being accumulated under the same key.
33590dc
to
884ca87
Compare
small_tests_24 / small_tests / 884ca87 small_tests_25 / small_tests / 884ca87 dynamic_domains_pgsql_mnesia_24 / pgsql_mnesia / 884ca87 ldap_mnesia_24 / ldap_mnesia / 884ca87 dynamic_domains_pgsql_mnesia_25 / pgsql_mnesia / 884ca87 ldap_mnesia_25 / ldap_mnesia / 884ca87 dynamic_domains_mysql_redis_25 / mysql_redis / 884ca87 pgsql_mnesia_24 / pgsql_mnesia / 884ca87 dynamic_domains_mssql_mnesia_25 / odbc_mssql_mnesia / 884ca87 internal_mnesia_25 / internal_mnesia / 884ca87 pgsql_mnesia_25 / pgsql_mnesia / 884ca87 elasticsearch_and_cassandra_25 / elasticsearch_and_cassandra_mnesia / 884ca87 mysql_redis_25 / mysql_redis / 884ca87 mssql_mnesia_25 / odbc_mssql_mnesia / 884ca87 riak_mnesia_24 / riak_mnesia / 884ca87 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good 👍
As described in 33590dc
We also take the chance to upgrade the
segmented_cache
library and use its new functionality.