[GitHub] couchdb-couch issue #236: Close idle dbs

[nickva]

Github user nickva commented on the issue:

https://github.com/apache/couchdb-couch/pull/236
  
I updated the code to both bump down the open dbs count on close as well as 
remove entries from Lru.  The last bit was shamelessly stolen from Eric.


---
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-couch issue #236: Close idle dbs

[nickva]

Github user nickva commented on the issue:

https://github.com/apache/couchdb-couch/pull/236
  
@eiri Nice find. Thank you. Yap I see when we delete a non-sys_db we forget 
to handle lru properly.


---
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-couch issue #236: Close idle dbs

[eiri]

Github user eiri commented on the issue:

https://github.com/apache/couchdb-couch/pull/236
  
I ran some tests and this approach not working very well. Since 
`close_db_if_idle` removes records from ets, but not from lru, "system" dbs 
pushing "normal" dbs out of ets. Once this process complete and ets exclusively 
consist of "system" records none of the shards on cluster could be open 
anymore. This is happening because in this case in `couch_lru:close_int/2` we 
are always hitting `false` on element update - keys in our lru don't intersect 
with keys in ets anymore - and then `open` always returns `all_dbs_active`, so 
cache ending up locked, since neither `lru` or `max_dbs_open` counter getting 
updated.





---
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-couch pull request #236: Close idle dbs

[nickva]

Github user nickva commented on a diff in the pull request:

https://github.com/apache/couchdb-couch/pull/236#discussion_r105822026
  
--- Diff: src/couch_db_updater.erl ---
@@ -1454,3 +1468,28 @@ default_security_object(_DbName) ->
 "everyone" ->
 []
 end.
+
+% These functions rely on using the process dictionary. This is usually 
frowned upon
+% howver in this case it is done to avoid changing to a different server 
state record
+
+schedule_timeout() ->
+case get(idle_timer_ref) of
+TimerRef when is_reference(TimerRef) ->
+erlang:cancel_timer(TimerRef);
+undefined  ->
+ok
+end,
+put(idle_timer_ref, erlang:send_after(idle_limit(), self(), timeout)).
+
+update_idle_limit_from_config() ->
+Default = integer_to_list(?IDLE_LIMIT_DEFAULT),
+IdleLimit = case config:get("couchdb", "idle_check_timeout", Default) 
of
+"infinity" ->
+infinity;
--- End diff --

Using `hibernate` here would force a hibernation but then it would force it 
more often (on every callback) than before. We did that only after update_docs. 
And the rest was effectively `infinity`.

I'll try to restore the old behavior so on infinity idle_check_timeout we 
hibernate after update_docs only. So we have a way to restore that old mode if 
need be in production.

Also one downside with this simplistic approach with config is that setting 
infinity means not having timeout fire so then config value will not be 
updated. This might involve a change listener or sticking 
update_idle_limit_from_config() call in other places that might be called 
periodically. Is it worth doing that?


---
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-couch pull request #235: Allow limiting maximum document body size

[nickva]

Github user nickva commented on a diff in the pull request:

https://github.com/apache/couchdb-couch/pull/235#discussion_r105816177
  
--- Diff: src/couch_doc.erl ---
@@ -125,7 +125,14 @@ 
doc_to_json_obj(#doc{id=Id,deleted=Del,body=Body,revs={Start, RevIds},
 }.
 
 from_json_obj({Props}) ->
--- End diff --

Hmm good point. It seems like the cleanest place code-wise as we do other 
validations in that function (`throw({doc_validation,...`). Wonder if it makes 
sens to make a validating and non-validation version of the function.


---
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-couch pull request #236: Close idle dbs

[davisp]

Github user davisp commented on a diff in the pull request:

https://github.com/apache/couchdb-couch/pull/236#discussion_r105803925
  
--- Diff: src/couch_db_updater.erl ---
@@ -1454,3 +1468,28 @@ default_security_object(_DbName) ->
 "everyone" ->
 []
 end.
+
+% These functions rely on using the process dictionary. This is usually 
frowned upon
+% howver in this case it is done to avoid changing to a different server 
state record
+
+schedule_timeout() ->
+case get(idle_timer_ref) of
+TimerRef when is_reference(TimerRef) ->
+erlang:cancel_timer(TimerRef);
+undefined  ->
+ok
+end,
+put(idle_timer_ref, erlang:send_after(idle_limit(), self(), timeout)).
+
+update_idle_limit_from_config() ->
+Default = integer_to_list(?IDLE_LIMIT_DEFAULT),
+IdleLimit = case config:get("couchdb", "idle_check_timeout", Default) 
of
+"infinity" ->
+infinity;
--- End diff --

