(couchdb) branch flush-chttpd-attachment-monitors created (now 1f4e507c7)

[ch...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

chewbranca pushed a change to branch flush-chttpd-attachment-monitors
in repository https://gitbox.apache.org/repos/asf/couchdb.git


      at 1f4e507c7 Flush chttpd_db monitor refs on demonitor

This branch includes the following new commits:

     new 1f4e507c7 Flush chttpd_db monitor refs on demonitor

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.

(couchdb) 01/01: Flush chttpd_db monitor refs on demonitor

[ch...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

chewbranca pushed a commit to branch flush-chttpd-attachment-monitors
in repository https://gitbox.apache.org/repos/asf/couchdb.git

commit 1f4e507c7b70913191477886018183b21128d119
Author: Russell Branca <ch...@apache.org>
AuthorDate: Fri Dec 8 16:19:57 2023 -0800

    Flush chttpd_db monitor refs on demonitor
    
    This ensures that the coordinator process flushes on demonitoring of the
    attachment refs in chttpd_db. The problem here is that it's possible to
    receive a 'DOWN' message for the monitor ref that is not receive'ed,
    causing it to stick around in the coordinator message queue while the
    next http request is handled. The pending message will not become
    apparent until the next fabric call is invoked, as fabric expects to
    have full access to all messages in the calling process, an expectation
    which is violated by the pending message and causes a case clause crash
    in the fabric receive message callbacks.
    
    I noticed this during eunit runs with stubbed attachment handles that
    generate an immediate noproc message on the monitor call. Normal
    operations should not result in an immediate noproc result on monitoring
    the attachment process, however, any failure that causes the attachment
    process to fail between acquisition of the refs and the demonitor calls
    will induce this bug, causing the next http request handled by the
    particular chttpd coordinator pool processs to fail on whatever next
    fabric call is made.
---
 src/chttpd/src/chttpd_db.erl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/chttpd/src/chttpd_db.erl b/src/chttpd/src/chttpd_db.erl
index 9b1aff54f..8cc7a8619 100644
--- a/src/chttpd/src/chttpd_db.erl
+++ b/src/chttpd/src/chttpd_db.erl
@@ -2248,7 +2248,7 @@ monitor_attachments(Att) ->
     monitor_attachments([Att]).
 
 demonitor_refs(Refs) when is_list(Refs) ->
-    [demonitor(Ref) || Ref <- Refs].
+    [demonitor(Ref, [flush]) || Ref <- Refs].
 
 % Return attachments which are not stubs
 non_stubbed_attachments(Atts) when is_list(Atts) ->