date:20110628

[
https://issues.apache.org/jira/browse/COUCHDB-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056531#comment-13056531
]

Simon Eisenmann commented on COUCHDB-691:
-

Please close this ticket for now. I will open a new one if I have issues with
CouchDB 1.1 again.

CouchDB pull replication from HTTPS does not recover after disconnect (hangs)
-

Key: COUCHDB-691
URL: https://issues.apache.org/jira/browse/COUCHDB-691
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 0.10.1
Environment: CouchDB 0.10.1 on Ubuntu 9.10 64bit with Nginx 0.7.62.
Reporter: Simon Eisenmann

have several CouchDB instances replicating through untrusted network
space. Thus these instances are behind a Nginx SSL-Proxy. Everything
works fine though when for whatever reason one of the connection breaks
then this pull replication never recovers. Even restarting the
replication job does not have any effect despite not giving an error.
Also in Futon the replication jobs are still reported as running (they
never go away).
I just have set up a local test environment with just two nodes
replicating to each other. One of the nodes is behind Nginx with SSL,
and the other is directly reachable unencrypted. When restarting the
unencrypted instance the pull replication on the other Couch recovers
like a charm and and things are in sync quickly again. Not so when i
restart the instance behind HTTPS. This replication never results in any
action again until the instance doing the pull replication is restarted.
After a couple bit of debugging i found that it seems like the _changes
feed is never again requested from the just restarted instance. As soon
as i restart the instance i get the following entry in the Nginx log:
10.1.1.201 - - [10/Mar/2010:17:40:50 +0100]
GET
/database_1/_changes?style=all_docsheartbeat=1since=3135feed=continuous
HTTP/1.1 200 408 - CouchDB/0.10.1
This means the long running connection has just finished (this was the
former working replication request). Afterwards i would suspect the
Couch to start up such a request again, though this never happens.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (COUCHDB-691) CouchDB pull replication from HTTPS does not recover after disconnect (hangs)

2011-06-28 Thread Filipe Manana (JIRA)

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

Filipe Manana closed COUCHDB-691.
-

Resolution: Fixed
Fix Version/s: 1.0.2
1.1
Assignee: Filipe Manana

Thanks Simon. This should have been fixed in 1.0.2 and 1.1.0

CouchDB pull replication from HTTPS does not recover after disconnect (hangs)
-

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

duplicate erlang files: mochijson2.erl and mochinum.erl

2011-06-28 Thread Andrey Somov

Hi all,
the trunk contains now duplicates for 2 Erlang files: mochijson2.erl and
mochinum.erl
They reside both in 'ejson' and in 'mochiweb' folders.

The content is almost identical (just two lines are swapped)

Is it intentional ?

-
Andrey

Re: duplicate erlang files: mochijson2.erl and mochinum.erl

On Tue, Jun 28, 2011 at 10:52 AM, Andrey Somov
trophyb...@googlemail.com wrote:
 Hi all,
 the trunk contains now duplicates for 2 Erlang files: mochijson2.erl and
 mochinum.erl
 They reside both in 'ejson' and in 'mochiweb' folders.

 The content is almost identical (just two lines are swapped)

 Is it intentional ?

 -
 Andrey


Yeah, the ones in ejson are there simply to reduce the amount of work
required to do fall back to native erlang JSON handling when NIF's
can't be compiled. Ideally we should remove them and patch
couch_util.erl with a compile time directive to pick the proper JSON
routines depending on whether NIF's have been compiled.

Paul

[jira] [Created] (COUCHDB-1204) Cannot pull replicate with HTTPS (using native SSL) but works for same database with HTTP

Cannot pull replicate with HTTPS (using native SSL) but works for same database
with HTTP
-

Key: COUCHDB-1204
URL: https://issues.apache.org/jira/browse/COUCHDB-1204
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.1
Environment: Ubuntu 10.04 64bit, CouchDB 1.1.0, Erlang
1:13.b.3-dfsg-2ubuntu2.1, Spidermonkey 3.5.15
Reporter: Simon Eisenmann

This is the output for the non SSL replication:
{session_id:8703d846d4a90184b5cdc4358ebbdec4,start_time:Tue, 28 Jun 2011
14:57:15 GMT,end_time:Tue, 28 Jun 2011 14:57:40
GMT,start_last_seq:0,end_last_seq:1303811,recorded_seq:1303811,missing_checked:0,missing_found:14965,docs_read:14984,docs_written:14984,doc_write_failures:0}

