[jira] [Resolved] (COUCHDB-1216) Rename _update to _save
[ https://issues.apache.org/jira/browse/COUCHDB-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Newson resolved COUCHDB-1216. Resolution: Won't Fix In couchdb we regard creation, update, and deletion of documents as 'updates', so the current name reflects internal terminology. I'm closing this as 'Won't Fix' but the idea could be helpful in defining a simpler and cleaner API in couchdb 2.0, where we could make incompatible changes like this. Thank you again for the suggestion. Rename _update to _save --- Key: COUCHDB-1216 URL: https://issues.apache.org/jira/browse/COUCHDB-1216 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Reporter: Johnny Weng Luu Priority: Trivial Since an update function can be used to either create or update a document, I think it's more appropriate to rename it to _save. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1216) Rename _update to _save
[ https://issues.apache.org/jira/browse/COUCHDB-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13063796#comment-13063796 ] Johnny Weng Luu commented on COUCHDB-1216: -- Yeah I think save is much more logical and follows web standards. Often you do something like model.save() and it will either send a 'create' or 'update' action depending on it's newness. Rename _update to _save --- Key: COUCHDB-1216 URL: https://issues.apache.org/jira/browse/COUCHDB-1216 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Reporter: Johnny Weng Luu Priority: Trivial Since an update function can be used to either create or update a document, I think it's more appropriate to rename it to _save. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1216) Rename _update to _save
[ https://issues.apache.org/jira/browse/COUCHDB-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13063811#comment-13063811 ] Jan Lehnardt commented on COUCHDB-1216: --- Can you point to a web standard that mandates a save method, function or endpoint? Rename _update to _save --- Key: COUCHDB-1216 URL: https://issues.apache.org/jira/browse/COUCHDB-1216 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Reporter: Johnny Weng Luu Priority: Trivial Since an update function can be used to either create or update a document, I think it's more appropriate to rename it to _save. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1216) Rename _update to _save
[ https://issues.apache.org/jira/browse/COUCHDB-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13063822#comment-13063822 ] Johnny Weng Luu commented on COUCHDB-1216: -- Backbone uses this approach. http://documentcloud.github.com/backbone/#Model-save Also YUI's new MVC structure. But it isn't really a standard to be correctly. Just something I have seen on multiple places. Rename _update to _save --- Key: COUCHDB-1216 URL: https://issues.apache.org/jira/browse/COUCHDB-1216 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Reporter: Johnny Weng Luu Priority: Trivial Since an update function can be used to either create or update a document, I think it's more appropriate to rename it to _save. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
How we relax with couchdb
Greetings Just a few words to say how we relax using CouchDB in one of our application ( you can even see our very own couch at http://www.flickr.com/photos/52933253@N05/4887256115/in/set-72157625387127511/ :) We decided to settle on couchdb for timejim, our timetracking applications ( http://timejim.com ) for three reasons: * multi master set up out of the box with the built-in continuous replication. It allows us to make hot backups, and distribute our data across a range of cheap nodes in the cloud. A multi master setup in PostgreSQL is, for all the love we have for PostgreSQL, at best tricky. * http access to the data, allowing us to leverage our knowledge of web technologies, for example clustering with nginx, and in the future allow client and server javascript code reuse when using/accessing the data * easier to use storage model, which allow us to update the data model without using alter table and the like Besides that we appreciate to have couchdb packaged in debian, which makes deployment a breeze. If it is not abusing your wiki space, I wanted to write this to http://wiki.apache.org/couchdb/CouchDB_in_the_wild to add some love to couchdb, maybe in a shorter form. Greets Emmanuel
[jira] [Resolved] (COUCHDB-970) Server crashes after successfull compaction
[
https://issues.apache.org/jira/browse/COUCHDB-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rudi Benkovic resolved COUCHDB-970.
---
Resolution: Not A Problem
Fix Version/s: 1.0.2
Upgraded to CouchBase which is based on 1.0.2, seems to work fine now. 0.11.2
didn't correctly compact the database - the newly compacted database always
contained old, stale documents, even retaining that count in doc_del_count.
Seems to be fixed now.
Server crashes after successfull compaction
---
Key: COUCHDB-970
URL: https://issues.apache.org/jira/browse/COUCHDB-970
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 0.11.2
Environment: Linux 2.6.18-194.11.3.el5 #1 SMP Mon Aug 30 16:19:16 EDT
2010 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Rudi Benkovic
Fix For: 1.0.2
Attachments: couch.log.errors
Our photos DB contains about 15K documents with 5-6 attachments per document
which results in a ~41GB database. Compacting this database (by removing the
original 30K documents to 15K) took a while, but after the temp file is
successfully switched, it crashes the whole server with these errors:
--
[Mon, 29 Nov 2010 15:24:52 GMT] [error] [0.186.0] ** Generic server
0.186.0 terminating
** Last message in was {'$gen_cast',
{compact_done,
/home/couchdb/photos.couch.compact}}
** When Server state == {db,0.185.0,0.186.0,0.4488.3,
1291039821602632,0.183.0,0.209.0,
{db_header,5,320843,0,
{81045895963,{12262,39070}},
{81045898520,51332},
nil,0,nil,nil,1000},
320843,
{btree,0.183.0,
{81045895963,{12262,39070}},
#Funcouch_db_updater.7.82129660,
#Funcouch_db_updater.8.42953822,
#Funcouch_btree.5.124754102,
#Funcouch_db_updater.9.115326703},
{btree,0.183.0,
{81045898520,51332},
#Funcouch_db_updater.10.103072508,
#Funcouch_db_updater.11.104248294,
#Funcouch_btree.5.124754102,
#Funcouch_db_updater.12.125559248},
{btree,0.183.0,nil,
#Funcouch_btree.0.83553141,
#Funcouch_btree.1.30790806,
#Funcouch_btree.2.124754102,nil},
320843,photos,/home/couchdb/photos.couch,
[],[],nil,
{user_ctx,null,[],undefined},
nil,1000,
[before_header,after_header,on_file_open]}
** Reason for termination ==
** {timeout,
{gen_server,call,
[0.185.0,
{db_updated,
{db,0.185.0,0.186.0,nil,1291039821602632,0.4617.3,
0.4619.3,
{db_header,5,320843,0,
{44797036682,{12262,39070}},
{44797027887,51332},
nil,0,nil,nil,1000},
320843,
{btree,0.4617.3,
{44797036682,{12262,39070}},
#Funcouch_db_updater.7.82129660,
#Funcouch_db_updater.8.42953822,
#Funcouch_btree.5.124754102,
#Funcouch_db_updater.9.115326703},
{btree,0.4617.3,
{44797027887,51332},
#Funcouch_db_updater.10.103072508,
#Funcouch_db_updater.11.104248294,
#Funcouch_btree.5.124754102,
#Funcouch_db_updater.12.125559248},
{btree,0.4617.3,nil,#Funcouch_btree.0.83553141,
#Funcouch_btree.1.30790806,
#Funcouch_btree.2.124754102,nil},
320843,photos,/home/couchdb/photos.couch,[],[],
nil,
{user_ctx,null,[],undefined},
nil,1000,
[before_header,after_header,on_file_open]}}]}}
[Mon, 29 Nov 2010 15:24:52 GMT] [error] [0.186.0] {error_report,0.29.0,
{0.186.0,crash_report,
[[{pid,0.186.0},
{registered_name,[]},
{error_info,
{exit,
{timeout,
[jira] [Commented] (COUCHDB-1216) Rename _update to _save
[ https://issues.apache.org/jira/browse/COUCHDB-1216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13063864#comment-13063864 ] Noah Slater commented on COUCHDB-1216: -- Save makes sense in the context of MVC, and indeed, objects. CouchDB is a RESTful system that operates on resources and representations. Update makes more sense in that context. Rename _update to _save --- Key: COUCHDB-1216 URL: https://issues.apache.org/jira/browse/COUCHDB-1216 Project: CouchDB Issue Type: Improvement Components: HTTP Interface Reporter: Johnny Weng Luu Priority: Trivial Since an update function can be used to either create or update a document, I think it's more appropriate to rename it to _save. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1217) Get _rev of the newly created document in _update function
Get _rev of the newly created document in _update function -- Key: COUCHDB-1217 URL: https://issues.apache.org/jira/browse/COUCHDB-1217 Project: CouchDB Issue Type: New Feature Reporter: Johnny Weng Luu I think it would be good to allow the _update function return the created/update document including the _rev field to the client. In this way the client doesn't have to make another HTTP request to get it and be able to update the document. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1217) Get _rev of the newly created document in _update function
[ https://issues.apache.org/jira/browse/COUCHDB-1217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johnny Weng Luu updated COUCHDB-1217: - Description: I think it would be good to allow the _update function returning the created/update document including the _rev field to the client. In this way the client doesn't have to make another HTTP request to get it to be able to update the document. was: I think it would be good to allow the _update function return the created/update document including the _rev field to the client. In this way the client doesn't have to make another HTTP request to get it and be able to update the document. Get _rev of the newly created document in _update function -- Key: COUCHDB-1217 URL: https://issues.apache.org/jira/browse/COUCHDB-1217 Project: CouchDB Issue Type: New Feature Reporter: Johnny Weng Luu I think it would be good to allow the _update function returning the created/update document including the _rev field to the client. In this way the client doesn't have to make another HTTP request to get it to be able to update the document. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-995) Changes feed returns duplicate fields with include_docs=true
[
https://issues.apache.org/jira/browse/COUCHDB-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13063950#comment-13063950
]
Bogdan Artyushenko commented on COUCHDB-995:
not quite sure but I have a problem of this type with couchdb 1.1.0, but if I
use on the same pc 0.10 (or even 1.0.2) I have not this problem.
Changes feed returns duplicate fields with include_docs=true
Key: COUCHDB-995
URL: https://issues.apache.org/jira/browse/COUCHDB-995
Project: CouchDB
Issue Type: Bug
Components: Full-Text Search, HTTP Interface
Affects Versions: 1.0.1
Environment: MacOSX with CouchDBX 1.0.1.1 as well as homebrew couchdb
1.0.1
Reporter: Luke Driscoll
I ran in to a problem, when using couchdb-lucene; but the problem is with
couch itself. I've found this happening both on CouchDBX 1.0.1.1 and couchdb
1.0.1 (through homebrew).
The problem is, if I update a document, and put in the same data each time,
the data that comes out of the changes feed has duplicate fields. The call:
http://localhost:5984/test/_changes?feed=continuousheartbeat=15000include_docs=truesince=0
is returning data like this:
{
seq:356,
id:encounter_83-20101218T133000.000-0700,
changes:[{rev:2-ada5250d09a364608db6cd639c213eae}],
doc:{
_id:encounter_83-20101218T133000.000-0700,
_rev:2-ada5250d09a364608db6cd639c213eae,
location:{
organisation:{
name:Some Org,
abbrev:0
},
location:{
name:Other Loc,
abbrev:Othe
}
},
comment:Broken,
appointmentDateTime:2010-12-18T13:30:00.000-07:00,
-patient_id:patient_83,
appointmentType:Acute,
-type:encounter,
-patient_id:patient_83,
-type:encounter
}
}
You'll notice that the patient_id field and the type field, are being
duplicated on the data return. This is causing couchdb-lucene to baulk, but
it's also just invalid json.
Thanks
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-995) Changes feed returns duplicate fields with include_docs=true
[
https://issues.apache.org/jira/browse/COUCHDB-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13063966#comment-13063966
]
Robert Newson commented on COUCHDB-995:
---
I'm curious to know how couchdb-lucene reacts. Since it passes through a Python
dict, I'd have expected duplicates to be dropped silently.
Changes feed returns duplicate fields with include_docs=true
Key: COUCHDB-995
URL: https://issues.apache.org/jira/browse/COUCHDB-995
Project: CouchDB
Issue Type: Bug
Components: Full-Text Search, HTTP Interface
Affects Versions: 1.0.1
Environment: MacOSX with CouchDBX 1.0.1.1 as well as homebrew couchdb
1.0.1
Reporter: Luke Driscoll
I ran in to a problem, when using couchdb-lucene; but the problem is with
couch itself. I've found this happening both on CouchDBX 1.0.1.1 and couchdb
1.0.1 (through homebrew).
The problem is, if I update a document, and put in the same data each time,
the data that comes out of the changes feed has duplicate fields. The call:
http://localhost:5984/test/_changes?feed=continuousheartbeat=15000include_docs=truesince=0
is returning data like this:
{
seq:356,
id:encounter_83-20101218T133000.000-0700,
changes:[{rev:2-ada5250d09a364608db6cd639c213eae}],
doc:{
_id:encounter_83-20101218T133000.000-0700,
_rev:2-ada5250d09a364608db6cd639c213eae,
location:{
organisation:{
name:Some Org,
abbrev:0
},
location:{
name:Other Loc,
abbrev:Othe
}
},
comment:Broken,
appointmentDateTime:2010-12-18T13:30:00.000-07:00,
-patient_id:patient_83,
appointmentType:Acute,
-type:encounter,
-patient_id:patient_83,
-type:encounter
}
}
You'll notice that the patient_id field and the type field, are being
duplicated on the data return. This is causing couchdb-lucene to baulk, but
it's also just invalid json.
Thanks
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1218) Better logger performance
Better logger performance - Key: COUCHDB-1218 URL: https://issues.apache.org/jira/browse/COUCHDB-1218 Project: CouchDB Issue Type: Improvement Reporter: Filipe Manana Assignee: Filipe Manana Attachments: 0001-Better-logger-performance.patch I made some experiments with OTP's disk_log module (available since 2001 at least) to use it to manage the log file. It turns out I got better throughput by using it. Basically it adopts a strategy similar to the asynchronous couch_file Damien described in this thread: http://mail-archives.apache.org/mod_mbox/couchdb-dev/201106.mbox/%3c5c39fb5a-0aca-4ff9-bd90-2ebecf271...@apache.org%3E Here's a benchmark with relaximation, 50 writers, 100 readers, documents of 1Kb, delayed_commits set to false and 'info' log level (default): http://graphs.mikeal.couchone.com/#/graph/9e19f6d9eeb318c70cabcf67bc013c7f The reads got a better throughput (bottom graph, easier to visualize). The patch (also attached here), which has a descriptive comment, is at: https://github.com/fdmanana/couchdb/compare/logger_perf.patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1218) Better logger performance
[ https://issues.apache.org/jira/browse/COUCHDB-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana updated COUCHDB-1218: --- Attachment: 0001-Better-logger-performance.patch Better logger performance - Key: COUCHDB-1218 URL: https://issues.apache.org/jira/browse/COUCHDB-1218 Project: CouchDB Issue Type: Improvement Reporter: Filipe Manana Assignee: Filipe Manana Attachments: 0001-Better-logger-performance.patch I made some experiments with OTP's disk_log module (available since 2001 at least) to use it to manage the log file. It turns out I got better throughput by using it. Basically it adopts a strategy similar to the asynchronous couch_file Damien described in this thread: http://mail-archives.apache.org/mod_mbox/couchdb-dev/201106.mbox/%3c5c39fb5a-0aca-4ff9-bd90-2ebecf271...@apache.org%3E Here's a benchmark with relaximation, 50 writers, 100 readers, documents of 1Kb, delayed_commits set to false and 'info' log level (default): http://graphs.mikeal.couchone.com/#/graph/9e19f6d9eeb318c70cabcf67bc013c7f The reads got a better throughput (bottom graph, easier to visualize). The patch (also attached here), which has a descriptive comment, is at: https://github.com/fdmanana/couchdb/compare/logger_perf.patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-536) CouchDB HTTP server stops accepting connections
[
https://issues.apache.org/jira/browse/COUCHDB-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064070#comment-13064070
]
Pasi Eronen commented on COUCHDB-536:
-
If netstat showed lots of connections (which consume file handles, too) , this
could be related to COUCHDB-1100?
CouchDB HTTP server stops accepting connections
---
Key: COUCHDB-536
URL: https://issues.apache.org/jira/browse/COUCHDB-536
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 0.10, 1.1
Environment: Ubuntu Linux 8.04 32bit and 64bit with Erlang R13B01
or Ubuntu Linux 8.04 64bit with Erlang R14B02
Reporter: Simon Eisenmann
Having 3 Couches all replicating a couple of databases to each other (pull
replication with a update notification process) the HTTP service on any of
the Couches stops working at some point (when running for a couple of ours
with constant changes on all databases and servers).
This is the error when a new HTTP request comes in:
=ERROR REPORT 19-Oct-2009::10:18:55 ===
application: mochiweb
Accept failed error
{error,enfile}
[error] [0.21619.12] {error_report,0.24.0,
{0.21619.12,crash_report,
[[{initial_call,{mochiweb_socket_server,acceptor_loop,['Argument__1']}},
{pid,0.21619.12},
{registered_name,[]},
{error_info,
{exit,
{error,accept_failed},
[{mochiweb_socket_server,acceptor_loop,1},
{proc_lib,init_p_do_apply,3}]}},
{ancestors,
[couch_httpd,couch_secondary_services,couch_server_sup,0.1.0]},
{messages,[]},
{links,[0.66.0]},
{dictionary,[]},
{trap_exit,false},
{status,running},
{heap_size,233},
{stack_size,24},
{reductions,202}],
[]]}}
[error] [0.66.0] {error_report,0.24.0,
{0.66.0,std_error,
{mochiweb_socket_server,225,{acceptor_error,{error,accept_failed}
To me this seems like it runs out of threads or sockets to handle the new
connection or somewhat like this.
Also i see in this setup that if i put lots of changes in a short time at
some point the replication process hangs (never finishes) and when trying to
restart the same replication once again is not possible and resulting in a
timeout.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-536) CouchDB HTTP server stops accepting connections
[
https://issues.apache.org/jira/browse/COUCHDB-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064089#comment-13064089
]
Simon Eisenmann commented on COUCHDB-536:
-
I had this again last night and did some further checks and found that there
were around 800 sockets in CLOSE_WAIT state for couchdb process. Though this
does not seem to be related to COUCHDB-1100 as i do not have any large views
which timeout while updating.
CouchDB HTTP server stops accepting connections
---
Key: COUCHDB-536
URL: https://issues.apache.org/jira/browse/COUCHDB-536
Project: CouchDB
Issue Type: Bug
Components: HTTP Interface
Affects Versions: 0.10, 1.1
Environment: Ubuntu Linux 8.04 32bit and 64bit with Erlang R13B01
or Ubuntu Linux 8.04 64bit with Erlang R14B02
Reporter: Simon Eisenmann
Having 3 Couches all replicating a couple of databases to each other (pull
replication with a update notification process) the HTTP service on any of
the Couches stops working at some point (when running for a couple of ours
with constant changes on all databases and servers).
This is the error when a new HTTP request comes in:
=ERROR REPORT 19-Oct-2009::10:18:55 ===
application: mochiweb
Accept failed error
{error,enfile}
[error] [0.21619.12] {error_report,0.24.0,
{0.21619.12,crash_report,
[[{initial_call,{mochiweb_socket_server,acceptor_loop,['Argument__1']}},
{pid,0.21619.12},
{registered_name,[]},
{error_info,
{exit,
{error,accept_failed},
[{mochiweb_socket_server,acceptor_loop,1},
{proc_lib,init_p_do_apply,3}]}},
{ancestors,
[couch_httpd,couch_secondary_services,couch_server_sup,0.1.0]},
{messages,[]},
{links,[0.66.0]},
{dictionary,[]},
{trap_exit,false},
{status,running},
{heap_size,233},
{stack_size,24},
{reductions,202}],
[]]}}
[error] [0.66.0] {error_report,0.24.0,
{0.66.0,std_error,
{mochiweb_socket_server,225,{acceptor_error,{error,accept_failed}
To me this seems like it runs out of threads or sockets to handle the new
connection or somewhat like this.
Also i see in this setup that if i put lots of changes in a short time at
some point the replication process hangs (never finishes) and when trying to
restart the same replication once again is not possible and resulting in a
timeout.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1218) Better logger performance
[ https://issues.apache.org/jira/browse/COUCHDB-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064181#comment-13064181 ] Paul Joseph Davis commented on COUCHDB-1218: Also, browsing the those benchmark graphs I notice that response times aren't changing, but the number of requests per second is increasing. Have you looked at memory usage patterns during such a test? I'd be curious to see of the disk_log process is just being out competed by .couch file i/o and then it buffers the log messages in RAM. Not that I have any idea how bad that'd be in terms of size. Better logger performance - Key: COUCHDB-1218 URL: https://issues.apache.org/jira/browse/COUCHDB-1218 Project: CouchDB Issue Type: Improvement Reporter: Filipe Manana Assignee: Filipe Manana Attachments: 0001-Better-logger-performance.patch I made some experiments with OTP's disk_log module (available since 2001 at least) to use it to manage the log file. It turns out I got better throughput by using it. Basically it adopts a strategy similar to the asynchronous couch_file Damien described in this thread: http://mail-archives.apache.org/mod_mbox/couchdb-dev/201106.mbox/%3c5c39fb5a-0aca-4ff9-bd90-2ebecf271...@apache.org%3E Here's a benchmark with relaximation, 50 writers, 100 readers, documents of 1Kb, delayed_commits set to false and 'info' log level (default): http://graphs.mikeal.couchone.com/#/graph/9e19f6d9eeb318c70cabcf67bc013c7f The reads got a better throughput (bottom graph, easier to visualize). The patch (also attached here), which has a descriptive comment, is at: https://github.com/fdmanana/couchdb/compare/logger_perf.patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1218) Better logger performance
[ https://issues.apache.org/jira/browse/COUCHDB-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064188#comment-13064188 ] Robert Newson commented on COUCHDB-1218: disk_log module seems a bit weird, I wonder if it's intended for this? Seems more like a binary logger sort of thing. The patch still goes through the gen_event server, though only to print to screen, seems a shame that we can't remove it at all. I'm equivocal. Logging can be improved for sure but I'm not sure this is the way. Something pluggable might be better, for example, I'd rather send the log statements over UDP to a syslog daemon and let it handle the writing and file rotation. Better logger performance - Key: COUCHDB-1218 URL: https://issues.apache.org/jira/browse/COUCHDB-1218 Project: CouchDB Issue Type: Improvement Reporter: Filipe Manana Assignee: Filipe Manana Attachments: 0001-Better-logger-performance.patch I made some experiments with OTP's disk_log module (available since 2001 at least) to use it to manage the log file. It turns out I got better throughput by using it. Basically it adopts a strategy similar to the asynchronous couch_file Damien described in this thread: http://mail-archives.apache.org/mod_mbox/couchdb-dev/201106.mbox/%3c5c39fb5a-0aca-4ff9-bd90-2ebecf271...@apache.org%3E Here's a benchmark with relaximation, 50 writers, 100 readers, documents of 1Kb, delayed_commits set to false and 'info' log level (default): http://graphs.mikeal.couchone.com/#/graph/9e19f6d9eeb318c70cabcf67bc013c7f The reads got a better throughput (bottom graph, easier to visualize). The patch (also attached here), which has a descriptive comment, is at: https://github.com/fdmanana/couchdb/compare/logger_perf.patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1219) Send data
Send data - Key: COUCHDB-1219 URL: https://issues.apache.org/jira/browse/COUCHDB-1219 Project: CouchDB Issue Type: New Feature Reporter: Johnny Weng Luu Priority: Minor With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc. It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push the data to other servers. What I have to do right now to send the data to an external service is to setup a server (node.js) that listens on the _changes feed. When there is a document meant for being delivered through email node.js will send a HTTP request to a email service (sendgrid). I think it would make sense if CouchDB could make HTTP requests on document changes, so that we can eliminate that extra layer. Why only HTTP server for data but not HTTP client for data. (This would make even more sense if CouchDB was redesigned with node.js). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1219) Send data
[ https://issues.apache.org/jira/browse/COUCHDB-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johnny Weng Luu updated COUCHDB-1219: - Description: With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc. It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers. What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed. When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service. I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data. Why only have a HTTP server for data but not a HTTP client for data. (This would make even more sense if CouchDB was redesigned with node.js). was: With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc. It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push the data to other servers. What I have to do right now to send the data to an external service is to setup a server (node.js) that listens on the _changes feed. When there is a document meant for being delivered through email node.js will send a HTTP request to a email service (sendgrid). I think it would make sense if CouchDB could make HTTP requests on document changes, so that we can eliminate that extra layer. Why only HTTP server for data but not HTTP client for data. (This would make even more sense if CouchDB was redesigned with node.js). Send data - Key: COUCHDB-1219 URL: https://issues.apache.org/jira/browse/COUCHDB-1219 Project: CouchDB Issue Type: New Feature Reporter: Johnny Weng Luu Priority: Minor With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc. It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers. What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed. When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service. I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data. Why only have a HTTP server for data but not a HTTP client for data. (This would make even more sense if CouchDB was redesigned with node.js). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1219) Send data
[ https://issues.apache.org/jira/browse/COUCHDB-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johnny Weng Luu updated COUCHDB-1219: - Description: With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc. It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers. What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed. When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service. I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data. Why only have a HTTP server for data but not a HTTP client for data. I think this would make CouchDB even more suitable for couchapps. (This would make even more sense if CouchDB was redesigned with node.js). was: With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc. It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers. What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed. When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service. I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data. Why only have a HTTP server for data but not a HTTP client for data. (This would make even more sense if CouchDB was redesigned with node.js). Send data - Key: COUCHDB-1219 URL: https://issues.apache.org/jira/browse/COUCHDB-1219 Project: CouchDB Issue Type: New Feature Reporter: Johnny Weng Luu Priority: Minor With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc. It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers. What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed. When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service. I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data. Why only have a HTTP server for data but not a HTTP client for data. I think this would make CouchDB even more suitable for couchapps. (This would make even more sense if CouchDB was redesigned with node.js). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1219) Send data
[ https://issues.apache.org/jira/browse/COUCHDB-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johnny Weng Luu updated COUCHDB-1219: - Description: With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc. It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers. What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed. When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service. I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data. Why only have a HTTP server for data but not a HTTP client for data. I think this would make CouchDB even more suitable for couchapps. Now the whole app can be replicated and every couchdb instance can make it's own HTTP requests and we no longer have to have a node.js server just to support basic HTTP requests. (This would make even more sense if CouchDB was redesigned with node.js). was: With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc. It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers. What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed. When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service. I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data. Why only have a HTTP server for data but not a HTTP client for data. I think this would make CouchDB even more suitable for couchapps. (This would make even more sense if CouchDB was redesigned with node.js). Send data - Key: COUCHDB-1219 URL: https://issues.apache.org/jira/browse/COUCHDB-1219 Project: CouchDB Issue Type: New Feature Reporter: Johnny Weng Luu Priority: Minor With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc. It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers. What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed. When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service. I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data. Why only have a HTTP server for data but not a HTTP client for data. I think this would make CouchDB even more suitable for couchapps. Now the whole app can be replicated and every couchdb instance can make it's own HTTP requests and we no longer have to have a node.js server just to support basic HTTP requests. (This would make even more sense if CouchDB was redesigned with node.js). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1219) Send data
[ https://issues.apache.org/jira/browse/COUCHDB-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johnny Weng Luu updated COUCHDB-1219: - Description: With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc. It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers. What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed. When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service. I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data. Why only have a HTTP server for data but not a HTTP client for data. I think this would make CouchDB even more suitable for couchapps. Now the whole app can be replicated and every couchdb instance can make it's own HTTP requests and we no longer have to have a node.js server just to support basic HTTP requests. was: With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc. It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers. What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed. When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service. I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data. Why only have a HTTP server for data but not a HTTP client for data. I think this would make CouchDB even more suitable for couchapps. Now the whole app can be replicated and every couchdb instance can make it's own HTTP requests and we no longer have to have a node.js server just to support basic HTTP requests. (This would make even more sense if CouchDB was redesigned with node.js). Send data - Key: COUCHDB-1219 URL: https://issues.apache.org/jira/browse/COUCHDB-1219 Project: CouchDB Issue Type: New Feature Reporter: Johnny Weng Luu Priority: Minor With CouchDB the application server landscape has changed. The database can now handle almost all logic that is data related, eg. validation, updating, formatting etc. It has a HTTP server for incoming requests but one thing I find missing is a HTTP client that can push data to other servers. What I have to do right now for sending data to an external service is to setup a (node.js) server that listens on the _changes feed. When there is a document meant for being delivered through email, node.js will send a HTTP request to the (sendgrid) email service. I think it would make sense if CouchDB could make HTTP requests on document changes, meaning we can eliminate that extra HTTP client layer just for sending the data. Why only have a HTTP server for data but not a HTTP client for data. I think this would make CouchDB even more suitable for couchapps. Now the whole app can be replicated and every couchdb instance can make it's own HTTP requests and we no longer have to have a node.js server just to support basic HTTP requests. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
