389-ds-base

#350 To investigate random length delay in the backend
Closed: wontfix Opened by nhosoi.

Closed: wontfix
Reopen Issue

Backend code has following random length delays in the retry:
PRIntervalTime interval; \
interval = PR_MillisecondsToInterval(slapi_rand() % 100); \
DS_Sleep(interval); \

This may be better to replace with pthread_yield/PR_Sleep(PR_INTERVAL_NO_WAIT).
/
** Make the current thread sleep until "ticks" time amount of time
** has expired. If "ticks" is PR_INTERVAL_NO_WAIT then the call is
** equivalent to calling PR_Yield. Calling PR_Sleep with an argument
** equivalent to PR_INTERVAL_NO_TIMEOUT is an error and will result
** in a PR_FAILURE error return.
/
NSPR_API(PRStatus) PR_Sleep(PRIntervalTime ticks);

set default ticket origin to Community

some sort of delay is necessary to prevent exceeding the deadlock retry count - but random vs. fixed amount vs. just a thread yield?

Added initial screened field value.

this ticket is now open for 3 yrs without pushing to resolve. The benefit of a change is unclear and the backend code is going to be redesigned, so we will not fix this.

Metadata Update from @rmeggins:
- Issue assigned to nhosoi
- Issue set to the milestone: 1.3.4 backlog

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/350

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Invalid)
Metadata
None
None
None
High
QE
0
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.