And this the error on the local CouchDB when trying this through SSL:
0.5735.8, {error,{badinfo,{tcp,#Port0.10031. Futon outputs something like
Replication failed: {bad_term,0.897.9}

The remote Couch does not have any error in the log.To me this seems to be an
issue on the receiving side.

Both Couches are the same version and Platform (Ubuntu 10.04 64bit).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [VOTE] Apache CouchDB 1.0.3 Release

On Mon, Jun 27, 2011 at 5:31 PM, Noah Slater nsla...@apache.org wrote:
 Everything works, except the bits that didn't.

 At the start of running the tests:

 Program received signal EXC_BAD_ACCESS, Could not access memory.
 Reason: KERN_INVALID_ADDRESS at address: 0x107c34f0
 [Switching to process 80613 thread 0x2a03]
 0x107c34f0 in ?? ()
 (gdb) bt
 #0  0x107c34f0 in ?? ()
 Cannot access memory at address 0x107c34f0
 #1  0x7fff88041711 in EVP_DigestInit_ex ()
 #2  0x7fff8800f69d in ssleay_rand_bytes ()
 #3  0x7fff8800ed2e in ssleay_rand_pseudo_bytes ()
 #4  0x1077a85a in rand_bytes_1 ()
 #5  0x100fec37 in process_main ()
 #6  0x1007024e in sched_thread_func ()
 #7  0x1018f7fb in thr_wrapper ()
 #8  0x7fff80398fd6 in _pthread_start ()
 #9  0x7fff80398e89 in thread_start ()

 Then later on, I get this:

 Program received signal SIGPIPE, Broken pipe.
 0x7fff803a3932 in select$DARWIN_EXTSN ()
 (gdb) bt
 #0  0x7fff803a3932 in select$DARWIN_EXTSN ()
 #1  0x1011dfd0 in erts_sys_main_thread ()
 #2  0x100207ef in erl_start ()
 #3  0x100010c9 in main ()

 Blowing away the database, and restarting.

 At this point in the logs:

 [info] [0.1839.0] 127.0.0.1 - - 'GET' /_uuids?count=600 200
 [info] [0.1839.0] 127.0.0.1 - - 'POST' /test_suite_db/_bulk_docs 201
 [info] [0.1839.0] 127.0.0.1 - - 'POST' /test_suite_db/_ensure_full_commit 
 201
 [info] [0.1839.0] 127.0.0.1 - - 'GET' 
 /test_suite_db/_design/test/_view/summate?stale=ok 200
 [info] [0.1839.0] 127.0.0.1 - - 'GET' /test_suite_db/_design/test/_info 200
 [info] [0.1839.0] 127.0.0.1 - - 'GET' 
 /test_suite_db/_design/test/_view/all_docs_twice?stale=ok 200
 [info] [0.1839.0] 127.0.0.1 - - 'GET' 
 /test_suite_db/_design/test/_view/single_doc?stale=ok 200
 [info] [0.1839.0] 127.0.0.1 - - 'GET' 
 /test_suite_db/_design/test/_view/summate?stale=ok 200
 [info] [0.1839.0] 127.0.0.1 - - 'POST' /test_suite_db/_ensure_full_commit 
 201
 [info] [0.1839.0] 127.0.0.1 - - 'POST' /_restart 200
 Apache CouchDB 1.0.3 (LogLevel=info) is starting.


 I get this:

 Program received signal EXC_BAD_ACCESS, Could not access memory.
 Reason: KERN_PROTECTION_FAILURE at address: 0x107c34f0
 [Switching to process 81217 thread 0x2903]
 0x107c34f0 in ?? ()
 (gdb) bt
 #0  0x107c34f0 in ?? ()
 #1  0x7fff88041711 in EVP_DigestInit_ex ()
 #2  0x7fff8800f69d in ssleay_rand_bytes ()
 #3  0x7fff8800ed2e in ssleay_rand_pseudo_bytes ()
 #4  0x107d585a in rand_bytes_1 ()
 #5  0x100fec37 in process_main ()
 #6  0x1007024e in sched_thread_func ()
 #7  0x1018f7fb in thr_wrapper ()
 #8  0x7fff80398fd6 in _pthread_start ()
 #9  0x7fff80398e89 in thread_start ()

 When I quit GDB this was reported as a bus error.

 Reran and at this point in the logs:

 [info] [0.5073.0] Compaction for db test_suite_db_a completed.
 [info] [0.3581.0] 127.0.0.1 - - 'GET' /test_suite_db_a/ 200
 [info] [0.3581.0] 127.0.0.1 - - 'PUT' /test_suite_db_a/30 201
 [info] [0.3581.0] 127.0.0.1 - - 'GET' /_active_tasks 200
 [info] [0.3608.0] 127.0.0.1 - - 'GET' 
 /test_suite_db_a/30?open_revs=[1-2caeb8875a4d87f9dae3535022744785]revs=truelatest=trueatt_encoding_info=true
  200
 [info] [0.3581.0] 127.0.0.1 - - 'GET' /test_suite_db_a/ 200
 [info] [0.3581.0] 127.0.0.1 - - 'GET' /test_suite_db_b/ 200
 [info] [0.3581.0] 127.0.0.1 - - 'GET' /test_suite_db_b/30 200
 [info] [0.3581.0] 127.0.0.1 - - 'POST' /_replicate 200
 [info] [0.3581.0] 127.0.0.1 - - 'DELETE' /test_suite_db_a/ 200

 I got this again:

 Program received signal SIGPIPE, Broken pipe.
 0x7fff803a3932 in select$DARWIN_EXTSN ()
 (gdb) bt
 #0  0x7fff803a3932 in select$DARWIN_EXTSN ()
 #1  0x1011dfd0 in erts_sys_main_thread ()
 #2  0x100207ef in erl_start ()
 #3  0x100010c9 in main ()



I'm constantly impressed that you manage to have an OpenSSL library
installation that segfaults. Is it perhaps possible that I can get a
remote login to this machine to try and debug what's going on? I'm
doubtful but at this point I don't have any better response other than
sending you a link to http://nelsonhaha.com/

HTH,
Paul Davis

[jira] [Commented] (COUCHDB-1204) Cannot pull replicate with HTTPS (using native SSL) but works for same database with HTTP

2011-06-28 Thread Filipe Manana (JIRA)

[
https://issues.apache.org/jira/browse/COUCHDB-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056558#comment-13056558
]

Filipe Manana commented on COUCHDB-1204:

Is it OTP R13B0x you're running?
If so it's a known issue with the OTP release. Try R14.

Cannot pull replicate with HTTPS (using native SSL) but works for same
database with HTTP
-

I just tried out native SSL in CouchDB 1.1. SSL pull replication works fine
for very small databases. Though for long running older databases it never
works. So this means having CouchDB 1.1.0 running on Port 5984 non SSL and on
6984 SSL replication works for the first but not for the second URL (same
source database, same local target).
This is the output for the non SSL replication:
{session_id:8703d846d4a90184b5cdc4358ebbdec4,start_time:Tue, 28 Jun
2011 14:57:15 GMT,end_time:Tue, 28 Jun 2011 14:57:40
GMT,start_last_seq:0,end_last_seq:1303811,recorded_seq:1303811,missing_checked:0,missing_found:14965,docs_read:14984,docs_written:14984,doc_write_failures:0}
And this the error on the local CouchDB when trying this through SSL:
0.5735.8, {error,{badinfo,{tcp,#Port0.10031. Futon outputs something
like Replication failed: {bad_term,0.897.9}
The remote Couch does not have any error in the log.To me this seems to be an
issue on the receiving side.
Both Couches are the same version and Platform (Ubuntu 10.04 64bit).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COUCHDB-1204) Cannot pull replicate with HTTPS (using native SSL) but works for same database with HTTP

[
https://issues.apache.org/jira/browse/COUCHDB-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056559#comment-13056559
]

Simon Eisenmann commented on COUCHDB-1204:
--

Ok - that was quick. Indeed this is R13B03.

Checking out with R14 (wherever i get that from :-)). Thanks!

Cannot pull replicate with HTTPS (using native SSL) but works for same
database with HTTP
-

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COUCHDB-1204) Cannot pull replicate with HTTPS (using native SSL) but works for same database with HTTP


[ 
https://issues.apache.org/jira/browse/COUCHDB-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056565#comment-13056565
 ] 

Simon Eisenmann commented on COUCHDB-1204:
--

Yes thanks - though for deployment reasons i require Packages for Ubuntu 10.04. 
Going to Backport 
http://archive.ubuntu.com/ubuntu/pool/main/e/erlang/erlang_14.b.2-dfsg-3ubuntu2.dsc
 now.

 Cannot pull replicate with HTTPS (using native SSL) but works for same 
 database with HTTP
 -

 Key: COUCHDB-1204
 URL: https://issues.apache.org/jira/browse/COUCHDB-1204
 Project: CouchDB
  Issue Type: Bug
  Components: Replication
Affects Versions: 1.1
 Environment: Ubuntu 10.04 64bit, CouchDB 1.1.0, Erlang 
 1:13.b.3-dfsg-2ubuntu2.1, Spidermonkey 3.5.15
Reporter: Simon Eisenmann
  Labels: SSL, pull, replication

 I just tried out native SSL in CouchDB 1.1. SSL pull replication works fine 
 for very small databases. Though for long running older databases it never 
 works. So this means having CouchDB 1.1.0 running on Port 5984 non SSL and on 
 6984 SSL replication works for the first but not for the second URL (same 
 source database, same local target).
 This is the output for the non SSL replication:
 {session_id:8703d846d4a90184b5cdc4358ebbdec4,start_time:Tue, 28 Jun 
 2011 14:57:15 GMT,end_time:Tue, 28 Jun 2011 14:57:40 
 GMT,start_last_seq:0,end_last_seq:1303811,recorded_seq:1303811,missing_checked:0,missing_found:14965,docs_read:14984,docs_written:14984,doc_write_failures:0}
 And this the error on the local CouchDB when trying this through SSL:
 0.5735.8,  {error,{badinfo,{tcp,#Port0.10031.  Futon outputs something 
 like Replication failed: {bad_term,0.897.9}
 The remote Couch does not have any error in the log.To me this seems to be an 
 issue on the receiving side.
 Both Couches are the same version and Platform (Ubuntu 10.04 64bit). 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [Couchdb Wiki] Update of CouchDB_in_the_wild by PaulDavis


On 28 Jun 2011, at 16:00, Apache Wiki wrote:

 - * [[http://www.weddingdjmelbourne.com/|weddings DJ Melbourne]] WDM is a DJ 
 service. We use CouchDB in our database.

Wow.

So, the spammers are actually reading the warning at the top of the page, and 
then pretending to use CouchDB in [their] database. Kind of makes me want to 
just give trying. If you're reading this, Mr. Spamy McSpamface, Y U NO INSTALL 
SUM ETHICS IN UR DATABASE ASWEL?

Re: [VOTE] Apache CouchDB 1.0.3 Release


On 28 Jun 2011, at 10:51, Sebastian Cohnen wrote:

 ./test/javascript/run: NOT OK, but I guess that's okay for now
 - not ok 3 attachment_names expected 'Created', got 'null'
 - not ok 26 form_submit false
 - not ok 44 replication ReferenceError: $ is not defined
 futon test suite (Safari 5.0.5): OK

None of the tests should fail.

I've said this before and I will say it again. The test suite forms a contract 
between the devs and the release team, and between the release team and the 
user. If they are expected to fail, they are next to useless.

Perhaps there is some good reason for them failing?

Re: duplicate erlang files: mochijson2.erl and mochinum.erl

2011-06-28 Thread Andrey Somov

Thank you.

I noticed it because erlIDE cannot compile the source.

-
Andrey

Re: [VOTE] Apache CouchDB 1.0.3 Release

2011-06-28 Thread Jan Lehnardt


On 28 Jun 2011, at 11:51, Sebastian Cohnen wrote:

 OS X 10.6.8, R14B03
 
 md5sum: OK
 sha1sum: OK
 gpg: Good signature from Paul J. Davis (CODE SIGNING KEY) 
 dav...@apache.org - OK
 make check: OK
 ./test/javascript/run: NOT OK, but I guess that's okay for now
 - not ok 3 attachment_names expected 'Created', got 'null'
 - not ok 26 form_submit false
 - not ok 44 replication ReferenceError: $ is not defined
 futon test suite (Safari 5.0.5): OK

Can you try clearing the cache or try Chrome?

Cheers
Jan
-- 

 
 +1
 
 Great work!
 
 On 25.06.2011, at 01:54, Paul Davis wrote:
 
 This is the release vote for Apache CouchDB 1.0.3
 
 Changes in this release:
 
 * Fixed compatibility issues with Erlang R14B02.
 * Fix bug that allows invalid UTF-8 after valid escapes.
 * The query parameter `include_docs` now honors the parameter `conflicts`.
  This applies to queries against map views, _all_docs and _changes.
 * Added support for inclusive_end with reduce views.
 * More performant queries against _changes and _all_docs when using the
 `include_docs` parameter.
 * Enabled replication over IPv6.
 * Fixed for crashes in continuous and filtered changes feeds.
 * Fixed error when restarting replications in OTP R14B02.
 * Upgrade ibrowse to version 2.2.0.
 * Fixed bug when using a filter and a limit of 1.
 * Fixed OAuth signature computation in OTP R14B02.
 * Handle passwords with : in them.
 * Made compatible with jQuery 1.5.x.
 * Etap tests no longer require use of port 5984. They now use a randomly
  selected port so they won't clash with a running CouchDB.
 * Windows builds now require ICU = 4.4.0 and Erlang = R14B03. See
  COUCHDB-1152, and COUCHDB-963 + OTP-9139 for more information.
 
 We encourage the whole community to download and test these release
 artifacts so that any critical issues can be resolved before the release
 is made. Everyone is free to vote on this release. Please report your
 results and vote to this thread.
 
 We are voting on the following release artifacts:
 
 http://people.apache.org/~davisp/dist/1.0.3-rc1/
 
 Instructions for validating the release tarball can be found here:
 
 http://people.apache.org/~davisp/dist/
 
 Instructions for testing the build artefacts can be found here:
 
 http://wiki.apache.org/couchdb/Test_procedure
 
 These artifacts have been built from the 1.0.3 tag in Subversion:
 
 http://svn.apache.org/repos/asf/couchdb/tags/1.0.3/
 
 At some point this weekend you will be bored with nothing to do for
 ten to fifteen minutes, this is when you should vote.

Re: [VOTE] Apache CouchDB 1.0.3 Release

2011-06-28 Thread Sebastian Cohnen

On 28.06.2011, at 17:57, Noah Slater wrote:

 On 28 Jun 2011, at 10:51, Sebastian Cohnen wrote:
 
 ./test/javascript/run: NOT OK, but I guess that's okay for now
 - not ok 3 attachment_names expected 'Created', got 'null'
 - not ok 26 form_submit false
 - not ok 44 replication ReferenceError: $ is not defined
 futon test suite (Safari 5.0.5): OK
 
 None of the tests should fail.
 
 I've said this before and I will say it again. The test suite forms a 
 contract between the devs and the release team, and between the release team 
 and the user. If they are expected to fail, they are next to useless.
 
 Perhaps there is some good reason for them failing?

I was not aware that the javascript CLI tests are officially ready to use 
yet. In that case it's definitely not okay if they are failing and since others 
have seen the same failing tests, I'd change my vote to −1.

Re: [VOTE] Apache CouchDB 1.0.3 Release


On 28 Jun 2011, at 17:09, Sebastian Cohnen wrote:

 Perhaps there is some good reason for them failing?
 
 I was not aware that the javascript CLI tests are officially ready to use 
 yet. In that case it's definitely not okay if they are failing and since 
 others have seen the same failing tests, I'd change my vote to −1.

If they are not ready to use yet, that is a good reason for them failing. If 
they should be part of the test procedure, then they should a) pass and b) be 
added to the wiki. Sorry for being so ARGH about it, but I like to run a tight 
ship, so we should get clarification on this either way. Thanks!

Re: [VOTE] Apache CouchDB 1.0.3 Release

2011-06-28 Thread Jan Lehnardt


On 28 Jun 2011, at 18:11, Noah Slater wrote:

 
 On 28 Jun 2011, at 17:09, Sebastian Cohnen wrote:
 
 Perhaps there is some good reason for them failing?
 
 I was not aware that the javascript CLI tests are officially ready to use 
 yet. In that case it's definitely not okay if they are failing and since 
 others have seen the same failing tests, I'd change my vote to −1.
 
 If they are not ready to use yet, that is a good reason for them failing. If 
 they should be part of the test procedure, then they should a) pass and b) be 
 added to the wiki. Sorry for being so ARGH about it, but I like to run a 
 tight ship, so we should get clarification on this either way. Thanks!

It's all good Noah, I'm 100% behind you here :)

Sebastian, sorry, I didn't see you were running the still experimental CLI 
tests.

Cheers
Jan
--

Re: [VOTE] Apache CouchDB 1.0.3 Release

2011-06-28 Thread Sebastian Cohnen


On 28.06.2011, at 18:11, Noah Slater wrote:

 
 On 28 Jun 2011, at 17:09, Sebastian Cohnen wrote:
 
 Perhaps there is some good reason for them failing?
 
 I was not aware that the javascript CLI tests are officially ready to use 
 yet. In that case it's definitely not okay if they are failing and since 
 others have seen the same failing tests, I'd change my vote to −1.
 
 If they are not ready to use yet, that is a good reason for them failing. If 
 they should be part of the test procedure, then they should a) pass and b) be 
 added to the wiki. Sorry for being so ARGH about it, but I like to run a 
 tight ship, so we should get clarification on this either way. Thanks!
 

I'm sorry Noah. You are right, they are not part of the test procedure 
(according to http://wiki.apache.org/couchdb/Test_procedure). Therefor I think 
it's okay for them to fail.

So let's ship that thing!

+1

Re: [VOTE] Apache CouchDB 1.0.3 Release

2011-06-28 Thread Robert Dionne

I don't think they are officially part of the test procedure, if so then 
we've shipped a lot of releases with them failing. In fact they never run 
completely, once in a blue moon. Perhaps I shouldn't have mentioned it in my +1 
vote. I run them almost every time I do a build from trunk, almost always the 
issues are related to the two different JS execution environments. I've started 
a topic branch to separate out [1] these tests from the browser based Futon 
tests. Ideally these would be part of make check.

SHIP IT!!!


[1] https://github.com/bdionne/couchdb/tree/cli-tests




On Jun 28, 2011, at 12:11 PM, Noah Slater wrote:

 
 On 28 Jun 2011, at 17:09, Sebastian Cohnen wrote:
 
 Perhaps there is some good reason for them failing?
 
 I was not aware that the javascript CLI tests are officially ready to use 
 yet. In that case it's definitely not okay if they are failing and since 
 others have seen the same failing tests, I'd change my vote to −1.
 
 If they are not ready to use yet, that is a good reason for them failing. If 
 they should be part of the test procedure, then they should a) pass and b) be 
 added to the wiki. Sorry for being so ARGH about it, but I like to run a 
 tight ship, so we should get clarification on this either way. Thanks!

