Description
Backport from CBL-5033 (Berrylium)
Pull uses a counter, _activeIncomingRevs, to count the number of active workers that are handling incoming revs concurrently. The current cap is 100. When more messages arrive, we put them in a queue, where they will be processed when _activeIncomingRevs drops below the limit (100).
There is a case where the _activeIncomingRevs grows thousands, (40,000+) and the document updates are not being handled properly. The reason is that there is a lots of purge revs, and any purge revs do not wait in the queue behind other revs, instead they are handled instantly, but they still increase _activeIncomingRevs count, so other (non-purge) revs are waiting for the count to drop below 100.
This could be by design, so access revocation is instant? If not, purge revs should wait in the queue with other revs
Attachments
Issue Links
- Clones
-
CBL-5033 Puller revoked docs should queue with other revs
- Closed