Introduced retries for timeout on do_associatons
do_introspect already has retry mechanism in place for busy workloads
at early stages of system boot. This change introduces exactly the same
handling for next step of ObjectMapper flow - getting Associations.
During performance tests with spawning multiple sensors I was able to
observe errors due to timeouted do_associations call.
Copying retry behavior from do_introspect allowed me to spawn
successfully 4000 sensors in the system (1500 without this change).
Signed-off-by: Adrian Ambrożewicz <adrian.ambrozewicz@intel.com>
Change-Id: I2c6c8b8b6b96186e0f49cf8b91c185a9c928c337
diff --git a/src/main.cpp b/src/main.cpp
index 5bbb0a3..4937057 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -131,14 +131,24 @@
void do_associations(sdbusplus::asio::connection* system_bus,
interface_map_type& interfaceMap,
sdbusplus::asio::object_server& objectServer,
- const std::string& processName, const std::string& path)
+ const std::string& processName, const std::string& path,
+ int timeoutRetries = 0)
{
+ constexpr int maxTimeoutRetries = 3;
system_bus->async_method_call(
- [&objectServer, path, processName, &interfaceMap](
+ [&objectServer, path, processName, &interfaceMap, system_bus,
+ timeoutRetries](
const boost::system::error_code ec,
const std::variant<std::vector<Association>>& variantAssociations) {
if (ec)
{
+ if (ec.value() == boost::system::errc::timed_out &&
+ timeoutRetries < maxTimeoutRetries)
+ {
+ do_associations(system_bus, interfaceMap, objectServer,
+ processName, path, timeoutRetries + 1);
+ return;
+ }
std::cerr << "Error getting associations from " << path << "\n";
}
std::vector<Association> associations =