yeeking
commented
8 years ago Hello again,
After a bit more digging, this is a known aspect of sharejs 0.6, i.e. it does not work across a cluster.
https://josephg.com/blog/sharejs/
Anyone tested 0.7 yet? We can potentially provide some developer time to work on this...
cheers
Matthew
Hello folks!
We have come across a problem with meteor-sharejs (actually sharejs) when it runs in a cluster configuration with multiple app instances.
Problem
In share.js, which is pulled in from here (according to the package.js file):
https://github.com/mizzao/ShareJS/tarball/05b625ea1e7f7f27bd13ba7ed05102b38dd175e5
there are two lines
which dictate the _id for an op. This does not work if you have two app instances (e.g. running in containers in meteor galaxy) as two connected users on the same doc, each conntected to a different instance, will generate the same version number and mongo will not accept the ops since they have have the same _id.
How to see the problem in action:
Startup your own mongo server.
Run two app instances: MONGO_URL=mongodb://localhost:27017/databasename meteor --port=3000 MONGO_URL=mongodb://localhost:27017/databasename meteor --port=3001
then try to edit the same document with two different users, one connected to each app instance, the first user is blocked from editing once the second user joins. This does not happen if they are in the same app instance. There is a server error:
The v is generated in the share.js file.
Thanks!
Matthew