I wonder if we shouldn't use hibernate here to force garbage collection 
when we're not using idle timeouts?


---
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-couch pull request #236: Close idle dbs

[davisp]

Github user davisp commented on a diff in the pull request:

https://github.com/apache/couchdb-couch/pull/236#discussion_r105803958
  
--- Diff: src/couch_server.erl ---
@@ -173,6 +174,15 @@ hash_admin_passwords(Persist) ->
 config:set("admins", User, ?b2l(HashedPassword), Persist)
 end, couch_passwords:get_unhashed_admins()).
 
+close_db_if_idle(DbName) ->
+case ets:lookup(couch_dbs, DbName) of
--- End diff --

I think I'd keep this on the off chance we save sending an extra message to 
couch_server.


---
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-couch pull request #236: Close idle dbs

[davisp]

Github user davisp commented on a diff in the pull request:

https://github.com/apache/couchdb-couch/pull/236#discussion_r105803775
  
--- Diff: src/couch_db_updater.erl ---
@@ -1454,3 +1468,28 @@ default_security_object(_DbName) ->
 "everyone" ->
 []
 end.
+
+% These functions rely on using the process dictionary. This is usually 
frowned upon
+% howver in this case it is done to avoid changing to a different server 
state record
--- End diff --

I'd append this to mention that we'll update the `#db{}` record once PSE 
lands.


---
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-couch issue #236: Close idle dbs

[nickva]

Github user nickva commented on the issue:

https://github.com/apache/couchdb-couch/pull/236
  
Since first (dirty) is_idle check was moved to `couch_db_updater` wonder if 
it is even worth doing this additional read in couch_server

```
close_db_if_idle(DbName) ->
case ets:lookup(couch_dbs, DbName) of
[#db{} = Db] ->
gen_server:cast(couch_server, {close_db_if_idle, DbName});
 _ ->
ok
end.
```



---
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-couch issue #236: Close idle dbs

[davisp]

Github user davisp commented on the issue:

https://github.com/apache/couchdb-couch/pull/236
  
I'd probably avoid adding load to the config changes listener system as
that already has a habit of getting backed up.

On Mon, Mar 13, 2017 at 6:09 PM Benjamin Bastian 
wrote:

> Also, can that be changed to be a config_listener rather than read the
> config on every timeout?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> ,
> or mute the thread
> 

> .
>



---
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-couch issue #236: Close idle dbs

[sagelywizard]

Github user sagelywizard commented on the issue:

https://github.com/apache/couchdb-couch/pull/236
  
Also, can that be changed to be a `config_listener` rather than read the 
config on every timeout?


---
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-couch issue #236: Close idle dbs

[sagelywizard]

Github user sagelywizard commented on the issue:

https://github.com/apache/couchdb-couch/pull/236
  
Seems reasonable to me as long as as we make sure to change it to be a 
state-based configuration at some point. I really hate the process dictionary.


---
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-couch issue #236: Close idle dbs

[nickva]

Github user nickva commented on the issue:

https://github.com/apache/couchdb-couch/pull/236
  
@davisp @sagelywizard 

Used process dictionary to fix two issues:

1) Lack of configuration. Configuration is now read from 
`couchdb.idle_check_timeout` with a default of 6 msec. Every timeout period 
it is refreshed from config module and put into process dictionary.

2) Potentially having more than 1 timeout message in flight. This could 
happen if shorty after a hibernate event, there is a gen_server message handled 
which sets a new timeout. So now they'd be two of them. To fix that, timer ref 
from send_after is stuck in the process dictionary and it is canceled before 
sending another. Now there is still a chance that previous timeout already is 
in the message queue, but there is no chance of an overlapping timeout message 
cascade forming.


---
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-couch issue #236: Close idle dbs

[davisp]

Github user davisp commented on the issue:

https://github.com/apache/couchdb-couch/pull/236
  
I like this change for the most part though I also think @sagelywizard is 
spot on in wondering how much extra load this will add to couch_server. However 
I don't have any better ideas on how to achieve this that don't involve a 
message going through couch_server. For instance, if we just exited the 
couch_db_updater process and relied on the 'EXIT' signal handling in 
couch_server that leaves us open to (more larger) race conditions where a 
client grabs the db record just as its closing due to an idle timeout.

Also for the configurability aspect it occurs to me we could just stuff it 
into the process dictionary since it is initialization configuration that would 
be mostly static. We could for instance re-check every $timeout period and 
update the dictionary or something. And then we can undo that cleanly when the 
PSE stuff lands and we can change the #db record more freely.


