ensure we decrement clients_requesting_changes

[rnewson]

Overview

ensure we decrement clients_requesting_changes even if the mochiweb process mediating the change request is killed by the client disconnect detector.

Testing recommendations

follow procedure in #5802

Related Issues or Pull Requests

#5802

Checklist

• Code is written and works correctly
• Changes are covered by tests
• Any new configurable parameters are documented in rel/overlay/etc/default.ini
• Documentation changes were made in the src/docs folder
• Documentation changes were backported (separated PR) to affected branches

[nickva]

Wonder if we can just re-use the cleanup process and have a streaming cleanup process (which is already spawn for each streaming request) do the decrementing:

couchdb/src/chttpd/src/chttpd_util.erl

Line 163 in 290314a

couch_stats:increment_counter([couchdb, httpd, abandoned_streaming_requests]),

And instead of having a dedicated changes clients we could have a streaming clients metric?

[rnewson]

continuous changes req is the only request that could in theory never end, whereas all the others do, so there's not as strong a need to count them in-flight (and, if those, why not everything?) but I don't feel that strongly against (or for).

[nickva]

continuous changes req is the only request that could in theory never end, whereas all the others do, so there's not as strong a need to count them in-flight (and, if those, why not everything?) but I don't feel that strongly against (or for).

yeah that makes sense, good point