This is pretty cutting-edge as 0.7.2 was just released today, but I thought I'd ask in case somebody can shed some light.
I didn't report this to MDG because I can't reproduce this on my dev environment and thus I wouldn't have a recipe to give them.
I've set up oplog tailing in my production environment, which was deployed exactly as my dev environment was, except it's on a remote server.
The server runs Ubuntu + node 0.10.26 and I'm running the bundled version of the app with forever. Mongo reports its replSet is working in order.
The problem is that some collection updates made in server code don't make it to the client. This is the workflow the code is following:
Server publishes the collection using a very simple user_id: this.userId selector.
Client subscribes
Client calls a server method using Meteor.call()
Client starts observing a query on that collection using a specific _id: "something" selector. It will echo on "changed"
Server method calls .update() on the document matching that "something" _id, after doing some work.
If I run the app without oplog tailing (by not setting MONGO_OPLOG_URL), the above workflow works every time. However, if I run it with oplog tailing, the client doesn't echo any changes and if I query the collection directly from the JS console on the browser I don't see the updated version of the collection.
To add to the mystery, if I go into the mongo console and update the document manually, I see the the change on the client immediately. Or if I refresh the browser after the Meteor.call() and then query the collection manually from the js console the changes are there, as I'd expect.
As mentioned before, if I run the app on my dev environment with oplog tailing (verified using the facts package) it all works as expected and I can't reproduce the issue. The only difference here would be latency between client and server? (my dev environment is in my LAN).
Maybe if somebody is running into something similar we can isolate the issue and make it reproducible..
Related
Made the mistake of performing a destructive migration on a synchronized realm, which I just now learned I shouldn’t have done according to the docs' statement “However, if the migration makes a destructive change, the Realm will stop syncing with ROS, producing a Bad changeset received error”. The server won't restart our Realm Object Server and the logs say realm-object-server dead but pid file exists. We cannot even access ROS on web at this point.
Is there a way around this without re-installing our realm instance? Also, if the magnitude of this migration is so severe, is there not a way to give a warning to the developer?
Code Sample:
let config = Realm.Configuration(
syncConfiguration: SyncConfiguration(user: curUser, realmURL: RealmURL.userObjects), migrationBlock: { (migration, schema) in
// todo
})
When you perform a schema change, this results in an operation that is appended to the operation log maintained by a Realm. This first occurs on the client copy of a synchronized Realm and is then synced to Realm Object Server. If the operation is a destructive change, the server should simply reject the operation and return an error. The result is that the server's operation log is not affected but the client is now in a state where it can't continue to sync with the server. In this situation, the solution is to reset the client, which is easiest in development by deleting and reinstalling the app.
Your situation, however, sounds like a different problem. The fact that the server is unresponsive implies something else went wrong. You could try removing and reinstalling the server since this does not delete the data or configuration.
I have a Meteor app that is based on the Meteor simple todos tutorial. I noticed, that the second node-process (smaller one) on the server, started later when the app is started up, increases its memory usage steadily, even when there is no activity at all but at least one client is logged on to the server. I trace the RSS-Memory value with
pmap -x $PID_node | tail -1 | awk '{ print $4 }'
but it is also visible with 'top'. The RSS number is increasing steadily when doing nothing at all on the client side. I added the app here for reproducing the behavior.
When I remember correctly it is the original state as I finished the tutorial without doing any custom changes.
When the client is disconnected the memory still remains and is not reduced by any means.This goes on until the app is closed on the server when reaching the memory limit. I encounter similar behavior with the official todos-example. I start the apps with
meteor --port 61100
I found in other posts that this could be related to a public folder which I even do not have in the simple todos so there must be something different. I also updated to the latest version of meteor 1.3.4.1 which does not change the behavior.
Is this a normal meteor behavior or has to be considered a meteor bug? Or is there any bad style code in the examples?
A very simply scenario: in a local meteor (v 1.2.1) development environment (WebStorm), with autopublish, and insecure enabled, I have a single MongodbDB (v 3.0.4) collection 'Letters'. I wish to respond immediately to any documents being added, removed, or modified in this collection.
For this purpose, I have the following autorun function:
Template.diagram.rendered = function(){
Tracker.autorun(function () {
Letters.find({}).observe({
added: function(document) {
console.log('a new document has been added');
},
changed: function(newDocument) {
console.log('a document has been changed');
},
removed: function(document) {
console.log('a document has been removed');
}
});
})
}
When a new document is added from within the same application, I can see the console messages right away (meteor latency compensation). However, when I connect to the same MongoDB database using an external tool (Robomongo), and add, change, or remove a document within the 'Letters' collection - it takes about 6-10 seconds before this change is detected, and the corresponding console message appears in the browser.
Why does it take this long, instead of being almost instantaneous?
Once I have this question posted on meteor forums, I was pointed to a meteor blog post from 2014, which describes the oplog tailing feature, and the fact, that it is only on by default in the dev instance. This made me realize, that, by using MONGO_URL env variable with my dev application, I was forcing my meteor app to work with the MongoDB instance, which was running on my mac all the time, independently from my meteor development, and, as such, was considered as "production" by my meteor app. Once I have switched the app to work with ad-hock mongo connection / db, the oplog tailing went into effect, and I started to see immediate event propagation to the browser.
Thanks, #dburles from the meteor forums!
I have a simple Meteor application. I would like to run some code periodically on the server end. I need to poll a remote site for XML orders.
It would look something like this (coffee-script):
unless process.env.ORDERS_NO_FETCH
Meteor.setInterval ->
checkForOrder()
, 600000
I am using Velocity to test. I do not want this code to run in the mirrored instance that runs the tests (otherwise it will poach my XML orders and I won't see them in the real instance). So, to that end, I would like to know how to tell if server code is running in the testing environment so that I can avoid setting up the the periodic checks.
EDIT I realised that I missed faking one of my server calls in the tests, which is why my test code was grabbing one of the XML orders from the real server. So, this might not be an issue. I am not sure yet how the tests are run for the server code and if the server code runs in a mirror (is that a client only concept)?.
The server and the client both run in a mirror when using mocha/jasmine integration tests.
If you want to know if you are in a mirror, you can use:
Meteor.call('velocity/isMirror', function(err, isMirror) {
if (isMirror) {
// do something
}
});
Also, on the server you can use:
process.env.IS_MIRROR
You've already got the fake working, and that is the right approach.
We have a problem with our meteor server. When we publish 300 or so items with Meteor.publish/Meteor.subscribe the server increases its memory and eventually becomes unresponsive.
We thought of:
1) monitor the number of reactive subscribtions / memory taken by an active subscription
2) make something like ,,one time publish" - ignore changes in server side collection
Any thoughts on how any of the above can be accomplished ?
Or any other tips to debug /improve meteor app performance ?
Thanks
zorlak's answer is good.
Some other things:
You can do a one-time publish by writing your own custom publisher via the this.set API, based on the code in _publishCursor. You'd do something like:
Meteor.publish("oneTimeQuery", function () {
MyCollection.find().forEach(function (doc) {
sub.added("collectionName", doc._id, doc);
});
sub.ready();
});
This does a query, sends its results down, and then never updates it again.
That said, we hope that Meteor's performance will be such that this is unnecessary!
I'd also like to add an easy way to get stats (like number of observed cursors) from an app to Meteor (exposed as an authenticated subscription) but haven't had the time yet.
As of Meteor 0.5.1, one thing you can do is to remove dependencies on the userId from the publish function. If a publish function does not depend on which user is subscribing, then Meteor will cache the db query so it doesn't get slower as more users subscribe.
See this Meteor blog post: http://meteor.com/blog/2012/11/20/meteor-051-database-scaling