LiteCore and CouchDB replication

47 views
Skip to first unread message

Adam Wilson

unread,
Sep 1, 2018, 8:32:33 PM9/1/18
to Couchbase Mobile

I'm trying to replicate from CouchDB using LiteCore (from C++). I'm linking to the static libraries, and using C4CivetWebSocketFactory. 

It looks like its trying to connect via WebSocket and receiving an HTTP response. Since CouchDB does not currently support WebSockets, how can I get it to fall back to HTTP? (If that is the issue)

Console output below:

01:19:41.614057| [DB]: Opening database ../../../../c4db/db/db.sqlite3
01:19:41.618855| [Sync]: {Repl#1}==> litecore::repl::Replicator ../../../../c4db/db/ ->http://<couchdb-ip>:5984/mydb
01:19:41.618917| [Sync]: {Repl#1} Push=passive, Pull=one-shot, Options={{}}
01:19:41.628659| [Sync]: {Repl#1} No local checkpoint 'cp-HdL43k4ltUI/79YYeGCRxvY6KsM='
01:19:41.691422| [WS] WARNING: {C4SocketImpl#1}==> litecore::repl::C4SocketImpl http://<couchdb-ip>:5984/mydb
01:19:41.691502| [WS] WARNING: {C4SocketImpl#1} WebSocket closed abnormally with status 200
01:19:41.691727| [Sync]: {Repl#1} Connection closed with WebSocket status 200: "Unexpected response status 200 OK" (state=1)
01:19:41.691790| [Sync] ERROR: {Repl#1} Got LiteCore error: Unexpected response status 200 OK (6/200)
01:19:41.691832| [Sync]: {Repl#1} now stopped
01:19:41.692051| [DB]: Closing database ../../../../c4db/db/db.sqlite3


Brendan Duddridge

unread,
Sep 1, 2018, 11:45:27 PM9/1/18
to Couchbase Mobile
It would be great to be able to sync from CouchbaseLite 2.x to CouchDB. But I don't think they support that.

It's what's keeping me from upgrading to 2.x.

Brendan

Adam Wilson

unread,
Sep 2, 2018, 5:24:06 AM9/2/18
to Couchbase Mobile
Yes, looking through the code again, it looks like you might be right. The following line in the documentation led me to believe HTTP was also supported:
 
 The WebSocket protocol starts off as an HTTP(s) connection and switches over to Websockets if the remote host supports it.

My question now is, will Couchbase support replication with CouchDB? I do not want to have to install Couchbase Server and Sync Gateway on my server. It requires a lot of memory (i.e., expensive to run) and is more complex to manage than CouchDB. 

If not, I'd like some guidelines on implementing a CouchDB Replicator. 

Another possible option might be to run Sync Gateway with an external store, https://docs.couchbase.com/sync-gateway/2.1/integrating-external-stores.html
However this requires lots of setting up and is not a clean solution like CouchDB. 

Nick Wood

unread,
Sep 2, 2018, 8:59:59 AM9/2/18
to Couchbase Mobile
If not, I'd like some guidelines on implementing a CouchDB Replicator. 

We're also in a situation where using sync gateway isn't feasible and we would need to switch to something like PouchDB if CouchDB replication ever stopped working with Couchbase Mobile. That being said, we would love to update to 2.x. We would be willing to contribute/sponsor development efforts to implement CouchDB replication in 2.x if reasonable, but don't have the in-house ability to lead this effort.

Jens Alfke

unread,
Sep 4, 2018, 2:10:03 PM9/4/18
to mobile-c...@googlegroups.com


On Sep 2, 2018, at 2:24 AM, Adam Wilson <adam.el...@gmail.com> wrote:

My question now is, will Couchbase support replication with CouchDB?

No, sorry. We used to use the CouchDB protocol mainly for historical reasons. Interop with CouchDB was nice, but it also caused support problems when CouchDB implemented replicator features in ways that were incompatible with ours [and poorly documented…]

In 2.0 we needed to improve replication performance and reliability, and reduce code complexity; and the use of HTTP/REST was a big obstacle to that. WebSockets work a lot better for this purpose.

—Jens
Privacy Policy | Update Marketing Preferences

Adam Wilson

unread,
Sep 5, 2018, 11:34:21 AM9/5/18
to Couchbase Mobile
Thanks for the information Jens. I understand what you're saying, but for some of us the need to run the beast that is Couchbase Server alongside Sync Gateway is quite a barrier. Running both services requires at least 8GB of memory to run reliably, ideally 16GB. A 16GB server costs over $100 a month to run. For my current project this is simply not feasible. Looks like its time to look at alternative options.
Reply all
Reply to author
Forward
0 new messages