osaf/services/saf/immsv/immloadd/imm_loader.cc | 21 ++++++++++++++------- 1 files changed, 14 insertions(+), 7 deletions(-)
The sync retry time was changed from 150msec to the huge value of 2 seconds in ticket #851 (OpenSAF 4.5). This large value may have been apropriate for optimizing some variant of sync (?) but it is not optimal in general. The retry time is reverted back to milliseconds level, but with the value increased with each retry up to a max retry time of 0.5 seconds. diff --git a/osaf/services/saf/immsv/immloadd/imm_loader.cc b/osaf/services/saf/immsv/immloadd/imm_loader.cc --- a/osaf/services/saf/immsv/immloadd/imm_loader.cc +++ b/osaf/services/saf/immsv/immloadd/imm_loader.cc @@ -2516,17 +2516,24 @@ int syncObjectsOfClass(std::string class while (err == SA_AIS_OK) { int retries = 0; + useconds_t usec = 10000; do { if(retries) { - /* If we receive TRY_AGAIN while sync in progress means - IMMD might have been reached IMMSV_DEFAULT_FEVS_MAX_PENDING fevs_replies_pending. - In general fevs_replies_pending will be hit in the case of the messages have accumulated in the sender queue - (The most possible reason will be receiver disconnected but the sender link is in TIPC link tolerance of 1.5 sec) - So give enough time to recover as if sync is not a priority messages and possibility of hitting this case because of multicast messaging. - */ - sleep(2); + /* TRY_AGAIN while sync is in progress means *this* IMMND most likely has reached IMMSV_DEFAULT_FEVS_MAX_PENDING. + This means that *this* IMMND has sent its quota of fevs messages to IMMD without having received them back via + broadcast from IMMD. + + Thus fevs_replies_pending will be hit in the case of the messages accumulating either in local send queues + at the MDS/TIPC/TCP level; OR at the IMMDs receivingg queue; OR at this IMMNDs MDS/TIPC_/TCP receiving + queue (when the fevs message comes back). The most likely case is the IMMD receive buffers. + + IMMD is in general the fevs bottleneck in the system. This since it is one process serving an open ended number + of IMMND clients. The larger the cluster the higher the risk of hitting fevs_max_pending at IMMNDs. + */ + usleep(usec); + if(usec < 500000) { usec = usec*2; } /* Increase wait time exponentially up to 0.5 seconds */ } /* Synchronous for throttling sync */ err = saImmOmSearchNext_2(searchHandle, &objectName, &attributes); ------------------------------------------------------------------------------ _______________________________________________ Opensaf-devel mailing list Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-devel