[jira] [Commented] (COUCHDB-1204) Cannot pull replicate with HTTPS (using native SSL) but works for same database with HTTP

[
https://issues.apache.org/jira/browse/COUCHDB-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056633#comment-13056633
]

Simon Eisenmann commented on COUCHDB-1204:
--

I upgrade erlang to 14.b.2 and now it works just fine. Thanks!

Cannot pull replicate with HTTPS (using native SSL) but works for same
database with HTTP
-

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (COUCHDB-1204) Cannot pull replicate with HTTPS (using native SSL) but works for same database with HTTP

2011-06-28 Thread Filipe Manana (JIRA)

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

Filipe Manana resolved COUCHDB-1204.

Resolution: Not A Problem

You're welcome Simon.
Please reopen the ticket if you find other SSL related issues when pull
replicating.

Cannot pull replicate with HTTPS (using native SSL) but works for same
database with HTTP
-

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [VOTE] Apache CouchDB 1.0.3 Release

On Tue, Jun 28, 2011 at 11:57 AM, Noah Slater nsla...@apache.org wrote:

 On 28 Jun 2011, at 10:51, Sebastian Cohnen wrote:

 ./test/javascript/run: NOT OK, but I guess that's okay for now
 - not ok 3 attachment_names expected 'Created', got 'null'
 - not ok 26 form_submit false
 - not ok 44 replication ReferenceError: $ is not defined
 futon test suite (Safari 5.0.5): OK

 None of the tests should fail.

 I've said this before and I will say it again. The test suite forms a 
 contract between the devs and the release team, and between the release team 
 and the user. If they are expected to fail, they are next to useless.

 Perhaps there is some good reason for them failing?



