Possible incompatibility between antidote-fs and antidote official docker image

[guillaumekoenig]

Hi,

I am using antidote-fs from git revision c08e5d1 and the official antidote from docker image 480c4f761f61. Antidote's port is mapped to 8087 on the host. When I run antidote-fs, I get the following errors. Listing the mount directory stalls and never completes. Do you have a preliminary idea of what is wrong with this setup ?

Thanks

$ docker run -d --name antidote -p "8087:8087" antidotedb/antidote
$ npm install
[...]
$ mkdir -p mnt
$ node src/antidote-fs.js -m ./mnt -a 127.0.0.1:8087
INIT: connInfo {"proto_major":7,"proto_minor":26,"async_read":1,"max_write":131072,"max_readahead":131072}
(node:1692) UnhandledPromiseRejectionWarning: Error: Antidote-PB Error code 0:
Error processing incoming message: error:{unknown_crdt_type_protobuf,9}:[{antidote_pb_codec,
                                                                          decode_type,
                                                                          1,
                                                                          [{file,
                                                                            "/usr/src/antidote/_build/default/lib/riak_pb/src/antidote_pb_codec.erl"},
                                                                           {line,
                                                                            317}]},
                                                                         {antidote_pb_codec,
                                                                          decode_bound_object,
                                                                          1,
                                                                          [{file,
                                                                            "/usr/src/antidote/_build/default/lib/riak_pb/src/antidote_pb_codec.erl"},
                                                                           {line,
                                                                            162}]},
                                                                         {lists,
                                                                          map,
                                                                          2,
                                                                          [{file,
                                                                            "lists.erl"},
                                                                           {line,
                                                                            1239}]},
                                                                         {antidote_pb_txn,
                                                                          process,
                                                                          2,
                                                                          [{file,
                                                                            "/usr/src/antidote/_build/default/lib/antidote/src/antidote_pb_txn.erl"},
                                                                           {line,
                                                                            191}]},
                                                                         {riak_api_pb_server,
                                                                          process_message,
                                                                          4,
                                                                          [{file,
                                                                            "/usr/src/antidote/_build/default/lib/riak_api/src/riak_api_pb_server.erl"},
                                                                           {line,
                                                                            388}]},
                                                                         {riak_api_pb_server,
                                                                          connected,
                                                                          2,
                                                                          [{file,
                                                                            "/usr/src/antidote/_build/default/lib/riak_api/src/riak_api_pb_server.erl"},
                                                                           {line,
                                                                            226}]},
                                                                         {riak_api_pb_server,
                                                                          decode_buffer,
                                                                          2,
                                                                          [{file,
                                                                            "/usr/src/antidote/_build/default/lib/riak_api/src/riak_api_pb_server.erl"},
                                                                           {line,
                                                                            364}]},
                                                                         {gen_fsm,
                                                                          handle_msg,
                                                                          7,
                                                                          [{file,
                                                                            "gen_fsm.erl"},
                                                                           {line,
                                                                            451}]}]
    at AntidoteConnection.handleError (/home/guillaume/Downloads/repo/antidote-fs/node_modules/antidote_ts_client/dist/antidoteConnection.js:104:34)
    at AntidoteConnection.readMessagesFromBuffer (/home/guillaume/Downloads/repo/antidote-fs/node_modules/antidote_ts_client/dist/antidoteConnection.js:75:22)
    at AntidoteConnection.onData (/home/guillaume/Downloads/repo/antidote-fs/node_modules/antidote_ts_client/dist/antidoteConnection.js:41:14)
    at Socket.socket.on (/home/guillaume/Downloads/repo/antidote-fs/node_modules/antidote_ts_client/dist/antidoteConnection.js:22:46)
    at emitOne (events.js:116:13)
    at Socket.emit (events.js:211:7)
    at addChunk (_stream_readable.js:263:12)
    at readableAddChunk (_stream_readable.js:250:11)
    at Socket.Readable.push (_stream_readable.js:208:10)
    at TCP.onread (net.js:607:20)
(node:1692) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:1692) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
GETATTR:  1

[pviotti]

Hi Guillaume, thanks for reporting this.
There's nothing wrong with your setup. Antidote has recently undergone a series of non-backward compatible changes that are reflected in the Docker image you used, and not yet supported by the Antidote javascript client.
While waiting for these changes to be fully supported, you can use this other Docker image, which is a bit out-of-date but still works for the file system.

[guillaumekoenig]

Thank you Paolo, I confirm that the other docker image does work with antidote-fs (ie I can now list, create, edit, delete on the mount).

[peterzeller]

@pviotti I updated the Javascript client and removed the CRDTs that are no longer supported by Antidote. You can find a short changelog here: https://github.com/SyncFree/antidote_ts_client/releases/tag/v0.2.0

[pviotti]

Thanks. I implemented the changes and pushed them into the dev branch.
The rrmap change went smooth, whereas the removal of the integer CRDT might create some issues. I was using it for counting hard links, invoking both set and increment operations. Now I temporarily replaced it with a register, which only supports set operations with LWW semantics, which may create some weird behaviors in case of concurrent removals and hard linking in distributed settings.
It passes the tests, but at the moment the test coverage for distributed settings is quite limited.
Maybe the counter would be a better replacement in this case -- this needs some thinking.

[marc-shapiro]

Thanks Paolo. I'm not sure a counter is the right approach. Assume creating a link is a transaction that both adds the link to a map or set, and increments the counter. Then, if two replicas concurrently add the same link, you will have only one link, but the counter is incremented by 2. Similar anomalies can happen if you have a concurrent add and delete of the same link. You may be better off asking the link map/set for its element count. Marc

…

Le 17 avr. 2018 à 10:27, Paolo ***@***.***> a écrit : Thanks. I implemented the changes and pushed them into the dev branch. The rrmap change went smooth, whereas the removal of the integer CRDT might create some issues. I was using it for counting hard links <https://github.com/SyncFree/antidote-fs/blob/master/src/antidote-fs.js#L803>, invoking both set and increment operations. Now I temporarily replaced it with a register, which only supports set operations with LWW semantics, which may create some weird behaviors in case of concurrent removals and hard linking in distributed settings. It passes the tests <https://travis-ci.org/SyncFree/antidote-fs/builds/367529267>, but at the moment the test coverage for distributed settings is quite limited. Maybe the counter would be a better replacement in this case -- this needs some thinking. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGWtn_OlNifBV0Yay2jb2ASbEMX55zmpks5tpadcgaJpZM4TWBTU>.

[pviotti]

Yep, that's exactly why I wrote that using counters requires careful thinking :)

You may be better off asking the link map/set for its element count.

The nlinks item exists in file systems for precise use cases (e.g. hard linking and deleting). So the question is: can we remove it and refer to the cardinality of the map of parent_inode -> name items? Yes, I suppose