I hope it's the right place to ask such question. I have a live react app which still runs in development mode since it requires frequent updates, and it seems that for a few users the website doesn't function properly while for the others it works perfectly.
For example, for a few users there is a button that just doesn't respond, although I created some code to log to the console that the button was pressed, and it does also for those users, but then the rest of the code just doesn't run.
For other users, there is some text that loaded from mongodb database, and for those users it reverses some of the words in a random fashion.
I'm really lost here and don't even know where to begin, since for me and most of the users everything is working fine.
Do you think it could be because the app still runs in development mode?
Recently I noticed that a few users received the message
the development server has disconnected. refresh the page if necessary.
I researched this and was suggested that I should upgrade my react-scripts. I did, and the problem vanished, but the other problems still persist.
I understand that it's like shooting in the dark and it's hard to give advices without knowing more information, but maybe you could point me in the right direction?
Thank you very much in advance
Related
We have a reactJs application which works fine on all other browsers except safari on macOS and ios. The app works perfectly on Chrome on macOs or windows and ios as well.
Also, once the app freezes, we cannot open dev console in safari and if it is open, most of the things don't work like pausing script execution. And we can say from activity monitor that it goes in some infinite loop as the cpu usage of that page goes to 100% but i am unable to figure out as there are no errors at all and it works on other browsers.
It just freezes on loading and becomes totally unresponsive (No scroll or clicks etc). It looks like there is some infinite loop or dependency issue.
The webapp is kind of LMS and has many dependencies but to give you an idea here is the stack -
GraphQL
React Router Dom
React Hooks
Sentry for Logging
Socket
etc
If you have any questions feel free to ask.
Here is the site - https://i3.stage.cudy.co/
Thanks
I went into trying to see what's going on and I noticed three things:
First couple of times I tried to open your site it froze as you say. Could not even open dev tools.
After previous tries, I suddenly saw the icons for your menu options (browse tutors, assignments, feeds, etc) appear and everything worked "fine" and no more freezes.
However, I did noticed a bunch of errors in dev tools. Most of them are related to urls not allowed to access and some others due a /profiles trying to access an API of some sort.
You have a lot of unhandled promise rejections errors in your *.js so that may also be something to look at.
I would suggest tackling down the cross domain origin policies first and then add logic to handle the promise rejections that you're missing since sometimes those unhandled scenarios leave the app at the dark without knowing what to do and may interrupt your logic process thus rendering frozen sites because of that.
Last but not less important, this is a good way of tracing down the issue.
There are way too many factors involved for us to help you without looking at the code.
I'd recommend the following:
Going through the code history and testing it on each major version change so you can rule out any culprits or suspicions.
I'd disconnect any packages 1 by 1.
Disconnect the API so see if it's a server issue where you're requesting API calls infinitely or something silly like that.
If disconnecting the API works then you know where to look at.
Cheers
I have an native mobile application that loads my react application within a child iframe (not sure exactly how it does it), but this application injects some variables into the page as windows.xxxx
So in order to test my application (yes, this sucks a lot) I need to run the app on my phone, have it open up the URL on my development machine (aka http://192.168.10.10:3300).
Then to debug anything I'm forced to alert(var1) .. as you can imagine this is a pretty painful process and I really wish the parent application would provide something better than this.
Normally a simple option would be something like console.log(var1) but I can't see the console on my mobile device and my URL is being loaded withing this native app.
So:
1. Any suggestions on a better debug process would be welcome.
2. One idea that would help is if there was a react component that would simply
print to screen anything any console.log().
3. I guess another option could be some kind of remote logger, so that console.remotelog(debugServerUrl, var1) pushes debug messages to the listener which then displays the debug.
All of this if a pain of course, but hoping someone out there has a clever idea for me.
If you're already using ReactJS, an easy quick-fix might be creating a log file in the phone. This post details a quick and relatively easy way to save a string as a text file, and it would not be hard to put everything you want saved into a string.
Furthermore, This post details an implementation of the remote logging feature you vaguely referenced.
Also, if you want to capture stdout and stderr, check out this npm package
Ultimately, hope this helps, and good luck
Running WSo2 EMM 1.1.0, everything has been working just fine except for one big issue.
From the moment I first click on an app in the App Management tab, the WSO2EMM_DB.h2.db file starts to steadily grow as long as the server is running, even with absolutely no changes. Eventually, it gets so big that clicking an app on that tab takes a ridiculously long time to load the list of devices using the app. We're talking 5+ minutes, it becomes completely unusable. I have checked the error logs and found no errors at all, every time.
Restarting the server does nothing to correct the issue. Even if I click an app on the App Management tab once, and never again, the database file will continue to grow. Even restarting the server and not logging into the EMM page, it will continue to grow.
The only thing I've found so far that can possibly help is keeping backup copies of the database file and overwriting the current file when it gets too big. Obviously that's not a solution, as I'd need to create a new backup file every time there's a change on the server, and eventually the database file would grow too big from that too.
It's not an issue with the H2 database either. Not only have I tried starting over fresh several times and have had the same behavior, but here is the only info I could find regarding this issue, and they were having the issue regardless of whether or not it was on H2 or MySQL.
I've been trying to find a solution for this for over a month with no success. Any help would be appreciated!
EDIT: It looks like this might be the subject of EMM-826. Unfortunately there seems to be no response to that bug report so far.
EDIT 2: EMM-826 was closed with a message saying the following:
This issue is fixed in the EMM 1.1.0 GA latest pack. Please get all the patches for the product/build the product from the latest source [ https://github.com/wso2/product-emm ] and try again.
Unfortunately, that did not work for me. I'm not sure what exactly I'm doing wrong, so I'll list the what I did to try to fix it:
Downloaded the EMM 1.1.0 zip from http://wso2.com/products/enterprise-mobility-manager/.
Downloaded the zip from https://github.com/wso2/product-emm and pasted the files from that into my EMM_HOME directory.
When that didn't work, I searched for patches and found I was only using patches 1-6. In the documentation I found I could download patches 7-12 here. Patches 9 and 10 didn't work right for some reason; causing me not to be able to reach the EMM dashboard or publisher. I could only access the Carbon manager. I was able to make patches 7, 8, 11, and 12 work though - with no change in behavior.
Here are the steps I take to reproduce the issue:
After setting a fresh copy of the EMM up, I log in to the EMM dashboard as Admin, set up a user account, and upload an app through the Publisher.
Register a device to the user account I set up. In this case, an Android device running Android 4.2.2.
From the dashboard, I go to App Management and click the app I uploaded. The list of devices loads, but from that point on, the database file starts growing and eventually, after several hours, becomes so large it the device list will never load.
Please help!
Found this happening also, from a quick look it's the WSO2EMM_DB.notifications table. Seems to keep a history of all notifications over time, and the info for app installs is taken from non-optimized queries, which degrade as the table grows. You 'could' delete all rows from the table, and it will re-populate as devices 'check back' and report their info.
But you'd probably want to write a query to just keep the latest notification of each type of each user (I'll leave that to someone else...) and as was mentioned, it is apparently fixed in the latest version.
Issue appears to be resolved in EMM 2.0, which can be found here.
I have an app on appengine. It works fine locally. This morning, I deployed it and it doesn't work properly.
This is the app link, you can user username: qingWANG & password: wang123456 to log in as a teacher. Please forgive its ugly look, because it's just a prototype. When you log in, click reviewAssignment and in the new page you can see the homework students' uploads. You can try to click the score button, and you will see a 500 server error. The weird thing is, the first score button works fine, although it doesn't at the beginning; the others totally do not work.
When I check the datastore admin, it shows this:
I tested all these pages locally many times. But why does this error happen when I deploy?
Best Regards.
It's working for me. I am not getting any 500 errors...
Go to your dashboard and check the logs to see what is going on...
According to the stats page (https://cloud.google.com/appengine/docs/standard/java/datastore/stats)
"To keep the overhead of storing and updating the statistics reasonable, Cloud Datastore progressively drops statistics entities"
So when having lots of namespaces or entities, datastore statistics become unavailable.
Thus at some point sharded counters (https://cloud.google.com/appengine/articles/sharding_counters) must be used.
I deployed my app to Server, then I got this situation too.
No matter what I do, I can save an Entity and get it by Key. But I always failed by query it.
Two hours later, magical thing happened. I came back to the console and fresh the data... they are here. Every data I saved into database was there.
... Obviously, you don't need to do anything to fix it. Just let it run a while longer. It will be fixed by itself.
Assumption: live/production web app suppresses errors being shown to end-users.
Suppose your tech support team wants to see live data but through the eyes of the development-side of the application (maybe you want to see what errors are occurring, or want to see when you've got an issue fixed using an end-user's data).
Right now we've got one database serving both the dev and live boxes (not my idea - I know it's gross).
Ideas?
Edit: Best/handy tools for implementing your suggestion?
We replicate the data back to a different database. Yes, there is a delay, but it keeps people hands out of the production servers. This also allows us to "hide" information that tech support (and other people for that matter) aren't supposed to see.
In addition to replicating data down, on production, we see who's logged into the application, and if it's a member of the company, send them to the real error page versus the happy kitten playing with a ball of yarn apologizing.
Back up and restore from live to dev on a regular basis (once, twice a day). It doesn't need to be realtime (as you might be entering data from the dev side anyway, which could cause problems).
If you have PCI or HIPAA data, make sure you don't put that in your dev environment -- that might break laws.
I generally like to have a 3-tier system for web development:
Development
Testing
Live
Most of the time testing is an exact copy of the live system, except that errors are turned on, when a new version is about to be moved live it's replaced with the new version BEFORE live is, to detect upgrade issues.
Development is completely separate from live, to allow for major changes to things like the database, or changes to the production environment.
I would firstly make errors are either emailed to someone with details of how the user got there or at minimum logged so you can watch the error log while you perform similar actions to see if you get the same messages in the log.
And yes, copying the database on the dev server/site is probably your only option. You don't want any changes made by the development team to live data and you'll probably also have changes that won't work with the production database at some point.
I wouldn't recommend doing a nightly copy as a developer might be in the middle of some new feature where they have added data and then it's erased that night. I usually copy the production database(s) to dev each time a major version is released. This also allows me to do speed testing with a lot of live data. On some systems I also change everyones password to a default so I can login easily as any user.
If your configuration permits it:
a. Add a logging function (if there isn't one already) to write messages of interest to a log file.
b. Run the unix command
tail -f < logfile.txt
which will stream the growing log file to your console.
http://www.monkey.org/cgi-bin/man2html?tail
If you have Windows, you might try this:
http://tailforwin32.sourceforge.net/