Dear Noah Slater,

These tests fail because the JS environment on the command line does
not support asynchronous XHR because that would require me to write
lots of whacky C to support a handful of assertions. These are not
part of the official test suite because they require a live server to
be opened and I wasn't good enough to figure out a way to be extra
sure to make sure the server doesn't linger around after the tests
have run. Also, it'd be good to configure things to use a random port
as well. Also, making them official makes the curl dependency
non-optional for release managers and testers, so there's also that.

Yours truly,
Paul Davis

MapServer and CouchDB

2011-06-28 Thread Norman Barker

Hi,

I am planning to wrap MapServer as a supervised process within CouchDB
using Erlang. MapServer is a CGI application, it should be
straightforward. The aim will be to store the MapServer map files
(just text docs) that can passed in with every CGI call as JSON docs
within CouchDB. The hook will be be register MapServer as an external
process within CouchDB.

If someone has already thought of this then let me know, I see GDAL
has support for CouchDB as a client driver (using http though) so
serving geojson through MapServer WFS or rendering over WMS should be
possible.

Let me know if you are interested, I should have some available for
review middle of next week, I am just sounding out for now.

The Erlang method of communication to C/C++ over stdio fits (in my
mind) perfectly with the existing MapServer CGI model. GeoCouch can
then be a supported backend of MapServer.

