#2581 Re-check memcache after acquiring the lock in the client code
Closed: Fixed None Opened 4 years ago by jhrozek.

Since the application requesting data from the NSS client might be milti-threaded (and in the case of slapi-nis, it often is), we sometimes run into a race condition in the client libraries. It might happen that a thread checks the memcache, finds no data is there, waits for the mutex. By the time the mutex is acquired, some other thread already resolved the same data this thread is waiting on. In this case, it might benefit the performance to re-check the memcache.


Fields changed

owner: somebody => lslebodn

Fields changed

type: enhancement => defect

I don't think it is a defect.

This ticket might help only in case when more threads want to obtain information about the same user/group. it would be good to measure performance speed up whether it will help in real deployment. otherwise it would be just premature optimisation.

BTW: Patch should be very small.

Internal, not really testable change, it should not be cloned.

rhbz: => 0

Required for downstream, but not for Beta

milestone: SSSD 1.13 beta => SSSD 1.13
sensitive: => 0

btw Alexander said this is needed for the server mode sssd, so I'm bumping priority

priority: major => critical

Fields changed

patch: 0 => 1
status: new => assigned

_comment0: * b08bcc3
88e6860
7c83c23
6d29263
ebf6735 => 1435933971149275
resolution: => fixed
status: assigned => closed

Fields changed

milestone: SSSD 1.13.2 => SSSD 1.13.1

Metadata Update from @jhrozek:
- Issue assigned to lslebodn
- Issue set to the milestone: SSSD 1.13.1

2 years ago

Login to comment on this ticket.

Metadata