Closed Yuval-Ariel closed 9 months ago
@Yuval-Ariel - Why not avoid logging in the WC to the reporter's logger? This would achieve what this PR is for as well as have a single log record (instead of 2) in the reporter's log.
@Yuval-Ariel - Why not avoid logging in the WC to the reporter's logger? This would achieve what this PR is for as well as have a single log record (instead of 2) in the reporter's log.
@udi-speedb , what you're suggesting wouldnt work when a logger is shared between two dbs. the db that initated the request will get a msg but the other one wouldnt.
@Yuval-Ariel - Why not avoid logging in the WC to the reporter's logger? This would achieve what this PR is for as well as have a single log record (instead of 2) in the reporter's log.
@udi-speedb , what you're suggesting wouldnt work when a logger is shared between two dbs. the db that initated the request will get a msg but the other one wouldnt.
Wouldn't the reporter get a log message from its own column_family.cc code while the other(s) would log the WC's message?
@Yuval-Ariel - Why not avoid logging in the WC to the reporter's logger? This would achieve what this PR is for as well as have a single log record (instead of 2) in the reporter's log.
@udi-speedb , what you're suggesting wouldnt work when a logger is shared between two dbs. the db that initated the request will get a msg but the other one wouldnt.
Wouldn't the reporter get a log message from its own column_family.cc code while the other(s) would log the WC's message?
its the same logger. so both dbs will get any msg
OK, but if there are multiple delay sources (cf-s, WBM) wouldn't you miss the min rate and only see the new rate?
OK, but if there are multiple delay sources (cf-s, WBM) wouldn't you miss the min rate and only see the new rate?
we would still get the msg from the cf that initiated the delay
The WC currently reports to the log whenever a new delay request is handled (even if its the same rate). These msgs are redundant in cases where the WC is only shared with 1 db and hence 1 logger since similar msgs are reported in ColumnFamilyData::RecalculateWriteStallConditions.
Currently it looks like :
This PR removes the msg from the write_controller (the first) when there is only 1 logger to report to.