cc'd Frank and Even rather than cross-posting as they seem to have
some couch interest.

thanks,

Norman

Re: [VOTE] Apache CouchDB 1.0.3 Release


On 28 Jun 2011, at 19:24, Paul Davis wrote:

 Yours truly,
 Paul Davis

Received, and understood.

Ever handsome,

Mr. Noah Slater Esq.

SpiderMonkey Version Support

2011-06-28 Thread Randall Leeds

I recently committed a patch from Chris Coulson to support the new
1.8.5 release of SpiderMonkey[1].

While some effort was put into supporting the breaking changes from
1.8.5 and it's been verified that the new trunk couchjs builds against
the rest of the 1.8 series, Bob Dionne discovered that compatibility
with 1.7 is now broken.

davisp You dropped support for 1.7?
tilgovi davisp: apparenty!
tilgovi what's the 1.0.x branch say in INSTALL.*?
davisp tilgovi: On purpose though?
tilgovi no
davisp I'm really confused
tilgovi not on purpose
davisp 1.7 I'm guessing
tilgovi also, I didn't backport this
tilgovi so, this is only on trunk
davisp 1.8
davisp I guess its lying
tilgovi I guess it's lying.
davisp tilgovi: Sure, I would've screamed at yo otherwise
tilgovi thoughts on not bothering to try and support 1.7?
davisp tilgovi: I'm of two minds on whether I want to drop 1.7 support
tilgovi might be super easy
davisp But I think jan said he wanted 1.7 support in 1.2 so I said, k