---
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-couch pull request #235: Allow limiting maximum document body size

[sagelywizard]

Github user sagelywizard commented on a diff in the pull request:

https://github.com/apache/couchdb-couch/pull/235#discussion_r105772791
  
--- Diff: src/couch_doc.erl ---
@@ -125,7 +125,14 @@ 
doc_to_json_obj(#doc{id=Id,deleted=Del,body=Body,revs={Start, RevIds},
 }.
 
 from_json_obj({Props}) ->
--- End diff --

Is this the right place to be making this change? `from_json_obj` is used 
in places other than when parsing HTTP request bodies. For example, this change 
will cause `fabric:cleanup_index_files` to fail if any existing design 
documents are larger than the limit.


---
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-couch issue #236: Close idle dbs

[sagelywizard]

Github user sagelywizard commented on the issue:

https://github.com/apache/couchdb-couch/pull/236
  
I'm tentatively in favor of waiting for the PSE code. I'm still concerned 
that there's no backpressure from couch_server and no configuration change that 
could be made if the messages from this code became a problem.


---
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-couch issue #236: Close idle dbs

[nickva]

Github user nickva commented on the issue:

https://github.com/apache/couchdb-couch/pull/236
  
@sagelywizard we are doing a check first is see if shard is idle to 
hopefully avoid backing up couch_server with messages.

Also because this will close idle shards, couch_server should have a bit of 
an easier time, since they'd be less entries in the lru and in the couchdbs_ets 
table.

Since PSE merge would modify this code wonder if we should wait till that 
merge happens and then make it nicer and configurable


---
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-couch issue #236: Close idle dbs

[sagelywizard]

Github user sagelywizard commented on the issue:

https://github.com/apache/couchdb-couch/pull/236
  
