[jira] [Closed] (COUCHDB-2824) group & group_level view parameters override each

[Nick Vatamaniuc (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COUCHDB-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Vatamaniuc closed COUCHDB-2824.


> group & group_level view parameters override each
> -
>
> Key: COUCHDB-2824
> URL: https://issues.apache.org/jira/browse/COUCHDB-2824
> Project: CouchDB
>  Issue Type: Bug
>  Components: Database Core, HTTP Interface
>Reporter: Nick Vatamaniuc
>Assignee: Nick Vatamaniuc
> Fix For: 2.0.0
>
>
> In a view query, if both group and group_level is specified the last one 
> specified overrides any of the previous "group" or "group_level" parameters.
> Example:
> Create a db (db1), at least one document, a design doc (des1) that looks like:
> {code:javascript}
> {
>"views": { 
>  "v1" : { "map": "function(d){
>  emit([1,1],1); 
>  emit([1,1],10);
>  emit([1,2],100); 
>  emit([1,2],1000); 
>  emit([2,2],1);
>}" , 
>  "reduce":"_sum" 
>  } 
> }
> {code}
> Then these queries show the problem:
> {code}
> $ http "$DB1/db1/_design/des1/_view/v1?group_level=1=true"
> {"rows":[
> {"key":[1,1],"value":11},
> {"key":[1,2],"value":1100},
> {"key":[2,2],"value":1}
> ]}
> {code}
> But users might expect group_level=1 results to show or a 400 request invalid.
> Specifying group_level=1 after group=true make group_level=1 take effect:
> {code}
> $ http "$DB1/db1/_design/des1/_view/v1?group_level=1=true_level=1"
> {"rows":[
> {"key":[1],"value":},
> {"key":[2],"value":1}
> ]}
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (COUCHDB-2831) OS Daemons configuration test is failing when run in isolation

[Nick Vatamaniuc (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COUCHDB-2831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Vatamaniuc closed COUCHDB-2831.


> OS Daemons configuration test is failing when run in isolation
> --
>
> Key: COUCHDB-2831
> URL: https://issues.apache.org/jira/browse/COUCHDB-2831
> Project: CouchDB
>  Issue Type: Bug
>Reporter: Nick Vatamaniuc
>
> It seems to work when run as part of the whole test suite. When run on its 
> won it fails.
> ... apps=couch tests=configuration_reader_test_,
> {code}
> [error] Ignoring OS daemon request: {error,{1,invalid_json}}
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (COUCHDB-2815) POST to /{db}/_all_docs with invalid keys should return a 400 error instead of 500

[Nick Vatamaniuc (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COUCHDB-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Vatamaniuc closed COUCHDB-2815.


> POST to /{db}/_all_docs with invalid keys should return a 400 error instead 
> of 500
> --
>
> Key: COUCHDB-2815
> URL: https://issues.apache.org/jira/browse/COUCHDB-2815
> Project: CouchDB
>  Issue Type: Bug
>  Components: Database Core, HTTP Interface
>Reporter: Nick Vatamaniuc
> Fix For: 2.0.0
>
>
> Related to 
> http://docs.couchdb.org/en/latest/api/database/bulk-api.html#post--db-_all_docs
>  end point.
> Example:
>  *  db1 created with two documents ids : "1" and "2".
> {code}
>  http -a adm:pass POST http://127.0.0.1:15984/db1/_all_docs  keys:='["1",2]'
> HTTP/1.1 500 Internal Server Error
> Cache-Control: must-revalidate
> Content-Length: 43
> Content-Type: application/json
> Date: Wed, 16 Sep 2015 18:25:08 GMT
> Server: CouchDB/b8b9968 (Erlang OTP/17)
> X-Couch-Request-ID: 898d97fc1f
> X-CouchDB-Body-Time: 0
> {
> "error": "2",
> "reason": "{illegal_docid,2}"
> }
> {code}
> Expected 400 error instead as there is nothing wrong with on the server.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (COUCHDB-2818) Design documents accept invalid views

[Nick Vatamaniuc (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COUCHDB-2818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Vatamaniuc closed COUCHDB-2818.


> Design documents accept invalid views
> -
>
> Key: COUCHDB-2818
> URL: https://issues.apache.org/jira/browse/COUCHDB-2818
> Project: CouchDB
>  Issue Type: Bug
>  Components: Database Core, Documentation, JavaScript View Server
>Reporter: Nick Vatamaniuc
>Assignee: Nick Vatamaniuc
> Fix For: 2.0.0
>
>
> Design documents seem to accept invalid views. 
> For example:
> {code}
> $ http PUT $DB1/db2/_design/des1 views:='{ "v1" : 
> "function(d){emit(d._id,d);}" }'
> HTTP/1.1 201 Created
> {
> "id": "_design/des1",
> "ok": true,
> "rev": "1-04701f13eb827265c442d219bd995e91"
> }
> {code}
> Going by the documentation for design documents: 
> http://docs.couchdb.org/en/latest/api/ddoc/common.html#put--db-_design-ddoc , 
> a view should be an object that has a map (a string) and an optional reduce 
> (string).  
> Interestingly some validation is performed to check that views field itself 
> is an object.  For example:
> {code}
> $ http PUT $DB1/db2/_design/des1 views:='"x"'
> HTTP/1.1 400 Bad Request
> {
> "error": "invalid_design_doc",
> "reason": "`views` parameter must be an object."
> }
> {code}
> Also there is a deeper level validation of map functions:
> {code}
> $  http PUT $DB1/db2/_design/des1 views:='{ "m":{"map":""} }'
> {
> "error": "not_found",
> "reason": "missing function"
> }
> {code}
> If there is interest, I have a patch that, if provided: views, filters, 
> lists, show, updates, options are objects. rewrites are arrays, 
> validate_doc_update and language are strings.
> Then if views is provided, each view is an object. It must have a map 
> function (a string) and an optional reduce function (also a string).
> Here is an example how it works:
> {code}
> $ http PUT $DB1/db2/_design/des1 views:='{ "m":"bad"  }'
> HTTP/1.1 400 Bad Request
> {
> "error": "invalid_design_doc",
> "reason": "View m must be an object"
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (COUCHDB-2848) EUnit Tests Fail Intermetently

[Nick Vatamaniuc (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COUCHDB-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Vatamaniuc closed COUCHDB-2848.


> EUnit Tests Fail Intermetently
> --
>
> Key: COUCHDB-2848
> URL: https://issues.apache.org/jira/browse/COUCHDB-2848
> Project: CouchDB
>  Issue Type: Bug
>Reporter: Nick Vatamaniuc
> Fix For: 2.0.0
>
>
> Use this for now to keep track of them



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (COUCHDB-2954) Deprecate configurable _replicator db name in 2.0

[Nick Vatamaniuc (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COUCHDB-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Vatamaniuc closed COUCHDB-2954.


> Deprecate configurable _replicator db name in 2.0
> -
>
> Key: COUCHDB-2954
> URL: https://issues.apache.org/jira/browse/COUCHDB-2954
> Project: CouchDB
>  Issue Type: Improvement
>Reporter: Nick Vatamaniuc
>
> CouchDB 1.x has a configurable replicator database name. 
> CouchDB 2.x uses another pattern for having custom replicator databases -- it 
> scans files in local database data directory for patterns matching {code} 
> "_replicator(\\.[0-9]{10,})?.couch$" {code}. So for example, can create a 
> database called {{"joe/_replicator"}} and it will be considered a replicator 
> database by the replication management code. This way can even have multiple 
> replicator databases ( {{"mike/_replicator"}}, or {{"joe/other/_replicator"}} 
> ), so configuration is even more flexible than it was in 1.x.
> Current code in couch_replicator_manager.erl is a mix of using the 1.x config 
> option and scanning recursively for db files with _replicator pattern. It 
> already also assumes a hard-coded "_replicator" name in a few places:
> https://github.com/apache/couchdb-couch-replicator/blob/master/src/couch_replicator_manager.erl#L918
> The proposal it to deprecate _replicator db name configuration in order to 
> simplify and clean up the the code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (COUCHDB-2832) Task status test setup fails

[Nick Vatamaniuc (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COUCHDB-2832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Vatamaniuc closed COUCHDB-2832.


> Task status test setup fails
> 
>
> Key: COUCHDB-2832
> URL: https://issues.apache.org/jira/browse/COUCHDB-2832
> Project: CouchDB
>  Issue Type: Bug
>Reporter: Nick Vatamaniuc
>
> Unit test couch_task_status_tests fails 
> {code}
> $ reunit apps=couch tests=couch_task_status_test_
> ==> couch_log (eunit)
> Running test function(s):
>  EUnit 
>   There were no tests to run.
> ==> couch (eunit)
> Compiled test/couch_doc_json_tests.erl
> Compiled test/couchdb_os_daemons_tests.erl
> Running test function(s):
>   couch_task_status_tests:couch_task_status_test_/0
>  EUnit 
> CouchDB task status updates
>   couch_task_status_tests:58: should_register_task...ok
>   couch_task_status_tests:62: should_set_task_startup_time...[0.002 s] ok
>   couch_task_status_tests:67: 
> should_have_update_time_as_startup_before_any_progress...ok
>   couch_task_status_tests:71: should_set_task_type...ok
>   couch_task_status_tests:75: 
> should_not_register_multiple_tasks_for_same_pid...ok
>   couch_task_status_tests:80: should_set_task_progress...ok
>   couch_task_status_tests:85: should_update_task_progress...*skipped*
> undefined
> *unexpected termination of test process*
> ::{{badmatch,undefined},
>[{couch_log,debug,2,[{file,"src/couch_log.erl"},{line,32}]},
> {couch_task_status,handle_cast,2,
>[{file,"src/couch_task_status.erl"},{line,137}]},
> {gen_server,try_dispatch,4,[{file,"gen_server.erl"},{line,593}]},
> {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,659}]},
> {proc_lib,init_p_do_apply,3,[{file,[...]},{line,...}]}]}
> ===
>   Failed: 0.  Skipped: 0.  Passed: 6.
> One or more tests were cancelled.
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (COUCHDB-2963) Replication manager does not rescan databases on cluster membership change

[Nick Vatamaniuc (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COUCHDB-2963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Vatamaniuc closed COUCHDB-2963.


> Replication manager does not rescan databases on cluster membership change
> --
>
> Key: COUCHDB-2963
> URL: https://issues.apache.org/jira/browse/COUCHDB-2963
> Project: CouchDB
>  Issue Type: Bug
>Reporter: Nick Vatamaniuc
>Assignee: Nick Vatamaniuc
> Fix For: 2.0.0
>
>
> Replication manager should rescan all replicator databases on cluster 
> membership changes from sequence 0, in order to possibly pick up new 
> replication it might be an owner of.
> On receipt of nodedown or nodeup message, replication manager attempts to 
> start a new scan by resetting the checkpointed sequence IDs ets table. With 
> the intent that change feeds will exit and then check if they need to rescan 
> again. However because change feeds used for the replicator databases are 
> "continuous" they never exit, so consequently they never get a chance start 
> rescanning from 0.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (COUCHDB-2959) Deadlock condition in replicator with remote source and configured 1 http connection

[Nick Vatamaniuc (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COUCHDB-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Vatamaniuc closed COUCHDB-2959.


> Deadlock condition in replicator with remote source and configured 1 http 
> connection
> 
>
> Key: COUCHDB-2959
> URL: https://issues.apache.org/jira/browse/COUCHDB-2959
> Project: CouchDB
>  Issue Type: Bug
>  Components: Replication
>Reporter: Nick Vatamaniuc
> Attachments: rep.py
>
>
> A deadlock that occurs that can get the starting replications to get stuck 
> (and never update their state to triggered). This happens with a remote 
> source and when using a single http connection and single worker.
>  The deadlock occurs in this case:
>  - Replication process starts, it starts the changes reader: 
> https://github.com/apache/couchdb-couch-replicator/blob/master/src/couch_replicator.erl#L276
>  - Changes reader consumes the worker from httpc pool. At some point it will 
> make a call back to the replication process to report how much work it has 
> done using gen_server call {{report_seq_done}}
>  - In the meantime, main replication process calls {{get_pending_changes}} to 
> get changes from the source. If the source is remote it will attempt to 
> consumer a worker from httpc pool. However the worker is used by the change 
> feed process. So get_pending_changes is blocked waiting for a worker to be 
> released.
>  - So changes feed is waiting for report_seq_done call to replication process 
> to return while holding a worker and main replication process is waiting for 
> httpc pool to release the worker and it never responds to report_seq_done.
> Attached python script (rep.py) to reproduce issue. Script creates n 
> databases (tested with n=1000). Then replicates those databases to 1 single 
> database. It also need Python CouchDB module from pip (or package repos).
> 1. It an can be run from ipython. By importing {{rep}}. 
> 2. start dev cluster {{./dev/run --admin=adm:pass}}
> 3. {{rep.replicate_1_to_n(1000)}}
> wait
> 4. {{rep.check_untriggered()}}
> When it fails, result might look like this:
> {code}
> {
>  'rdyno_1_6': None,
>  'rdyno_1_00158': None
> }
> {code}
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (COUCHDB-2959) Deadlock condition in replicator with remote source and configured 1 http connection

[Nick Vatamaniuc (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COUCHDB-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Vatamaniuc resolved COUCHDB-2959.
--
Resolution: Fixed

> Deadlock condition in replicator with remote source and configured 1 http 
> connection
> 
>
> Key: COUCHDB-2959
> URL: https://issues.apache.org/jira/browse/COUCHDB-2959
> Project: CouchDB
>  Issue Type: Bug
>  Components: Replication
>Reporter: Nick Vatamaniuc
> Attachments: rep.py
>
>
> A deadlock that occurs that can get the starting replications to get stuck 
> (and never update their state to triggered). This happens with a remote 
> source and when using a single http connection and single worker.
>  The deadlock occurs in this case:
>  - Replication process starts, it starts the changes reader: 
> https://github.com/apache/couchdb-couch-replicator/blob/master/src/couch_replicator.erl#L276
>  - Changes reader consumes the worker from httpc pool. At some point it will 
> make a call back to the replication process to report how much work it has 
> done using gen_server call {{report_seq_done}}
>  - In the meantime, main replication process calls {{get_pending_changes}} to 
> get changes from the source. If the source is remote it will attempt to 
> consumer a worker from httpc pool. However the worker is used by the change 
> feed process. So get_pending_changes is blocked waiting for a worker to be 
> released.
>  - So changes feed is waiting for report_seq_done call to replication process 
> to return while holding a worker and main replication process is waiting for 
> httpc pool to release the worker and it never responds to report_seq_done.
> Attached python script (rep.py) to reproduce issue. Script creates n 
> databases (tested with n=1000). Then replicates those databases to 1 single 
> database. It also need Python CouchDB module from pip (or package repos).
> 1. It an can be run from ipython. By importing {{rep}}. 
> 2. start dev cluster {{./dev/run --admin=adm:pass}}
> 3. {{rep.replicate_1_to_n(1000)}}
> wait
> 4. {{rep.check_untriggered()}}
> When it fails, result might look like this:
> {code}
> {
>  'rdyno_1_6': None,
>  'rdyno_1_00158': None
> }
> {code}
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (COUCHDB-2954) Deprecate configurable _replicator db name in 2.0

[Nick Vatamaniuc (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COUCHDB-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Vatamaniuc resolved COUCHDB-2954.
--
Resolution: Fixed

> Deprecate configurable _replicator db name in 2.0
> -
>
> Key: COUCHDB-2954
> URL: https://issues.apache.org/jira/browse/COUCHDB-2954
> Project: CouchDB
>  Issue Type: Improvement
>Reporter: Nick Vatamaniuc
>
> CouchDB 1.x has a configurable replicator database name. 
> CouchDB 2.x uses another pattern for having custom replicator databases -- it 
> scans files in local database data directory for patterns matching {code} 
> "_replicator(\\.[0-9]{10,})?.couch$" {code}. So for example, can create a 
> database called {{"joe/_replicator"}} and it will be considered a replicator 
> database by the replication management code. This way can even have multiple 
> replicator databases ( {{"mike/_replicator"}}, or {{"joe/other/_replicator"}} 
> ), so configuration is even more flexible than it was in 1.x.
> Current code in couch_replicator_manager.erl is a mix of using the 1.x config 
> option and scanning recursively for db files with _replicator pattern. It 
> already also assumes a hard-coded "_replicator" name in a few places:
> https://github.com/apache/couchdb-couch-replicator/blob/master/src/couch_replicator_manager.erl#L918
> The proposal it to deprecate _replicator db name configuration in order to 
> simplify and clean up the the code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (COUCHDB-2988) Allow query selector as changes and replication filter

[Nick Vatamaniuc (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COUCHDB-2988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Vatamaniuc resolved COUCHDB-2988.
--
Resolution: Fixed

> Allow query selector as changes and replication filter
> --
>
> Key: COUCHDB-2988
> URL: https://issues.apache.org/jira/browse/COUCHDB-2988
> Project: CouchDB
>  Issue Type: Improvement
>  Components: Database Core, Mango
>Reporter: Nick Vatamaniuc
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (COUCHDB-2979) Replicator manager attempts to checkpoint too frequently

[Nick Vatamaniuc (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COUCHDB-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Vatamaniuc closed COUCHDB-2979.


> Replicator manager attempts to checkpoint too frequently
> 
>
> Key: COUCHDB-2979
> URL: https://issues.apache.org/jira/browse/COUCHDB-2979
> Project: CouchDB
>  Issue Type: Bug
>Reporter: Nick Vatamaniuc
>
> Current checkpoint interval is set to 5 seconds. That works well for a few 
> replications but when there are thousands of them it ends up being an attempt 
> every few milliseconds or so.
> Moreover to decide on ownership (in order to keep on replication running per 
> cluster) each replication during an attempted checkpoint uses a gen_server 
> call to replicator manager. Those usually are fast (I bench-marked at a 
> 100-200 usec) however if replicator manager is busy (say stuck fetching large 
> filter documents when computing replication ids), none of the replication 
> would be able to checkpoint and make progress.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (COUCHDB-2988) Allow query selector as changes and replication filter

[Nick Vatamaniuc (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COUCHDB-2988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Vatamaniuc closed COUCHDB-2988.


> Allow query selector as changes and replication filter
> --
>
> Key: COUCHDB-2988
> URL: https://issues.apache.org/jira/browse/COUCHDB-2988
> Project: CouchDB
>  Issue Type: Improvement
>  Components: Database Core, Mango
>Reporter: Nick Vatamaniuc
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (COUCHDB-3006) Source failure in one source to many target replications causes a stampede

[Nick Vatamaniuc (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COUCHDB-3006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Vatamaniuc closed COUCHDB-3006.


> Source failure in one source to many target replications causes a stampede
> --
>
> Key: COUCHDB-3006
> URL: https://issues.apache.org/jira/browse/COUCHDB-3006
> Project: CouchDB
>  Issue Type: Bug
>Reporter: Nick Vatamaniuc
>
> For multiple replications from a single source to multiple targets. If source 
> fails, all replications post an error state back their replication document 
> and attempt to restart. This creates a stampede effect and causes sharp load 
> spikes on the replication cluster.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (COUCHDB-3039) Inconsistent behavior with with _all_docs handling of null keys between CouchDB 1.x and 2.x

[Nick Vatamaniuc (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COUCHDB-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Vatamaniuc resolved COUCHDB-3039.
--
Resolution: Fixed

> Inconsistent behavior with with _all_docs handling of null keys between 
> CouchDB 1.x and 2.x
> ---
>
> Key: COUCHDB-3039
> URL: https://issues.apache.org/jira/browse/COUCHDB-3039
> Project: CouchDB
>  Issue Type: Bug
>Reporter: Nick Vatamaniuc
>
> CouchDB in a POST request to _all_docs where key is null will return an error 
> row:
> {code}
>  {
>"total_rows": 14970916,
>"offset": 0,
>"rows": [
>   {
>  "key": null,
>  "error": "not_found"
>   },
>   ... other valid rows ...
> ]
> }
> {code}
> CouchDB 2.0 will return a 400 error
> {code}
> HTTP/1.1 400 Bad Request
> {
> "error": "illegal_docid",
> "reason": null
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (COUCHDB-3082) Replicator manager crashes in terminate/2 if initial change feed spawned for _replicate hasn't finished

[Nick Vatamaniuc (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COUCHDB-3082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Vatamaniuc closed COUCHDB-3082.


> Replicator manager crashes in terminate/2 if initial change feed spawned for 
> _replicate hasn't finished
> ---
>
> Key: COUCHDB-3082
> URL: https://issues.apache.org/jira/browse/COUCHDB-3082
> Project: CouchDB
>  Issue Type: Bug
>Reporter: Nick Vatamaniuc
>
> During init we spawn a change feed for the _replicator db and assign 
> rep_start_pids = [Pid]. However the shape of rep_start_pids should be {Tag, 
> Pid}. In terminate/2 we clean up by doing:
> {code}
> lists:foreach(
> fun({_Tag, Pid}) ->
> ...
> [{scanner, ScanPid} | StartPids]),
> {code}
>  
> Which ends up crashing with a function clause because we expect foreach 
> function to get a tuple of 2 items.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COUCHDB-2980) Replicator DB on 15984 replicates to backdoor ports

[Nick Vatamaniuc (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-2980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15405193#comment-15405193
 ] 

Nick Vatamaniuc commented on COUCHDB-2980:
--

[~chrisfosterelli] Interesting points.

Thinking more about this, it seems it is hard to for a node in a cluster to 
know the host of the cluster in general. Say a cluster is behind a proxy for 
fault tollerance, after the document is added to a replicator db, can't see how 
it would know what the external cluster host would be say database {{a}} means 
"https://user:p...@mycluster.com/a; or 
"http://user:p...@user.somecluster.net/a; for example. In case of {

> Replicator DB on 15984 replicates to backdoor ports
> ---
>
> Key: COUCHDB-2980
> URL: https://issues.apache.org/jira/browse/COUCHDB-2980
> Project: CouchDB
>  Issue Type: Bug
>  Components: Replication
>Affects Versions: 2.0.0
>Reporter: Robert Kowalski
>Priority: Blocker
>
> If you POST a doc into the replicator database a replication is kicked off 
> and finishes successfully (usual 5984 port which maps to 15984 via haproxy).
> The problem is that the DB is replicated to the backdoor ports (15986) and is 
> not visible on the other ports.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] couchdb issue #435: Change default to log to a file, not stderr

[kxepal]

Github user kxepal commented on the issue:

https://github.com/apache/couchdb/pull/435
  
Why not to keep default stderr, while allow to provide a path to logfile on 
configure? This will satisfy both groups needs. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (COUCHDB-3090) Error when handling empty "Access-Control-Request-Headers" header

[Nolan Lawson (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-3090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15404866#comment-15404866
 ] 

Nolan Lawson commented on COUCHDB-3090:
---

I've filed an issue on Chromium: 
https://bugs.chromium.org/p/chromium/issues/detail?id=633729

> Error when handling empty "Access-Control-Request-Headers" header
> -
>
> Key: COUCHDB-3090
> URL: https://issues.apache.org/jira/browse/COUCHDB-3090
> Project: CouchDB
>  Issue Type: Bug
>  Components: HTTP Interface
>Reporter: Will Holley
>
> Sending an empty  "Access-Control-Request-Headers" header as part of a 
> pre-flight request (as opposed to excluding it) causes CouchDB to respond 
> with a 405 Method Not Allowed:
> With the header excluded:
> {code}
> $ curl 'http://localhost:15984/_session' -H "Access-Control-Request-Headers:" 
> -H "Access-Control-Request-Method: POST" -H "Origin:https://something.com; 
> -XOPTIONS -v
> Mon  1 Aug 2016 13:48:26 BST
> *   Trying ::1...
> * connect to ::1 port 15984 failed: Connection refused
> *   Trying 127.0.0.1...
> * Connected to localhost (127.0.0.1) port 15984 (#0)
> > OPTIONS /_session HTTP/1.1
> > Host: localhost:15984
> > User-Agent: curl/7.43.0
> > Accept: */*
> > Access-Control-Request-Method: POST
> > Origin:https://something.com
> > 
> < HTTP/1.1 204 No Content
> < Access-Control-Allow-Credentials: true
> < Access-Control-Allow-Headers: 
> < Access-Control-Allow-Methods: GET, PUT, POST, HEAD, DELETE
> < Access-Control-Allow-Origin: https://something.com
> < Access-Control-Max-Age: 600
> < Content-Length: 0
> < Date: Mon, 01 Aug 2016 12:48:25 GMT
> < Server: CouchDB/b49d069 (Erlang OTP/18)
> < X-Couch-Request-ID: c68c601375
> < X-CouchDB-Body-Time: 0
> < 
> * Connection #0 to host localhost left intact
> {code}
> With an empty header:
> {code}
> $ curl 'http://localhost:15984/_session' -H "Access-Control-Request-Headers;" 
> -H "Access-Control-Request-Method: POST" -H "Origin:https://something.com; 
> -XOPTIONS -v
> Mon  1 Aug 2016 13:48:21 BST
> *   Trying ::1...
> * connect to ::1 port 15984 failed: Connection refused
> *   Trying fe80::1...
> * connect to fe80::1 port 15984 failed: Connection refused
> *   Trying 127.0.0.1...
> * Connected to localhost (127.0.0.1) port 15984 (#0)
> > OPTIONS /_session HTTP/1.1
> > Host: localhost:15984
> > User-Agent: curl/7.43.0
> > Accept: */*
> > Access-Control-Request-Headers:
> > Access-Control-Request-Method: POST
> > Origin:https://something.com
> > 
> < HTTP/1.1 405 Method Not Allowed
> < Access-Control-Allow-Credentials: true
> < Access-Control-Allow-Origin: https://something.com
> < Access-Control-Expose-Headers: content-type, cache-control, accept-ranges, 
> etag, server, x-couch-request-id, x-couch-update-newrev, x-couchdb-body-time
> < Allow: GET,HEAD,POST,DELETE
> < Cache-Control: must-revalidate
> < Content-Length: 76
> < Content-Type: application/json
> < Date: Mon, 01 Aug 2016 12:48:21 GMT
> < Server: CouchDB/b49d069 (Erlang OTP/18)
> < 
> {"error":"method_not_allowed","reason":"Only GET,HEAD,POST,DELETE allowed"}
> * Connection #0 to host localhost left intact
> {code}
> A recent release of Chrome (52) has resulted in the browser sending this 
> empty header instead of excluding it, resulting in CORS breaking against 
> CouchDB (both 1.6 and 2.0/master) - see 
> https://github.com/nolanlawson/pouchdb-authentication/issues/111



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] couchdb issue #435: Change default to log to a file, not stderr

[wohali]

Github user wohali commented on the issue:

https://github.com/apache/couchdb/pull/435
  
I have since learned that it is increasingly common for services like 
systemd to gather and manage log files on its own. As such this change may be 
unpopular given modern trends in UNIX. I'm hoping to gather more feedback on 
the approach before making a merge/no-merge decision here.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] couchdb pull request #435: Change default to log to a file, not stderr

[wohali]

GitHub user wohali opened a pull request:

https://github.com/apache/couchdb/pull/435

Change default to log to a file, not stderr

Presently our default is to log only to stderr. This is both a deviation
from couchdb 1.x behaviour as well as unexpected for a service of
couchdb's stature. This PR defaults output in the 'make release' to
./var/log/couchdb.log.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/couchdb log-file-by-default

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/couchdb/pull/435.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #435


commit 46824041c4d0fdfe6917e0819d26eef2ae2846e8
Author: Joan Touzet 
Date:   2016-08-02T19:25:48Z

Change default to log to a file, not stderr




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---