So 1.0.x, 1.1.x and trunk all seem to say we require SpiderMonkey 1.8,
but up until this patch couchjs ran against 1.7.
Should I back out the patch and try to fix compatibility with 1.7 or not bother?

-Randall

[1] 
https://github.com/apache/couchdb/commit/7b0f330627c9f3ef1ccb9e3ffe1e909e3a27f1bf

Re: SpiderMonkey Version Support

On Tue, Jun 28, 2011 at 6:41 PM, Randall Leeds rand...@apache.org wrote:
 I recently committed a patch from Chris Coulson to support the new
 1.8.5 release of SpiderMonkey[1].

 While some effort was put into supporting the breaking changes from
 1.8.5 and it's been verified that the new trunk couchjs builds against
 the rest of the 1.8 series, Bob Dionne discovered that compatibility
 with 1.7 is now broken.

 davisp You dropped support for 1.7?
 tilgovi davisp: apparenty!
 tilgovi what's the 1.0.x branch say in INSTALL.*?
 davisp tilgovi: On purpose though?
 tilgovi no
 davisp I'm really confused
 tilgovi not on purpose
 davisp 1.7 I'm guessing
 tilgovi also, I didn't backport this
 tilgovi so, this is only on trunk
 davisp 1.8
 davisp I guess its lying
 tilgovi I guess it's lying.
 davisp tilgovi: Sure, I would've screamed at yo otherwise
 tilgovi thoughts on not bothering to try and support 1.7?
 davisp tilgovi: I'm of two minds on whether I want to drop 1.7 support
 tilgovi might be super easy
 davisp But I think jan said he wanted 1.7 support in 1.2 so I said, k

 So 1.0.x, 1.1.x and trunk all seem to say we require SpiderMonkey 1.8,
 but up until this patch couchjs ran against 1.7.
 Should I back out the patch and try to fix compatibility with 1.7 or not 
 bother?

 -Randall

 [1] 
 https://github.com/apache/couchdb/commit/7b0f330627c9f3ef1ccb9e3ffe1e909e3a27f1bf