Also, can we change couch_db_updater's state to be a `#st{db=#db{}, 
idle_timeout=Timeout}` record? That way we could make it configurable which 
would be nice.


---
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-couch issue #236: Close idle dbs

[sagelywizard]

Github user sagelywizard commented on the issue:

https://github.com/apache/couchdb-couch/pull/236
  
Could this be problematic from a performance perspective? There's no 
backpressure against making requests to couch_server if it's under load. If you 
have a high max_dbs_open, it could result in hundreds or thousands of messages 
being sent to couch_server. I haven't deeply thought through the performance 
implications, but I'm wondering if there could be a situation where this could 
cause couch_server's message queue to snowball if it got backed up.


---
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-3323) Idle dbs cause excessive overhead

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on COUCHDB-3323:
-

GitHub user nickva opened a pull request:

https://github.com/apache/couchdb-couch/pull/236

Close idle dbs

Previously idle dbs, especially sys_dbs like _replicator shards once opened
once for scanning would stay open forever. In a large cluster with many
_replicator shards that can add up to a significant overhead, mostly in 
terms
of number of active processes.

Add a mechanism to close dbs which have an idle db updater. Before 
hibernation
was used to limit the memory pressure, however that is often not enough in
practice.

Ideally timeout value would be a configuration option, however we don't 
want to
add an ets call for every couch_db_updater callback, and modifiying the db
record is prohibitive for this patch, however PSE does this work and once it
lands we can read the idle configuration when the process starts.

(Original idea for this belongs to Paul Davis)

COUCHDB-3323

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

$ git pull https://github.com/cloudant/couchdb-couch close-idle-dbs

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

https://github.com/apache/couchdb-couch/pull/236.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 #236


commit 85a9f13632a6828420e01cc7d39cdaa7c19c2170
Author: Nick Vatamaniuc 
Date:   2017-03-10T19:24:01Z

Close idle dbs

Previously idle dbs, especially sys_dbs like _replicator shards once opened
once for scanning would stay open forever. In a large cluster with many
_replicator shards that can add up to a significant overhead, mostly in 
terms
of number of active processes.

Add a mechanism to close dbs which have an idle db updater. Before 
hibernation
was used to limit the memory pressure, however that is often not enough in
practice.

Ideally timeout value would be a configuration option, however we don't 
want to
add an ets call for every couch_db_updater callback, and modifiying the db
record is prohibitive for this patch, however PSE does this work and once it
lands we can read the idle configuration when the process starts.

(Original idea for this belongs to Paul Davis)

COUCHDB-3323




> Idle dbs cause excessive overhead
> -
>
> Key: COUCHDB-3323
> URL: https://issues.apache.org/jira/browse/COUCHDB-3323
> Project: CouchDB
>  Issue Type: Bug
>Reporter: Nick Vatamaniuc
>
> Idle dbs, especially sys_dbs like _replicator shards once opened
> once for scanning would stay open forever. In a large cluster with many
> _replicator shards that can add up to a significant overhead, mostly in terms
> of number of active processes.
> Add a mechanism to close dbs which are idle.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] couchdb-couch pull request #236: Close idle dbs

[nickva]

GitHub user nickva opened a pull request:

https://github.com/apache/couchdb-couch/pull/236

Close idle dbs

Previously idle dbs, especially sys_dbs like _replicator shards once opened
once for scanning would stay open forever. In a large cluster with many
_replicator shards that can add up to a significant overhead, mostly in 
terms
of number of active processes.

Add a mechanism to close dbs which have an idle db updater. Before 
hibernation
was used to limit the memory pressure, however that is often not enough in
practice.

Ideally timeout value would be a configuration option, however we don't 
want to
add an ets call for every couch_db_updater callback, and modifiying the db
record is prohibitive for this patch, however PSE does this work and once it
lands we can read the idle configuration when the process starts.

(Original idea for this belongs to Paul Davis)

COUCHDB-3323

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

$ git pull https://github.com/cloudant/couchdb-couch close-idle-dbs

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

https://github.com/apache/couchdb-couch/pull/236.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 #236


commit 85a9f13632a6828420e01cc7d39cdaa7c19c2170
Author: Nick Vatamaniuc 
Date:   2017-03-10T19:24:01Z

Close idle dbs

Previously idle dbs, especially sys_dbs like _replicator shards once opened
once for scanning would stay open forever. In a large cluster with many
_replicator shards that can add up to a significant overhead, mostly in 
terms
of number of active processes.

Add a mechanism to close dbs which have an idle db updater. Before 
hibernation
was used to limit the memory pressure, however that is often not enough in
practice.

Ideally timeout value would be a configuration option, however we don't 
want to
add an ets call for every couch_db_updater callback, and modifiying the db
record is prohibitive for this patch, however PSE does this work and once it
lands we can read the idle configuration when the process starts.

(Original idea for this belongs to Paul Davis)

COUCHDB-3323




---
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] [Created] (COUCHDB-3323) Idle dbs cause excessive overhead

[Nick Vatamaniuc (JIRA)]

Nick Vatamaniuc created COUCHDB-3323:


 Summary: Idle dbs cause excessive overhead
 Key: COUCHDB-3323
 URL: https://issues.apache.org/jira/browse/COUCHDB-3323
 Project: CouchDB
  Issue Type: Bug
Reporter: Nick Vatamaniuc


Idle dbs, especially sys_dbs like _replicator shards once opened
once for scanning would stay open forever. In a large cluster with many
_replicator shards that can add up to a significant overhead, mostly in terms
of number of active processes.

Add a mechanism to close dbs which are idle.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] couchdb-chttpd issue #157: Allow limiting maximum document body size

[nickva]

Github user nickva commented on the issue:

https://github.com/apache/couchdb-chttpd/pull/157
  
Tests are failing because it needs changes from 
https://github.com/apache/couchdb-couch/pull/235


---
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-2992) Add additional support for document size

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on COUCHDB-2992:
-

GitHub user nickva opened a pull request:

https://github.com/apache/couchdb-chttpd/pull/157

Allow limiting maximum document body size

This is the HTTP layer and some tests. The actual checking is done in couch
application's from_json_obj/1 function.

If a document is too large it will return a 413 response code. The error 
reason
will be the document ID. The intent is to help users identify the document 
if
they used _bulk_docs endpoint. It will also help replicator skip over 
documents
which are too large.

COUCHDB-2992

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

$ git pull https://github.com/cloudant/couchdb-chttpd couchdb-2992

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

https://github.com/apache/couchdb-chttpd/pull/157.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 #157


commit 95ecd629f77444dd5fa2820fbc18cccaba350f6d
Author: Nick Vatamaniuc 
Date:   2017-03-13T06:22:19Z

Allow limiting maximum document body size

This is the HTTP layer and some tests. The actual checking is done in couch
application's from_json_obj/1 function.

If a document is too large it will return a 413 response code. The error 
reason
will be the document ID. The intent is to help users identify the document 
if
they used _bulk_docs endpoint. It will also help replicator skip over 
documents
which are too large.

COUCHDB-2992




> Add additional support for document size
> 
>
> Key: COUCHDB-2992
> URL: https://issues.apache.org/jira/browse/COUCHDB-2992
> Project: CouchDB
>  Issue Type: Improvement
>  Components: Database Core
>Reporter: Tony Sun
>
> Currently, only max_document_size of 64 GB is the restriction for users 
> creating documents. Large documents often leads to issues with our indexers. 
> This feature will allow users more finer grain control over document size.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] couchdb-chttpd pull request #157: Allow limiting maximum document body size

[nickva]

GitHub user nickva opened a pull request:

https://github.com/apache/couchdb-chttpd/pull/157

Allow limiting maximum document body size

This is the HTTP layer and some tests. The actual checking is done in couch
application's from_json_obj/1 function.

If a document is too large it will return a 413 response code. The error 
reason
will be the document ID. The intent is to help users identify the document 
if
they used _bulk_docs endpoint. It will also help replicator skip over 
documents
which are too large.

COUCHDB-2992

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

$ git pull https://github.com/cloudant/couchdb-chttpd couchdb-2992

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

https://github.com/apache/couchdb-chttpd/pull/157.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 #157


commit 95ecd629f77444dd5fa2820fbc18cccaba350f6d
Author: Nick Vatamaniuc 
Date:   2017-03-13T06:22:19Z

Allow limiting maximum document body size

This is the HTTP layer and some tests. The actual checking is done in couch
application's from_json_obj/1 function.

If a document is too large it will return a 413 response code. The error 
reason
will be the document ID. The intent is to help users identify the document 
if
they used _bulk_docs endpoint. It will also help replicator skip over 
documents
which are too large.

COUCHDB-2992




---
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-couch pull request #235: Allow limiting maximum document body size

[nickva]

GitHub user nickva opened a pull request:

https://github.com/apache/couchdb-couch/pull/235

Allow limiting maximum document body size

Configuration is via the `couchdb.max_document_size`. In the past that
was implemented as a maximum http request body size and this finally 
implements
it by actually checking a document's body size.

COUCHDB-2992

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

$ git pull https://github.com/cloudant/couchdb-couch couchdb-2992

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

https://github.com/apache/couchdb-couch/pull/235.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 #235


commit c51c3f2bdc8e2f2a135c8363096762607ed33f2c
Author: Nick Vatamaniuc 
Date:   2017-03-13T06:33:57Z

Allow limiting maximum document body size

Configuration is via the `couchdb.max_document_size`. In the past that
was implemented as a maximum http request body size and this finally 
implements
it by actually checking a document's body size.

COUCHDB-2992




---
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-2992) Add additional support for document size

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on COUCHDB-2992:
-

GitHub user nickva opened a pull request:

https://github.com/apache/couchdb-couch/pull/235

Allow limiting maximum document body size

Configuration is via the `couchdb.max_document_size`. In the past that
was implemented as a maximum http request body size and this finally 
implements
it by actually checking a document's body size.

COUCHDB-2992

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

$ git pull https://github.com/cloudant/couchdb-couch couchdb-2992

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

https://github.com/apache/couchdb-couch/pull/235.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 #235


commit c51c3f2bdc8e2f2a135c8363096762607ed33f2c
Author: Nick Vatamaniuc 
Date:   2017-03-13T06:33:57Z

Allow limiting maximum document body size

Configuration is via the `couchdb.max_document_size`. In the past that
was implemented as a maximum http request body size and this finally 
implements
it by actually checking a document's body size.

COUCHDB-2992




> Add additional support for document size
> 
>
> Key: COUCHDB-2992
> URL: https://issues.apache.org/jira/browse/COUCHDB-2992
> Project: CouchDB
>  Issue Type: Improvement
>  Components: Database Core
>Reporter: Tony Sun
>
> Currently, only max_document_size of 64 GB is the restriction for users 
> creating documents. Large documents often leads to issues with our indexers. 
> This feature will allow users more finer grain control over document size.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (COUCHDB-3322) Permissions error when trying to start coucdb server

[Brian Rayburn (JIRA)]

Brian Rayburn created COUCHDB-3322:
--

 Summary: Permissions error when trying to start coucdb server
 Key: COUCHDB-3322
 URL: https://issues.apache.org/jira/browse/COUCHDB-3322
 Project: CouchDB
  Issue Type: Bug
Reporter: Brian Rayburn


WIn 10. Couchdb 2.0.1. At first Couchdb service was running paused. Tried 
running from command line, but received an error indicating a permissions 
problem on starting the log server. Was able to start a CMD line as 
administrator and start couchdb successfully. User is a member of the admin 
group. Any idea what's going on here? Thank you in advance.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)