[jira] [Commented] (COUCHDB-1093) Exceptions related to _changes + compact
[
https://issues.apache.org/jira/browse/COUCHDB-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009095#comment-13009095
]
Daniel Truemper commented on COUCHDB-1093:
--
Hi there,
exactly the same issue here for me. I am running on a 64bit kernel (Debian).
Daniel
Exceptions related to _changes + compact
Key: COUCHDB-1093
URL: https://issues.apache.org/jira/browse/COUCHDB-1093
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 1.0.2
Environment: I don't believe this is OS and/or hardware elated, but
I'm running on a redhat 32-bit linux kernel
Reporter: kowsik
Labels: exception
From the last thread on the dev mailing list:
On Fri, Mar 18, 2011 at 10:54 AM, Filipe David Manana fdman...@apache.org
wrote:
Ah,
I think the issue is while we are folding the by sequence btree, we
are not checking if the database file changed. So if compaction
finishes before finishing the btree fold, we reach that error.
I can't see right now any other situation, involving _changes, that
might cause that issue.
On Fri, Mar 18, 2011 at 5:40 PM, kowsik kow...@gmail.com wrote:
Been seeing this on our production CouchDB's (1.0.2) sporadically. We
are using the _changes feed, background view indexing and automatic
compaction.
Uncaught error in HTTP request: {exit,
{noproc,
{gen_server,call,
[0.1478.0,
{pread_iolist,290916},
infinity]}}}
Stacktrace: [{gen_server,call,3},
{couch_file,pread_iolist,2},
{couch_file,pread_binary,2},
{couch_file,pread_term,2},
{couch_db,make_doc,5},
{couch_db,open_doc_int,3},
{couch_db,open_doc,3},
{couch_changes,'-make_filter_fun/4-lc$^4/1-3-',2}]
Not reproducible yet, but it seems compacting while there are active
_changes listeners seems to trigger this. After the exception the
_changes listeners are disconnected which then connect back and
everything goes back to normal. beam itself holds up, though last
night it terminated with no logs, nothing. Just poof. Any ideas?
Thanks,
K.
---
http://blitz.io
http://twitter.com/pcapr
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1093) Exceptions related to _changes + compact
[
https://issues.apache.org/jira/browse/COUCHDB-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009109#comment-13009109
]
Daniel Truemper commented on COUCHDB-1093:
--
I'd be happy to test the patch when you have finished it!
Exceptions related to _changes + compact
Key: COUCHDB-1093
URL: https://issues.apache.org/jira/browse/COUCHDB-1093
Project: CouchDB
Issue Type: Bug
Components: Database Core
Affects Versions: 1.0.2
Environment: I don't believe this is OS and/or hardware elated, but
I'm running on a redhat 32-bit linux kernel
Reporter: kowsik
Assignee: Filipe Manana
Labels: exception
From the last thread on the dev mailing list:
On Fri, Mar 18, 2011 at 10:54 AM, Filipe David Manana fdman...@apache.org
wrote:
Ah,
I think the issue is while we are folding the by sequence btree, we
are not checking if the database file changed. So if compaction
finishes before finishing the btree fold, we reach that error.
I can't see right now any other situation, involving _changes, that
might cause that issue.
On Fri, Mar 18, 2011 at 5:40 PM, kowsik kow...@gmail.com wrote:
Been seeing this on our production CouchDB's (1.0.2) sporadically. We
are using the _changes feed, background view indexing and automatic
compaction.
Uncaught error in HTTP request: {exit,
{noproc,
{gen_server,call,
[0.1478.0,
{pread_iolist,290916},
infinity]}}}
Stacktrace: [{gen_server,call,3},
{couch_file,pread_iolist,2},
{couch_file,pread_binary,2},
{couch_file,pread_term,2},
{couch_db,make_doc,5},
{couch_db,open_doc_int,3},
{couch_db,open_doc,3},
{couch_changes,'-make_filter_fun/4-lc$^4/1-3-',2}]
Not reproducible yet, but it seems compacting while there are active
_changes listeners seems to trigger this. After the exception the
_changes listeners are disconnected which then connect back and
everything goes back to normal. beam itself holds up, though last
night it terminated with no logs, nothing. Just poof. Any ideas?
Thanks,
K.
---
http://blitz.io
http://twitter.com/pcapr
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COUCHDB-720) Pull replication fails due to 401 Authentication required while push replication works fine
[ https://issues.apache.org/jira/browse/COUCHDB-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12879284#action_12879284 ] Daniel Truemper commented on COUCHDB-720: - Oh, sorry, kind of forgot about this ticket! At one point I decided to install nginx from source and finally got everything working with this configuration: http://www.friendpaste.com/2VzN9vD63KV6JDUWQdIT1X Strangely I was not able to reproduce the error! So now, everything works as I'd expected it! Best Daniel Pull replication fails due to 401 Authentication required while push replication works fine - Key: COUCHDB-720 URL: https://issues.apache.org/jira/browse/COUCHDB-720 Project: CouchDB Issue Type: Bug Components: Futon, HTTP Interface, Replication Affects Versions: 0.10.1, 0.11 Environment: Remote server having Nginx reverse proxy and basic authentication enabled Reporter: Jochen Kempf Priority: Blocker Pull replication fails using both Futon Replicator and http request throwing an 401 Authentication required error. This just happens when design documents are existent. Push replication on the other hand works fine. See used code here: http://gist.github.com/364072 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-720) Pull replication fails due to 401 Authentication required while push replication works fine
[ https://issues.apache.org/jira/browse/COUCHDB-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12865731#action_12865731 ] Daniel Truemper commented on COUCHDB-720: - @Filipe: no, exactly the same behaviour. @Jochen: yes, the number of replicated documents vary. Seems like the way you described it: once the _design doc is reached, pull replication stops. Regarding the SSL cert: I am using a CA that I created for this with a server cert signed by that CA. Where do you get the invalid ssl error? CouchDB Server/Client? Pull replication fails due to 401 Authentication required while push replication works fine - Key: COUCHDB-720 URL: https://issues.apache.org/jira/browse/COUCHDB-720 Project: CouchDB Issue Type: Bug Components: Futon, HTTP Interface, Replication Affects Versions: 0.10.1, 0.11 Environment: Remote server having Nginx reverse proxy and basic authentication enabled Reporter: Jochen Kempf Priority: Blocker Pull replication fails using both Futon Replicator and http request throwing an 401 Authentication required error. This just happens when design documents are existent. Push replication on the other hand works fine. See used code here: http://gist.github.com/364072 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-720) Pull replication fails due to 401 Authentication required while push replication works fine
[ https://issues.apache.org/jira/browse/COUCHDB-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12864698#action_12864698 ] Daniel Truemper commented on COUCHDB-720: - Hi, I just experienced the same behaviour but have some more background information. I have an nginx reverse proxy for the ssl stuff. On both DBs there are users and admins. From the client DB I am now trying to do the following in Futon: - start replication from https://$user:pas...@$server:5984/$db to http://localhost:5984/$db (on the local machine I am already logged in and on both DBs I am admin). When I try to replicate using pull replication, all documents are replicated except the design document. At the time the replicator tries to GET the design document a HTTP 401 is being sent from the server DB. When I do the same using push replication the design document is being replicated. I am unsure if this is intentional but if so I could use a little help ;). Best Daniel Pull replication fails due to 401 Authentication required while push replication works fine - Key: COUCHDB-720 URL: https://issues.apache.org/jira/browse/COUCHDB-720 Project: CouchDB Issue Type: Bug Components: Futon, HTTP Interface, Replication Affects Versions: 0.10.1, 0.11 Environment: Remote server having Nginx reverse proxy and basic authentication enabled Reporter: Jochen Kempf Priority: Blocker Pull replication fails using both Futon Replicator and http request throwing an 401 Authentication required error. This just happens when design documents are existent. Push replication on the other hand works fine. See used code here: http://gist.github.com/364072 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