I would say if you think its close that you should try and make it
compatible with 1.7 again. I wouldn't immediately jump to backing it
out unless you think it'll take a significant amount of time to bring
back compatibility with 1.7.

On the other hand, if people want to dump 1.7 support I would vote in
favor of dropping support for everything before 1.8.5. The source to
couchjs would be greatly simplified and everything between 1.7 and
1.8.5 was never really an official SM release.

Re: SpiderMonkey Version Support

2011-06-28 Thread Randall Leeds

On Tue, Jun 28, 2011 at 15:54, Paul Davis paul.joseph.da...@gmail.com wrote:
 On Tue, Jun 28, 2011 at 6:41 PM, Randall Leeds rand...@apache.org wrote:
 I recently committed a patch from Chris Coulson to support the new
 1.8.5 release of SpiderMonkey[1].

 While some effort was put into supporting the breaking changes from
 1.8.5 and it's been verified that the new trunk couchjs builds against
 the rest of the 1.8 series, Bob Dionne discovered that compatibility
 with 1.7 is now broken.

 davisp You dropped support for 1.7?
 tilgovi davisp: apparenty!
 tilgovi what's the 1.0.x branch say in INSTALL.*?
 davisp tilgovi: On purpose though?
 tilgovi no
 davisp I'm really confused
 tilgovi not on purpose
 davisp 1.7 I'm guessing
 tilgovi also, I didn't backport this
 tilgovi so, this is only on trunk
 davisp 1.8
 davisp I guess its lying
 tilgovi I guess it's lying.
 davisp tilgovi: Sure, I would've screamed at yo otherwise
 tilgovi thoughts on not bothering to try and support 1.7?
 davisp tilgovi: I'm of two minds on whether I want to drop 1.7 support
 tilgovi might be super easy
 davisp But I think jan said he wanted 1.7 support in 1.2 so I said, k

 So 1.0.x, 1.1.x and trunk all seem to say we require SpiderMonkey 1.8,
 but up until this patch couchjs ran against 1.7.
 Should I back out the patch and try to fix compatibility with 1.7 or not 
 bother?

 -Randall

 [1] 
 https://github.com/apache/couchdb/commit/7b0f330627c9f3ef1ccb9e3ffe1e909e3a27f1bf


 I would say if you think its close that you should try and make it
 compatible with 1.7 again. I wouldn't immediately jump to backing it
 out unless you think it'll take a significant amount of time to bring
 back compatibility with 1.7.

Good point. I won't back it out, but please give me your opinions here.
I think it'd be fairly easy.


 On the other hand, if people want to dump 1.7 support I would vote in
 favor of dropping support for everything before 1.8.5. The source to
 couchjs would be greatly simplified and everything between 1.7 and
 1.8.5 was never really an official SM release.


However, this is a *really* good point.
If there really hasn't been an official release since 1.7 I'd like to
support it.
We'll continue to support 1.1.x until 1.3 (2.0?) is out, so maybe it's
okay to let that be the SM 1.7-compatible line and bump to 1.8.5 for
CouchDB 1.2.

Moar feedback.

Re: SpiderMonkey Version Support

