[jira] Commented: (COUCHDB-164) Make error messages more verbose
[
https://issues.apache.org/jira/browse/COUCHDB-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12863837#action_12863837
]
Till Klampaeckel commented on COUCHDB-164:
--
I got another pretty one:
os_process_error {exit_status,2}
... this means that a path which is somewhere compiled into CouchDB does not
exist anymore. (The viewserver was broken after I moved an install to another
server).
Make error messages more verbose
--
Key: COUCHDB-164
URL: https://issues.apache.org/jira/browse/COUCHDB-164
Project: CouchDB
Issue Type: Improvement
Components: Database Core
Affects Versions: 0.9
Environment: Linux till-laptop 2.6.24-21-generic #1 SMP Tue Oct 21
23:09:30 UTC 2008 x86_64 GNU/Linux
Reporter: Till Klampaeckel
The following error designates that there is no space left on device, it
could say just that. :-)
[Tue, 18 Nov 2008 18:20:25 GMT] [error] [0.57.0] {error_report,
0.22.0,
{0.57.0,
std_error,
{mochiweb_socket_server,
235,
{child_error,
{{{badmatch,{{error,enospc},4414824448}},
[{couch_stream,write_data,2},
{couch_stream,write_data,2},
{couch_stream,handle_call,3},
{gen_server,handle_msg,6},
{proc_lib,init_p,5}]},
{gen_server,
call,
[0.11747.125,
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-757) crypto:md5 vs erlang:md5
crypto:md5 vs erlang:md5
Key: COUCHDB-757
URL: https://issues.apache.org/jira/browse/COUCHDB-757
Project: CouchDB
Issue Type: Improvement
Environment: GNU/Linux
Reporter: Filipe Manana
Attachments: crypto_md5.patch
Just noticed that crypto:md5 is faster than erlang:md5 by about an order of
magnitude when hashing just 8Kb or 4Kb of data.
Basically we use md5 hashing when writing and reading documents and attachments
through couch_file and couch_stream.
Eshell V5.8 (abort with ^G)
1 crypto:start().
ok
2 Bin1 = crypto:rand_bytes(4 * 1024).
92,239,233,29,1,237,96,193,188,97,4,72,51,90,96,91,187,
112,112,198,7,173,105,99,205,65,105,94,144,...
3
3 {T1, _} = timer:tc(erlang, md5, [Bin1]).
{211,
20,235,111,74,212,254,194,144,49,70,205,105,124,106,
131,230}
4
4 {T2, _} = timer:tc(crypto, md5, [Bin1]).
{60,
20,235,111,74,212,254,194,144,49,70,205,105,124,106,
131,230}
5
5 Bin2 = crypto:rand_bytes(8 * 1024).
246,66,158,227,62,127,62,239,202,232,133,244,191,9,136,
6,164,179,109,166,253,41,144,185,177,39,177,88,142,...
6
6 {T3, _} = timer:tc(erlang, md5, [Bin2]).
{446,
7,55,252,42,249,30,58,22,245,12,111,82,131,58,199,51}
7
7 {T4, _} = timer:tc(crypto, md5, [Bin2]).
{77,
7,55,252,42,249,30,58,22,245,12,111,82,131,58,199,51}
8
I know there's a ticket around with the goal of the possibility to remove the
dependency on the crypto module, but for environments where this is not a
problem it would be a plus.
Made a test that wrote 400 attachments with about 60Kbs and noticed an average
response time of 0.16s versus 0.18s (erlang:md5).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-537) reduce string
[ https://issues.apache.org/jira/browse/COUCHDB-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nils Adermann updated COUCHDB-537: -- Attachment: (was: 0001-Incorrect-builtin-function-names-now-throw-an-error-.patch) reduce string - Key: COUCHDB-537 URL: https://issues.apache.org/jira/browse/COUCHDB-537 Project: CouchDB Issue Type: Bug Components: Database Core Affects Versions: 0.10 Environment: ubuntu from source 0.10 Reporter: greg tappero Priority: Trivial Attachments: 0001-Incorrect-builtin-function-names-now-throw-an-error-.patch For a simple reduce as _sum if i add a space after _sum it crashes. Don't know how likely it is to add a space by mistake maybe the input could be trimed ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-537) reduce string
[ https://issues.apache.org/jira/browse/COUCHDB-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nils Adermann updated COUCHDB-537: -- Attachment: 0001-Incorrect-builtin-function-names-now-throw-an-error-.patch Updated the patch to include a test. It's also in github if that is of any use: http://github.com/naderman/couchdb/commit/feab10f02a82a57baf440080a3e3b593ead16585 reduce string - Key: COUCHDB-537 URL: https://issues.apache.org/jira/browse/COUCHDB-537 Project: CouchDB Issue Type: Bug Components: Database Core Affects Versions: 0.10 Environment: ubuntu from source 0.10 Reporter: greg tappero Priority: Trivial Attachments: 0001-Incorrect-builtin-function-names-now-throw-an-error-.patch For a simple reduce as _sum if i add a space after _sum it crashes. Don't know how likely it is to add a space by mistake maybe the input could be trimed ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-757) crypto:md5 vs erlang:md5
[
https://issues.apache.org/jira/browse/COUCHDB-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12863955#action_12863955
]
Adam Kocoloski commented on COUCHDB-757:
Cool, nice find Filipe. In the interest of not relying too heavily on crypto
we could add couch_util:md5*, e.g.
md5(Data) -
try crypto:md5(Data) catch error:_ - erlang:md5(Data) end.
I didn't notice any performance hit from the extra function call and try..catch
wrapper. Of course CouchDB still depends on crypto in other places, but at
least this patch wouldn't tie us any more closely to it.
crypto:md5 vs erlang:md5
Key: COUCHDB-757
URL: https://issues.apache.org/jira/browse/COUCHDB-757
Project: CouchDB
Issue Type: Improvement
Environment: GNU/Linux
Reporter: Filipe Manana
Attachments: crypto_md5.patch
Just noticed that crypto:md5 is faster than erlang:md5 by about an order of
magnitude when hashing just 8Kb or 4Kb of data.
Basically we use md5 hashing when writing and reading documents and
attachments through couch_file and couch_stream.
Eshell V5.8 (abort with ^G)
1 crypto:start().
ok
2 Bin1 = crypto:rand_bytes(4 * 1024).
92,239,233,29,1,237,96,193,188,97,4,72,51,90,96,91,187,
112,112,198,7,173,105,99,205,65,105,94,144,...
3
3 {T1, _} = timer:tc(erlang, md5, [Bin1]).
{211,
20,235,111,74,212,254,194,144,49,70,205,105,124,106,
131,230}
4
4 {T2, _} = timer:tc(crypto, md5, [Bin1]).
{60,
20,235,111,74,212,254,194,144,49,70,205,105,124,106,
131,230}
5
5 Bin2 = crypto:rand_bytes(8 * 1024).
246,66,158,227,62,127,62,239,202,232,133,244,191,9,136,
6,164,179,109,166,253,41,144,185,177,39,177,88,142,...
6
6 {T3, _} = timer:tc(erlang, md5, [Bin2]).
{446,
7,55,252,42,249,30,58,22,245,12,111,82,131,58,199,51}
7
7 {T4, _} = timer:tc(crypto, md5, [Bin2]).
{77,
7,55,252,42,249,30,58,22,245,12,111,82,131,58,199,51}
8
I know there's a ticket around with the goal of the possibility to remove the
dependency on the crypto module, but for environments where this is not a
problem it would be a plus.
Made a test that wrote 400 attachments with about 60Kbs and noticed an
average response time of 0.16s versus 0.18s (erlang:md5).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-757) crypto:md5 vs erlang:md5
[
https://issues.apache.org/jira/browse/COUCHDB-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski updated COUCHDB-757:
---
Attachment: crypto_fallback_to_erlang.patch
crypto:md5 vs erlang:md5
Key: COUCHDB-757
URL: https://issues.apache.org/jira/browse/COUCHDB-757
Project: CouchDB
Issue Type: Improvement
Environment: GNU/Linux
Reporter: Filipe Manana
Attachments: crypto_fallback_to_erlang.patch, crypto_md5.patch
Just noticed that crypto:md5 is faster than erlang:md5 by about an order of
magnitude when hashing just 8Kb or 4Kb of data.
Basically we use md5 hashing when writing and reading documents and
attachments through couch_file and couch_stream.
Eshell V5.8 (abort with ^G)
1 crypto:start().
ok
2 Bin1 = crypto:rand_bytes(4 * 1024).
92,239,233,29,1,237,96,193,188,97,4,72,51,90,96,91,187,
112,112,198,7,173,105,99,205,65,105,94,144,...
3
3 {T1, _} = timer:tc(erlang, md5, [Bin1]).
{211,
20,235,111,74,212,254,194,144,49,70,205,105,124,106,
131,230}
4
4 {T2, _} = timer:tc(crypto, md5, [Bin1]).
{60,
20,235,111,74,212,254,194,144,49,70,205,105,124,106,
131,230}
5
5 Bin2 = crypto:rand_bytes(8 * 1024).
246,66,158,227,62,127,62,239,202,232,133,244,191,9,136,
6,164,179,109,166,253,41,144,185,177,39,177,88,142,...
6
6 {T3, _} = timer:tc(erlang, md5, [Bin2]).
{446,
7,55,252,42,249,30,58,22,245,12,111,82,131,58,199,51}
7
7 {T4, _} = timer:tc(crypto, md5, [Bin2]).
{77,
7,55,252,42,249,30,58,22,245,12,111,82,131,58,199,51}
8
I know there's a ticket around with the goal of the possibility to remove the
dependency on the crypto module, but for environments where this is not a
problem it would be a plus.
Made a test that wrote 400 attachments with about 60Kbs and noticed an
average response time of 0.16s versus 0.18s (erlang:md5).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-757) use (fast) crypto:md5 instead of (slow) erlang:md5 when available
[
https://issues.apache.org/jira/browse/COUCHDB-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski updated COUCHDB-757:
---
Summary: use (fast) crypto:md5 instead of (slow) erlang:md5 when
available (was: crypto:md5 vs erlang:md5)
Fix Version/s: 1.1
use (fast) crypto:md5 instead of (slow) erlang:md5 when available
-
Key: COUCHDB-757
URL: https://issues.apache.org/jira/browse/COUCHDB-757
Project: CouchDB
Issue Type: Improvement
Environment: GNU/Linux
Reporter: Filipe Manana
Fix For: 1.1
Attachments: crypto_fallback_to_erlang.patch, crypto_md5.patch
Just noticed that crypto:md5 is faster than erlang:md5 by about an order of
magnitude when hashing just 8Kb or 4Kb of data.
Basically we use md5 hashing when writing and reading documents and
attachments through couch_file and couch_stream.
Eshell V5.8 (abort with ^G)
1 crypto:start().
ok
2 Bin1 = crypto:rand_bytes(4 * 1024).
92,239,233,29,1,237,96,193,188,97,4,72,51,90,96,91,187,
112,112,198,7,173,105,99,205,65,105,94,144,...
3
3 {T1, _} = timer:tc(erlang, md5, [Bin1]).
{211,
20,235,111,74,212,254,194,144,49,70,205,105,124,106,
131,230}
4
4 {T2, _} = timer:tc(crypto, md5, [Bin1]).
{60,
20,235,111,74,212,254,194,144,49,70,205,105,124,106,
131,230}
5
5 Bin2 = crypto:rand_bytes(8 * 1024).
246,66,158,227,62,127,62,239,202,232,133,244,191,9,136,
6,164,179,109,166,253,41,144,185,177,39,177,88,142,...
6
6 {T3, _} = timer:tc(erlang, md5, [Bin2]).
{446,
7,55,252,42,249,30,58,22,245,12,111,82,131,58,199,51}
7
7 {T4, _} = timer:tc(crypto, md5, [Bin2]).
{77,
7,55,252,42,249,30,58,22,245,12,111,82,131,58,199,51}
8
I know there's a ticket around with the goal of the possibility to remove the
dependency on the crypto module, but for environments where this is not a
problem it would be a plus.
Made a test that wrote 400 attachments with about 60Kbs and noticed an
average response time of 0.16s versus 0.18s (erlang:md5).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-757) use (fast) crypto:md5 instead of (slow) erlang:md5 when available
[
https://issues.apache.org/jira/browse/COUCHDB-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12863965#action_12863965
]
Filipe Manana commented on COUCHDB-757:
---
True :)
A while back I was thinking about adding a .ini config option, and then adding
a couch_util:md5 based on it. But it could be a bit overkill (md5, md5_init,
md5_update, ...)
So, the try catch is a better fit.
cheers
use (fast) crypto:md5 instead of (slow) erlang:md5 when available
-
Key: COUCHDB-757
URL: https://issues.apache.org/jira/browse/COUCHDB-757
Project: CouchDB
Issue Type: Improvement
Environment: GNU/Linux
Reporter: Filipe Manana
Fix For: 1.1
Attachments: crypto_fallback_to_erlang.patch, crypto_md5.patch
Just noticed that crypto:md5 is faster than erlang:md5 by about an order of
magnitude when hashing just 8Kb or 4Kb of data.
Basically we use md5 hashing when writing and reading documents and
attachments through couch_file and couch_stream.
Eshell V5.8 (abort with ^G)
1 crypto:start().
ok
2 Bin1 = crypto:rand_bytes(4 * 1024).
92,239,233,29,1,237,96,193,188,97,4,72,51,90,96,91,187,
112,112,198,7,173,105,99,205,65,105,94,144,...
3
3 {T1, _} = timer:tc(erlang, md5, [Bin1]).
{211,
20,235,111,74,212,254,194,144,49,70,205,105,124,106,
131,230}
4
4 {T2, _} = timer:tc(crypto, md5, [Bin1]).
{60,
20,235,111,74,212,254,194,144,49,70,205,105,124,106,
131,230}
5
5 Bin2 = crypto:rand_bytes(8 * 1024).
246,66,158,227,62,127,62,239,202,232,133,244,191,9,136,
6,164,179,109,166,253,41,144,185,177,39,177,88,142,...
6
6 {T3, _} = timer:tc(erlang, md5, [Bin2]).
{446,
7,55,252,42,249,30,58,22,245,12,111,82,131,58,199,51}
7
7 {T4, _} = timer:tc(crypto, md5, [Bin2]).
{77,
7,55,252,42,249,30,58,22,245,12,111,82,131,58,199,51}
8
I know there's a ticket around with the goal of the possibility to remove the
dependency on the crypto module, but for environments where this is not a
problem it would be a plus.
Made a test that wrote 400 attachments with about 60Kbs and noticed an
average response time of 0.16s versus 0.18s (erlang:md5).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-757) use (fast) crypto:md5 instead of (slow) erlang:md5 when available
[
https://issues.apache.org/jira/browse/COUCHDB-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski closed COUCHDB-757.
--
Resolution: Fixed
Applied the version with try..catch. Thanks Filipe.
use (fast) crypto:md5 instead of (slow) erlang:md5 when available
-
Key: COUCHDB-757
URL: https://issues.apache.org/jira/browse/COUCHDB-757
Project: CouchDB
Issue Type: Improvement
Environment: GNU/Linux
Reporter: Filipe Manana
Fix For: 1.1
Attachments: crypto_fallback_to_erlang.patch, crypto_md5.patch
Just noticed that crypto:md5 is faster than erlang:md5 by about an order of
magnitude when hashing just 8Kb or 4Kb of data.
Basically we use md5 hashing when writing and reading documents and
attachments through couch_file and couch_stream.
Eshell V5.8 (abort with ^G)
1 crypto:start().
ok
2 Bin1 = crypto:rand_bytes(4 * 1024).
92,239,233,29,1,237,96,193,188,97,4,72,51,90,96,91,187,
112,112,198,7,173,105,99,205,65,105,94,144,...
3
3 {T1, _} = timer:tc(erlang, md5, [Bin1]).
{211,
20,235,111,74,212,254,194,144,49,70,205,105,124,106,
131,230}
4
4 {T2, _} = timer:tc(crypto, md5, [Bin1]).
{60,
20,235,111,74,212,254,194,144,49,70,205,105,124,106,
131,230}
5
5 Bin2 = crypto:rand_bytes(8 * 1024).
246,66,158,227,62,127,62,239,202,232,133,244,191,9,136,
6,164,179,109,166,253,41,144,185,177,39,177,88,142,...
6
6 {T3, _} = timer:tc(erlang, md5, [Bin2]).
{446,
7,55,252,42,249,30,58,22,245,12,111,82,131,58,199,51}
7
7 {T4, _} = timer:tc(crypto, md5, [Bin2]).
{77,
7,55,252,42,249,30,58,22,245,12,111,82,131,58,199,51}
8
I know there's a ticket around with the goal of the possibility to remove the
dependency on the crypto module, but for environments where this is not a
problem it would be a plus.
Made a test that wrote 400 attachments with about 60Kbs and noticed an
average response time of 0.16s versus 0.18s (erlang:md5).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: buildbot failure in ASF Buildbot on couchdb-trunk
How do I force another build? I can't reproduce the test failure locally. Adam On May 4, 2010, at 4:59 PM, build...@apache.org wrote: The Buildbot has detected a new failure of couchdb-trunk on ASF Buildbot. Full details are available at: http://ci.apache.org/builders/couchdb-trunk/builds/306 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: Build Source Stamp: [branch couchdb/trunk] 941033 Blamelist: kocolosk BUILD FAILED: failed compile_5 sincerely, -The ASF Buildbot
Re: buildbot failure in ASF Buildbot on couchdb-trunk
Theoretically, on IRC, its:
couchbot: force build ${BUILDER}
Where ${BUILDER} can currently be couch-trunk or couch-cover.
I know of spurious errors when both builds run at the same time due to
our tests not using random ports when we start a full server. (Both
try and grab port 5984, one fails)
Though currently, couchbot has gone missing. I think there's an email
endpoint but I don't know it off the top of my head.
HTH,
Paul Davis
On Tue, May 4, 2010 at 10:10 PM, Adam Kocoloski kocol...@apache.org wrote:
How do I force another build? I can't reproduce the test failure locally.
Adam
On May 4, 2010, at 4:59 PM, build...@apache.org wrote:
The Buildbot has detected a new failure of couchdb-trunk on ASF Buildbot.
Full details are available at:
http://ci.apache.org/builders/couchdb-trunk/builds/306
Buildbot URL: http://ci.apache.org/
Buildslave for this Build: bb-vm_ubuntu
Build Reason:
Build Source Stamp: [branch couchdb/trunk] 941033
Blamelist: kocolosk
BUILD FAILED: failed compile_5
sincerely,
-The ASF Buildbot
