[ https://issues.apache.org/jira/browse/COUCHDB-3133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Newson resolved COUCHDB-3133. ------------------------------------ Resolution: Not A Problem This is by design. In the clustered case we need to wait for the shards to respond before we can know if we're even going to send a 200 OK instead of some error. The reason 1.x can do this immediately is simply because it's much faster, there's a single and already open local file descriptor to talk to. > Continuous change response header is sent late > ---------------------------------------------- > > Key: COUCHDB-3133 > URL: https://issues.apache.org/jira/browse/COUCHDB-3133 > Project: CouchDB > Issue Type: Bug > Components: HTTP Interface > Affects Versions: 2.0.0 > Reporter: Samuel Tardieu > > In CouchDB 1.x, when connecting to the continuous change stream, the "200 OK" > was sent as soon as the connection was established. > This was very useful when using a connection pool to ensure, for example, > that all the "_changes" stream were established before starting manipulating > the database, so that we would be notified of any interesting event happening. > However, in CouchDB 2.0.0-RC4 the "200 OK" is sent only after the first > change is available. More precisely, when using a filter, it is sent after > the first time the filter is invoked, be it successful or not. > This prevents a client from knowing whether it is indeed connected to the > changes stream or not yet. This is a functional regression against 1.x. -- This message was sent by Atlassian JIRA (v6.3.4#6332)