https://github.com/wekan/wekan/issues?q=is%3Aissue+maximum+call+stack+is%3Aclosed
https://stackoverflow.com/questions/75869629/ios-websocket-close-and-error-events-not-firing
This can happen, when there is too much or incompatible code at browserside, for example at iOS Safari.
To fix it:
Use Bundle Visualizer to see what is the size of dependencies, and try what can be moved to serverside like at step 1, that bundle visualizer is used in this script https://github.com/wekan/wekan/blob/main/rebuild-wekan.sh
meteor run --exclude-archs web.browser.legacy,web.cordova --port 4000 --extra-packages bundle-visualizer --production 2>&1 | tee ../log.txt
Make dependencies smaller. For example, use only required files, and do not include all dependencies: https://github.com/wekan/wekan/commit/23e5e1e3bd081699ce39ce5887db7e612616014d . In that commit, package was forked to packages directory, then renamed, and added with meteor add packagename
, where package name does not have character :
Use Browserstack.com to see errors at browser / inspect / console, or use iOS or other device emulators, to see error messages. Testing at real device is more important, because they could work differently than emulators, emulators sometimes do not emulate all same features. Those error messages have file where error happened, and line number, like something.js:301
. From there, scroll up a little, look at what function or what package dependency it is where it happened. If possible, try to move that package serverside, like at step 1. Or alternatively, look is it possible to remove or change to some other compatible dependency.
See what are the dependencies at your Meteor based software, compared to WeKan dependencies that are usually already upgraded to newest Meteor, is there any differences where changing to correct dependencies could help you to upgrade to newest Meteor:
If you get some errors, search are those same already fixed in WeKan/Meteor/RocketChat, could you fix them same way:
If you have some webserver providing SSL/TLS, check that you have websockets enabled:
Identify the core service your app is providing and make sure it is running independently. Put everything non-critical, including reporting, on some other system.
Look at scaling tips here, quote:
smeijer commented 25 days ago Just wanted to let know that I haven't experienced this issue anymore since I've replaced a lot of
meteor publications
withapollo/graphql requests
.The reactivity is thereby lost, but in my case a 30sec poll is also fine. On the places that I do require reactivity, I only
publish
a singletimestamp
. This timestamp is passed through toapollo
, which triggers arefetch
when the timestamp is changed.The discussion here has also been helpfull to improve performance here and there.
Collect a heap profile and then analyze it
Older article: How to Self Detect a Memory Leak in Node
1) Increase ulimit system wide to 100 000 in systemd config.
2) Wekan Javascript code has increaded fiber poolsize.
3) There is on-going 100% CPU usage Meteor issue and hopefully fixes to Node.js will land in Node v8.12 sometime. Node 8.12 is now released and official version included at Wekan.
Dockerfile, versions of Meteor.js, Node etc listed at beginning.
Included Meteor package versions
Added packages at package.json
Wekan:
Wekan for Sandstorm:
curl https://install.sandstorm.io | bash
, select dev installwget https://releases.wekan.team/node
chmod +x node
mv node ~/projects/meteor-spk/meteor-spk-0.4.0/meteor-spk.deps/bin/
export PATH=$PATH:$HOME/projects/meteor-spk/meteor-spk-0.4.0
source ~/.bashrc
cd wekan && meteor-spk dev
sudo sandstorm
. Release scripts. Official releases require publishing key that only xet7 has.Docker:
git clone https://github.com/wekan/wekan
cd wekan
docker-compose up -d --build