[jira] [Commented] (COUCHDB-1359) Spurious checkpoint failure: conflict (are you replicating to yourself?)
[
https://issues.apache.org/jira/browse/COUCHDB-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13170840#comment-13170840
]
Mathias Leppich commented on COUCHDB-1359:
--
I ran into the same issue. I was replicating from couch-A (version 1.0.3) to
couch-B (version 1.1.1) via couch-B:
curl -X POST -H 'Content-Type: application/json' -d '{
source:some-db,
target:http://couch-A/some-db;,
filter:filters_erl/no_design,
continuous:true
}' 'http://couch-B/_replicate'
Then suddenly (after more than 2 days of replication) I got the following error
in the log:
[Thu, 15 Dec 2011 19:10:00 GMT] [error] [0.259.0] checkpoint failure:
conflict (are you replicating to yourself?)
And the replication stopped replicating but still showing up in _active_tasks.
It did not started replicating again until I canceled the replication and
re-initiated it again. So no couchrestart required, but I had to first cancel
then restart the replication.
I might have to add that even thou these 2 couches have a different version,
they are both based on the same database file. So couch-B was created from a
filesystem snapshot of couch-A. The size of both DB's is about 52M doc with 70M
seq.
Spurious checkpoint failure: conflict (are you replicating to yourself?)
--
Key: COUCHDB-1359
URL: https://issues.apache.org/jira/browse/COUCHDB-1359
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.1.1
Environment: Centos 5.6/x64 - spidermonkey 1.8.5, couch 1.1.1 patched
for COUCHDB-1333 and COUCHDB-1340
Reporter: Alex Markham
Labels: PUT, _local, checkpoint, conflict, replication, slow
I'm seeing these errors in the log when couch just stops replicating (even
though it appears in _active_tasks it doesn't checkpoint again, even with
_replicate being called every 5 mins)
It seems to occur when replicating from a couch 1.1.1 (I have seen it on
1.0.3 machines replicating from 1.1.1)
It definitely is not replicating to itself, but I suspect it is a problem in
PUTing the _local doc on the source db.
log here (snipped from host33 couch.log):
http://www.friendpaste.com/3FLgRFzOEAkkKazLbc7Jgw
for that log our replication cron does an ssh to host33, then curls it to
replicate from host01 to the database (with no host specified) as coninuous
pull replication
We have occasionally seen slow PUTing of documents on that database (and only
that database) which can take upwards of 10 seconds (via futon or our app) as
it is a creaking database that has a scarred history of documents that
contain many (thousands) of conflicts.
Could this occasional slow PUT manifest itself as this error in the log?
As a workaround to keep replication flowing, would it restart this
replication id if the curl called the cancelling of the replication
(cancel:true) followed by the starting of replication?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1364) Replication hanging/failing on docs with lots of revisions
[
https://issues.apache.org/jira/browse/COUCHDB-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Markham updated COUCHDB-1364:
--
Attachment: couchlog target host32.txt
checkpoint hang seq changes.txt
couchlog source host17.log
Ok, perhaps that stack trace was a separate issue. - with it patched, push
replication just times out with the same error as the do_checkpoint error
push.txt
I have done some more analysis - and found 2 seq ids where replication hangs
from host 17 - 32. After this point there are no more checkpoints. I managed
to get continuous replication working again past it by manually updating the
replication _local document on both sources to 1 source_last_seq id after this
point.
I attach 3 logs:
1) checkpoint hang seq changes - this is the changes feed from the source at
the 2 points in replication which hang - both are docs with very high number of
open revisions.
2) couchlog source host 17.log - this is the log of the couch where you can see
the GET requests for those documents being made, and then replication starting
again.
3) couchlog target host32.txt - this is the log of the couch doing the pull
replication - the target, there were no errors here.
I doubt the network is the issue here, all other databases replicate fine, and
this replication stream works once manually tweaked to go past those choke
points.
Is it possible that the database is trying to commit all these hundreds of
documents at once and it takes a crazy long time? I have set up a parallel
replication to the same host using a different hostname (so that the
replication id is different) without the cancel:true that I send every minute
and it has hung on that checkpoint (2745054) for the last few hours
Replication hanging/failing on docs with lots of revisions
--
Key: COUCHDB-1364
URL: https://issues.apache.org/jira/browse/COUCHDB-1364
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 1.0.3, 1.1.1
Environment: Centos 5.6/x64 spidermonkey 1.8.5, couchdb 1.1.1 patched
for COUCHDB-1340 and COUCHDB-1333
Reporter: Alex Markham
Labels: open_revs, replication
Attachments: COUCHDB-1364-11x.patch, checkpoint hang seq changes.txt,
couchlog source host17.log, couchlog target host32.txt, do_checkpoint error
push.txt, replication error changes_loop died redacted.txt
We have a setup where replication from a 1.1.1 couch is hanging - this is WAN
replication which previously worked 1.0.3 - 1.0.3.
Replicating from the 1.1.1 - 1.0.3 showed an error very similar to
COUCHDB-1340 - which I presumed meant the url was too long. So I upgraded the
1.0.3 couch to our 1.1.1 build which had this patched.
However - the replication between the 2 1.1.1 couches is hanging at a certain
point when doing continuous pull replication - it doesn't checkpoint, just
stays on starting however, when cancelled and restarted it gets the latest
documents (so doc counts are equal). The last calls I see to the source db
when it hangs are multiple long GETs for a document with 2051 open revisions
on the source and 498 on the target.
When doing a push replication the _replicate call just gives a 500 error (at
about the same seq id as the pull replication hangs at) saying:
[Thu, 15 Dec 2011 10:09:17 GMT] [error] [0.11306.115] changes_loop died
with reason {noproc,
{gen_server,call,
[0.6382.115,
{pread_iolist,
79043596434},
infinity]}}
when the last call in the target of the push replication is:
[Thu, 15 Dec 2011 10:09:17 GMT] [info] [0.580.50] 10.35.9.79 - - 'POST'
/master_db/_missing_revs 200
with no stack trace.
Comparing the open_revs=all count on the documents with many open revs shows
differing numbers on each side of the replication WAN and between different
couches in the same datacentre. Some of these documents have not been updated
for months. Is it possible that 1.0.3 just skipped over this issue and
carried on replicating, but 1.1.1 does not?
I know I can hack the replication to work by updating the checkpoint seq past
this point in the _local document, but I think there is a real bug here
somewhere.
If wireshark/debug data is required, please say
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
[jira] [Created] (COUCHDB-1365) Fix merging of document with attachment stubs
Fix merging of document with attachment stubs - Key: COUCHDB-1365 URL: https://issues.apache.org/jira/browse/COUCHDB-1365 Project: CouchDB Issue Type: Bug Components: Database Core, Replication Reporter: Filipe Manana Priority: Blocker Fix For: 1.2, 1.1.2 Attachments: 0001-Fix-merging-of-documents-with-attachment-stubs.patch, reproduce-CBMA-22.sh This issue was found by Marty Schoch and is reproducible the following attached script. The commit message in the patch explains the issue: During replicated updates, merging of documents with attachment stubs will fail if, after merging the received document's revision tree with the current on disk revision tree, produces a revision tree which doesn't contain the revision that immediately precedes the received document's revision. This happens when the received document doesn't contain in its revision history any of the revisions in the revision tree of the currently on disk document. This is possible when the document had a number of updates higher than the value of revs limit defined for the source database. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1365) Fix merging of document with attachment stubs
[ https://issues.apache.org/jira/browse/COUCHDB-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana updated COUCHDB-1365: --- Attachment: reproduce-CBMA-22.sh 0001-Fix-merging-of-documents-with-attachment-stubs.patch Fix merging of document with attachment stubs - Key: COUCHDB-1365 URL: https://issues.apache.org/jira/browse/COUCHDB-1365 Project: CouchDB Issue Type: Bug Components: Database Core, Replication Reporter: Filipe Manana Priority: Blocker Fix For: 1.2, 1.1.2 Attachments: 0001-Fix-merging-of-documents-with-attachment-stubs.patch, reproduce-CBMA-22.sh This issue was found by Marty Schoch and is reproducible the following attached script. The commit message in the patch explains the issue: During replicated updates, merging of documents with attachment stubs will fail if, after merging the received document's revision tree with the current on disk revision tree, produces a revision tree which doesn't contain the revision that immediately precedes the received document's revision. This happens when the received document doesn't contain in its revision history any of the revisions in the revision tree of the currently on disk document. This is possible when the document had a number of updates higher than the value of revs limit defined for the source database. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1365) Fix merging of document with attachment stubs
[ https://issues.apache.org/jira/browse/COUCHDB-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13171022#comment-13171022 ] Paul Joseph Davis commented on COUCHDB-1365: I don't get it. Does this patch fix replication or make it fail with an error? Fix merging of document with attachment stubs - Key: COUCHDB-1365 URL: https://issues.apache.org/jira/browse/COUCHDB-1365 Project: CouchDB Issue Type: Bug Components: Database Core, Replication Reporter: Filipe Manana Priority: Blocker Fix For: 1.2, 1.1.2 Attachments: 0001-Fix-merging-of-documents-with-attachment-stubs.patch, reproduce-CBMA-22.sh This issue was found by Marty Schoch and is reproducible the following attached script. The commit message in the patch explains the issue: During replicated updates, merging of documents with attachment stubs will fail if, after merging the received document's revision tree with the current on disk revision tree, produces a revision tree which doesn't contain the revision that immediately precedes the received document's revision. This happens when the received document doesn't contain in its revision history any of the revisions in the revision tree of the currently on disk document. This is possible when the document had a number of updates higher than the value of revs limit defined for the source database. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COUCHDB-1366) update of the Getting started with PL/SQL page
update of the Getting started with PL/SQL page -- Key: COUCHDB-1366 URL: https://issues.apache.org/jira/browse/COUCHDB-1366 Project: CouchDB Issue Type: Task Components: Documentation Environment: couchdb wiki Reporter: zekeriya koç Priority: Minor my link to the couchdb client library for Oracle PL/SQL has changed to: https://github.com/zekzekus/couch_orcl -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1365) Fix merging of document with attachment stubs
[
https://issues.apache.org/jira/browse/COUCHDB-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13171032#comment-13171032
]
Filipe Manana commented on COUCHDB-1365:
Paul, it makes the merging throw a missing_stubs error instead of crashing with
a function_clause like this:
{error:{worker_died,0.4681.0,\n {function_clause,\n
[{couch_doc,merge_stubs,\n [{doc,\document\,\n {12,\n
[173,196,77,158,203,221,181,67,212,246,74,43,219,237,94,\n 140,\n
72,74,171,180,242,101,33,172,166,195,136,125,231,134,65,\n 37,\n
83,182,225,95,63,211,178,52,96,92,102,114,130,224,138,145,\n
95,234,29,149,2,72,24,226,188,255,99,148,120,126,85,103,\n
87,169,231,120,244,95,82,97,203,2,50,37,173,50,61,2,\n
215,75,114,100,77,137,213,77,75,174,41,30,112,205,156,95,\n
65,124,138,146,230,4,155,92,52,14,189,152,167,30,231,96,\n
68,16,172,15,172,224,254,189,163,203,141,251,172,187,194,\n 27,\n
34,8,58,215,190,139,123,102,40,55,20,84,179,249,85,8,\n
29,39,81,231,191,249,211,32,50,145,38,97,78,100,102,188,\n
88,5,136,102,228,34,222,205,62,252,107,44,97,23,101,81,\n
222,52,110,92,212,100,161,137,190,163,109,245,255,233,\n 85,71]},\n
131,104,1,108,0,0,0,1,104,2,109,0,0,0,4,110,97,109,101,109,\n
0,0,0,6,99,98,109,97,50,50,106,\n
[{att,\./reproduce-CBMA-22.sh\,\text/plain\,41,21,\n
47,253,88,99,174,109,103,33,178,178,139,137,178,159,\n 243,29,\n
2,stub,gzip}],\n false,[]},\n nil]},\n
{couch_db,'-prep_and_validate_replicated_updates/5-fun-5-',4},\n
{lists,foldl,3},\n {couch_db,prep_and_validate_replicated_updates,5},\n
{couch_db,update_docs,4},\n {couch_db,update_doc,4},\n
{couch_replicator_worker,flush_doc,2},\n
{couch_replicator_worker,local_doc_handler,2}]}}}
When the replicator catches a missing_stubs error, it retries replicating the
document but without incremental attachment replication (sends all attachments,
just like in 1.1 and below).
Fix merging of document with attachment stubs
-
Key: COUCHDB-1365
URL: https://issues.apache.org/jira/browse/COUCHDB-1365
Project: CouchDB
Issue Type: Bug
Components: Database Core, Replication
Reporter: Filipe Manana
Priority: Blocker
Fix For: 1.2, 1.1.2
Attachments:
0001-Fix-merging-of-documents-with-attachment-stubs.patch,
reproduce-CBMA-22.sh
This issue was found by Marty Schoch and is reproducible the following
attached script.
The commit message in the patch explains the issue:
During replicated updates, merging of documents with
attachment stubs will fail if, after merging the received
document's revision tree with the current on disk revision
tree, produces a revision tree which doesn't contain the revision
that immediately precedes the received document's revision.
This happens when the received document doesn't contain in its
revision history any of the revisions in the revision tree
of the currently on disk document. This is possible when the
document had a number of updates higher than the value of revs
limit defined for the source database.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (COUCHDB-1358) Only delete files with .view extension
[ https://issues.apache.org/jira/browse/COUCHDB-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Joseph Davis closed COUCHDB-1358. -- Resolution: Fixed Applied to 1.2.x and 1.1.x Only delete files with .view extension -- Key: COUCHDB-1358 URL: https://issues.apache.org/jira/browse/COUCHDB-1358 Project: CouchDB Issue Type: Improvement Components: Database Core Affects Versions: 1.1.1 Reporter: Volker Mische Priority: Minor Fix For: 1.1.2 Attachments: cleanup-views-only.patch Currently all files in the view directory that are not used by any View group are deleted by the _view_cleanup endpoint. If other indexers (like GeoCouch) store indexes in the same directory, they get deleted as well. The attached patch changes the bahaviour and only deletes files ending with .view. Leftovers from compaction are deletes as well as they end with .compact.view. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1365) Fix merging of document with attachment stubs
[ https://issues.apache.org/jira/browse/COUCHDB-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13171039#comment-13171039 ] Paul Joseph Davis commented on COUCHDB-1365: Ah. Sounds good to me then. Fix merging of document with attachment stubs - Key: COUCHDB-1365 URL: https://issues.apache.org/jira/browse/COUCHDB-1365 Project: CouchDB Issue Type: Bug Components: Database Core, Replication Reporter: Filipe Manana Priority: Blocker Fix For: 1.2, 1.1.2 Attachments: 0001-Fix-merging-of-documents-with-attachment-stubs.patch, reproduce-CBMA-22.sh This issue was found by Marty Schoch and is reproducible the following attached script. The commit message in the patch explains the issue: During replicated updates, merging of documents with attachment stubs will fail if, after merging the received document's revision tree with the current on disk revision tree, produces a revision tree which doesn't contain the revision that immediately precedes the received document's revision. This happens when the received document doesn't contain in its revision history any of the revisions in the revision tree of the currently on disk document. This is possible when the document had a number of updates higher than the value of revs limit defined for the source database. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1365) Fix merging of document with attachment stubs
[ https://issues.apache.org/jira/browse/COUCHDB-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13171042#comment-13171042 ] Filipe Manana commented on COUCHDB-1365: Actually the commit message has a small mistake: This is possible when the document had a number of updates higher than the value of revs limit defined for the source database. Here I didn't want to say source but target database instead. Fix merging of document with attachment stubs - Key: COUCHDB-1365 URL: https://issues.apache.org/jira/browse/COUCHDB-1365 Project: CouchDB Issue Type: Bug Components: Database Core, Replication Reporter: Filipe Manana Priority: Blocker Fix For: 1.2, 1.1.2 Attachments: 0001-Fix-merging-of-documents-with-attachment-stubs.patch, 0001-Fix-merging-of-documents-with-attachment-stubs.patch, reproduce-CBMA-22.sh This issue was found by Marty Schoch and is reproducible the following attached script. The commit message in the patch explains the issue: During replicated updates, merging of documents with attachment stubs will fail if, after merging the received document's revision tree with the current on disk revision tree, produces a revision tree which doesn't contain the revision that immediately precedes the received document's revision. This happens when the received document doesn't contain in its revision history any of the revisions in the revision tree of the currently on disk document. This is possible when the document had a number of updates higher than the value of revs limit defined for the source database. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1365) Fix merging of document with attachment stubs
[ https://issues.apache.org/jira/browse/COUCHDB-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana updated COUCHDB-1365: --- Attachment: 0001-Fix-merging-of-documents-with-attachment-stubs.patch Fix merging of document with attachment stubs - Key: COUCHDB-1365 URL: https://issues.apache.org/jira/browse/COUCHDB-1365 Project: CouchDB Issue Type: Bug Components: Database Core, Replication Reporter: Filipe Manana Priority: Blocker Fix For: 1.2, 1.1.2 Attachments: 0001-Fix-merging-of-documents-with-attachment-stubs.patch, 0001-Fix-merging-of-documents-with-attachment-stubs.patch, reproduce-CBMA-22.sh This issue was found by Marty Schoch and is reproducible the following attached script. The commit message in the patch explains the issue: During replicated updates, merging of documents with attachment stubs will fail if, after merging the received document's revision tree with the current on disk revision tree, produces a revision tree which doesn't contain the revision that immediately precedes the received document's revision. This happens when the received document doesn't contain in its revision history any of the revisions in the revision tree of the currently on disk document. This is possible when the document had a number of updates higher than the value of revs limit defined for the source database. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1366) update of the Getting started with PL/SQL page
[ https://issues.apache.org/jira/browse/COUCHDB-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13171062#comment-13171062 ] Paul Joseph Davis commented on COUCHDB-1366: What's your wikipedia user name? I'll add you to the editors list. update of the Getting started with PL/SQL page -- Key: COUCHDB-1366 URL: https://issues.apache.org/jira/browse/COUCHDB-1366 Project: CouchDB Issue Type: Task Components: Documentation Environment: couchdb wiki Reporter: zekeriya koç Priority: Minor Labels: documentaion, getting_started, wiki my link to the couchdb client library for Oracle PL/SQL has changed to: https://github.com/zekzekus/couch_orcl -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1366) update of the Getting started with PL/SQL page
[ https://issues.apache.org/jira/browse/COUCHDB-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13171065#comment-13171065 ] Paul Joseph Davis commented on COUCHDB-1366: And by wikipedia I meant wiki.apache.org. I am apparently still not awake. update of the Getting started with PL/SQL page -- Key: COUCHDB-1366 URL: https://issues.apache.org/jira/browse/COUCHDB-1366 Project: CouchDB Issue Type: Task Components: Documentation Environment: couchdb wiki Reporter: zekeriya koç Priority: Minor Labels: documentaion, getting_started, wiki my link to the couchdb client library for Oracle PL/SQL has changed to: https://github.com/zekzekus/couch_orcl -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1366) update of the Getting started with PL/SQL page
[ https://issues.apache.org/jira/browse/COUCHDB-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13171147#comment-13171147 ] zekeriya koç commented on COUCHDB-1366: --- It should be zekzekus or zekze...@gmail.com update of the Getting started with PL/SQL page -- Key: COUCHDB-1366 URL: https://issues.apache.org/jira/browse/COUCHDB-1366 Project: CouchDB Issue Type: Task Components: Documentation Environment: couchdb wiki Reporter: zekeriya koç Priority: Minor Labels: documentaion, getting_started, wiki my link to the couchdb client library for Oracle PL/SQL has changed to: https://github.com/zekzekus/couch_orcl -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