On Tue, Jun 28, 2011 at 7:06 PM, Randall Leeds randall.le...@gmail.com wrote:
 On Tue, Jun 28, 2011 at 15:54, Paul Davis paul.joseph.da...@gmail.com wrote:
 On Tue, Jun 28, 2011 at 6:41 PM, Randall Leeds rand...@apache.org wrote:
 I recently committed a patch from Chris Coulson to support the new
 1.8.5 release of SpiderMonkey[1].

 While some effort was put into supporting the breaking changes from
 1.8.5 and it's been verified that the new trunk couchjs builds against
 the rest of the 1.8 series, Bob Dionne discovered that compatibility
 with 1.7 is now broken.

 davisp You dropped support for 1.7?
 tilgovi davisp: apparenty!
 tilgovi what's the 1.0.x branch say in INSTALL.*?
 davisp tilgovi: On purpose though?
 tilgovi no
 davisp I'm really confused
 tilgovi not on purpose
 davisp 1.7 I'm guessing
 tilgovi also, I didn't backport this
 tilgovi so, this is only on trunk
 davisp 1.8
 davisp I guess its lying
 tilgovi I guess it's lying.
 davisp tilgovi: Sure, I would've screamed at yo otherwise
 tilgovi thoughts on not bothering to try and support 1.7?
 davisp tilgovi: I'm of two minds on whether I want to drop 1.7 support
 tilgovi might be super easy
 davisp But I think jan said he wanted 1.7 support in 1.2 so I said, 
 k

 So 1.0.x, 1.1.x and trunk all seem to say we require SpiderMonkey 1.8,
 but up until this patch couchjs ran against 1.7.
 Should I back out the patch and try to fix compatibility with 1.7 or not 
 bother?

 -Randall

 [1] 
 https://github.com/apache/couchdb/commit/7b0f330627c9f3ef1ccb9e3ffe1e909e3a27f1bf


 I would say if you think its close that you should try and make it
 compatible with 1.7 again. I wouldn't immediately jump to backing it
 out unless you think it'll take a significant amount of time to bring
 back compatibility with 1.7.

 Good point. I won't back it out, but please give me your opinions here.
 I think it'd be fairly easy.


 On the other hand, if people want to dump 1.7 support I would vote in
 favor of dropping support for everything before 1.8.5. The source to
 couchjs would be greatly simplified and everything between 1.7 and
 1.8.5 was never really an official SM release.


 However, this is a *really* good point.
 If there really hasn't been an official release since 1.7 I'd like to
 support it.
 We'll continue to support 1.1.x until 1.3 (2.0?) is out, so maybe it's
 okay to let that be the SM 1.7-compatible line and bump to 1.8.5 for
 CouchDB 1.2.

 Moar feedback.


*Nothing* should change on anything that isn't trunk.

Since 1.2 isn't more than a reference to trunk, there's not much (IMO)
keeping us from dropping our support for everything pre-1.8.5 (except
being nice to users I guess).

Re: [Couchdb Wiki] Update of CouchDB_in_the_wild by PaulDavis

2011-06-28 Thread Chris Anderson

On Tue, Jun 28, 2011 at 8:54 AM, Noah Slater nsla...@apache.org wrote:

 On 28 Jun 2011, at 16:00, Apache Wiki wrote:

 - * [[http://www.weddingdjmelbourne.com/|weddings DJ Melbourne]] WDM is a DJ 
 service. We use CouchDB in our database.

 Wow.

 So, the spammers are actually reading the warning at the top of the page, and 
 then pretending to use CouchDB in [their] database. Kind of makes me want 
 to just give trying. If you're reading this, Mr. Spamy McSpamface, Y U NO 
 INSTALL SUM ETHICS IN UR DATABASE ASWEL?

Noah I have a present for you:
http://200967.spreadshirt.com/men-s-heavyweight-t-shirt-A7726440/customize/color/1

-- 
Chris Anderson
http://jchrisa.net
http://couchbase.com

Re: [Couchdb Wiki] Update of CouchDB_in_the_wild by PaulDavis

2011-06-28 Thread Ryan Ramage

meme awesome. Me wants more couch in my db.

On Tue, Jun 28, 2011 at 5:43 PM, Chris Anderson jch...@apache.org wrote:

 On Tue, Jun 28, 2011 at 8:54 AM, Noah Slater nsla...@apache.org wrote:
 
  On 28 Jun 2011, at 16:00, Apache Wiki wrote:
 
  - * [[http://www.weddingdjmelbourne.com/|weddings DJ Melbourne]] WDM is
 a DJ service. We use CouchDB in our database.
 
  Wow.
 
  So, the spammers are actually reading the warning at the top of the page,
 and then pretending to use CouchDB in [their] database. Kind of makes me
 want to just give trying. If you're reading this, Mr. Spamy McSpamface, Y U
 NO INSTALL SUM ETHICS IN UR DATABASE ASWEL?

 Noah I have a present for you:

 http://200967.spreadshirt.com/men-s-heavyweight-t-shirt-A7726440/customize/color/1

 --
 Chris Anderson
 http://jchrisa.net
 http://couchbase.com




-- 
Twitter: @eckoit
http://eckoit.com - Keep what you hear.
http://opendoorstories.com  - Create Experiences

Re: [Couchdb Wiki] Update of CouchDB_in_the_wild by PaulDavis