I'm facing a very strange problem since Meteor update from v2.5.6 to v2.6.1:
When i deploy the app on my server (a local server in my LAN) using MUP at first glance everything works as expected. But when i call a method the first time, the answer is returned from the server very very slow (about 10-20 seconds). When calling then the same method again, it is quickly as usual. However this is the case for every method in my application.
Of course I also changed my MUP setup when updating from 2.5.6 to 2.6.1 and called mup setup first:
My changes in mup.js:
...
docker: {
image: "zodern/meteor:root",
},
...
mongo: {
version: "3.6",
servers: {
one: {},
},
},
...
It might be similar to this problem: Meteor.call is very slow when responding back
But I had never any issues with this in version 2.5.6.
Further, it only happened for method calls, all subscriptions are super quick. And it also only happened on the server! On my local dev machine, everything is good!
Does anyone know whats going on here and how I can solve this issue?
He solved the issue by upgrading the server to MongoDB 5.0.5
Related
I have a strange issue. I build my Meteor app and run it on android device using -
meteor run android-device --mobile-server=<my_aws_ip>:3000
When the app deploys immediately it connects to the server (and my javascripts etc works). After a few seconds, the page refreshs and none of the javascript callbacks work. Please help me debug this issue.
More information: If I change the client (and not the server), and deploy it, for the first few seconds, the changed client gets shown on the phone. After the first few seconds, the version which is present on the server is shown. So I think Cordova or Meteor is trying to fetch the client code from the server, which is breaking the app. Is there a way to prevent this behavior?
Even more data points -
My aws code does NOT have android and ios platforms installed. Because of this, I think the cordova plugins are not installed, causing a JS break somewhere.
Easiest fix I can think of is remove cordova autoupdate. This is being added by meteor-platform package. If I clone meteor-platform and comment out the cordova autoupdate, the app doesn't load.
Is there another way of removing autoupdate?
This sounds like you have a different version of your app deployed at the mobile-server address.
The local code is run in development mode. Your AWS one is likely in production mode (and may contain a syntax error).
When you run your app it sees the code is different and fetches the new/old (different) version with a hot code reload - hence the page refresh/flash.
To fix this, you need to find the syntax error in your code. It's best to view the ADB logger or run with meteor run --verbose android-device ....
This will provide a bit more information such as an Uncaught exception: cannot read .. of null error type error.
It's hard to say what the error is. The error prevents the rest of your code from executing. In production mode the entire project is one JS file. If there is an error of any kind half way along the file, the rest of the file will not execute.
Also, try loading <my_aws_ip>:3000 in your browser and watch for JS errors in the JS console.
You can also run it locally with --production to simulate a production build environment locally.
Enabling autoupdate but without a page refresh:
Reload._reload = function (options) {
console.log("Next load will load new version");
};
Does meteor run ios-device not build from scratch every time you run it? While meteor run ios serves the latest code, ios-device seems to serve the code that was built before. I have checked documents but haven't found anything related.
Are you building against a server other than your local server (i.e. something other than localhost).
If so, if that server has and old version deployed, it may be hot code pushing old client code when your mobile app starts up!
Recently I added email sending capability to my Meteor app, using both the email package, and the account registration APIs to send emails. The other day, after having tested this thoroughly on my dev machine, I deployed it to our production server using Meteor Up. Once deployed, I did a quick check that the email APIs were working properly, and let it be. A day or two later, I made some minor changes, wrapping these email APIs in a Meteor.defer method to speed up the UI. I tested the changes locally (all fine), and re-deployed. I also ran apt-get update on my server after seeing a notification there were some new security updates available. After doing this, the email system no longer works. I tried reverting back to my previous configuration, and it still isn't working. I'm getting a timeout error:
Exception while invoking method 'forgotPassword' Error: connect ETIMEDOUT
I was wondering if anyone had any ideas on what might be causing this timeout (a blocked port?...how can I diagnose this?). Given my SMTP port is working on my development machine, it doesn't seem to be an issue with my code, but rather either with the MUP deployment, or Ubuntu configuration. I'm not super familiar with configuring Ubuntu servers. Any suggestions on how to go about de-bugging would be greatly appreciated!
We got a similar problem, and it was solved by opening the needed port in EC2. thanks to https://kylegoslin.wordpress.com/2012/06/05/116/
I have created my first meteor app today and am kind of stuck. Everything works extremely well on localhost:3000, very responsive etc. It is a simple task app, where users can post tasks to a feed that displays all tasks an then claim those tasks, removing them from the general feed and putting them into their personal feed. But when I deploy it to a meteor.com server, everything breaks.
This is the js file
https://github.com/valentin-zambelli/brokenjs/blob/master/mvp.js
Accounts.ui.config({
passwordSignupFields: "USERNAME_ONLY"
});
gets ignored and whenever I try to post a new task the page reloads, getting stuck on app.meteor.com/?text=some+new+task and doesnt display the task in the general taskfeed.
I have removed the insecure and autopublish package. Is there anything I am missing here? It kind of seems as if it uses an older, broken build. I also get the ReferenceError: Can't find variable: require when deploying, but I can't really figure out where this is coming from.
I hope someone can help me.
Ok, it was an insanely stupid mistake on my part: The mongodb was still in an older state and caused a conflict. If you have problems deploying your meteor app try
meteor deploy myapp.meteor.com -- delete
This will delete all resources on the server, including the database. Then do a simple
meteor deploy myapp.meteor.com
On localhost, the app works just fine.
On EC2, the app runs behind nginx. It loads into the browser, but nothing shows up. The browser console displays an Error
TypeError: 'undefined' is not an object (evaluating 'Package["service-configuration"].ServiceConfiguration')
I have no idea how to tackle this problem. Any help appreciated.
EDIT
NGINX is not the problem. The same behavior if I access meteor server directly.
Running "meteor add service-configuration" does fix the above mentioned error, but the absence of the error does not fix the observed behavior, that the app does not render on EC2 whereas it does render when started on localhost. (The error message was the only visible difference between EC2 and localhost. So I suspected that would be the cause. Now that hypothesis must be wrong.) So the problem still persists.
Problem Solved. The Lesson:
Meteor has a debug mode and a production mode. The two may behave differently. On localhost, meteor runs in debug mode per default. On deploy to meteor.com or per mup, the default is production mode. To run meteor in production mode on localhost, run meteor --production.
It looks like you're trying to access the service-configuration configs on your browser.
These are not available client side. This also affects your localhost app but it doesn't break your app (doesn't give you a blank page) because meteor is in debug mode.
In debug mode Meteor files are not concatenated so an error like this would go unnoticed, even if it is thrown on your js console. In production mode the error would halt the rest of your script (since everything is concatenated into a single file)
You need to ensure the code that is doing this only runs on the server side. In general it's not a good idea to have access to the service configuration data on the client side.
Looks like Arunoda and crew are adding a buildOptions.debug setting to the next version of MUP, which should allow you to deploy via MUP and have it act like it's running on localhost. See Arunoda's answer to a related question and (at least for now) documentation for the development version of MUP.