I'm developing a GWT application, and I'm having issues with testing in development mode in eclipse.
When I make changes to the client-side code, I refresh the browser page (F5) to reload the module. Every time I do this (whether the code has changed or not), the Development Tab in eclipse shows a new bullet point with "Module xxxx has loaded". As well, according to Task Manager, every time I do this, the javaw.exe host process increases by about 1MB of memory. Eventually (10-20 refreshes later), the page fails to load and the Development Mode tab shows this error:
Out of memory; to increase the amount of memory, use the -Xmx flag at startup (java -Xmx128M ...)
I can fix this by stopping and restarting the server (not the little refresh button in the Developer Mode tab, but the red stop button), but it then the module has to be revalidated, which takes a while. It seems that eclipse doesn't realize I've finished with the old module when I reload a new one. I'm observing the same behavior with a brand-new GWT project, so I don't think it's my code. Is anyone aware of a way to remedy this?
EDIT: See both answers below for possible solutions.
The default settings gwt dev mode use are the minimum , so you hit an out of memory really quickly.
From this you can see that the permgenspace is to low and if you refresh 20 times in a short periode it will go out of memory.
you can start by using following vmargs :
-Xms512m -Xmx512m -XX:MaxPermSize=256M -XX:+UseParallelGC
But as enrybo pointed out if your application grows it requires more memory:
-Xms512m -Xmx1g -XX:MaxPermSize=256M -XX:+UseParallelGC
There isn't really all that much you can do. As you mentioned you can increase the memory but eventually you'll run into the same problem even with more allocated memory.
I suggest you try to run in Super Dev Mode but in that case you'll need to update the SDK you're using to 2.5.1+. With Super Dev Mode your browser does not need a plugin because it will actually be running true Javascript. You even have the ability to debug in your browser but looking at your Java source (using source maps).
Related
I am writing to ask about --disable-features=SameSiteByDefaultCookies feature which was part of chrome earlier.
I am working with IT MNC and recently we promoted very important functionality to Production. We have started charging customer for this. It is legacy application .
This application can't be tested locally anymore! Earlier we could point out application to lower environment with custom settings in project's config.js file and disabling #same-site-by-default-cookies in Chrome and application could be tested locally. But now we can't!
We tried many different settings and debugged but it could not help !!
It is noted that these settings no longer work in Chrome 94+. These flags are removed entirely.
As per my analysis it is found that application still can be tested locally if we get the portable Chrome. Or older version of Chrome installed in our System. However as per the compliance policy of company and client, we can't get old or portable chrome in system. We have latest version only.
Earlier we used to perform following to run it locally:
Open CMD
cd to Chrome path ( Till Application )
Fire the following command:
chrome.exe --disable-web-security --user-data-dir=C:\XXXX\XXXX\localwlp --disable-features=SameSiteByDefaultCookies"
This would open a new window of Chrome ( Close all before firing the command) and then we could test the application locally.
Anybody is aware about the alternative for this? That would be really helpful. We can't test the application locally so for even small changes, we require to deploy on lower environments which takes a lot of time and also code will work or not can't say.
I look forward to hearing from you all guys.
Thanks,
Kailash Nirmal.
We have a Kiosk app which runs on Chrome Kiosk mode and is written in React JS. But for some of our Kiosk machines (All of our machines are Windows machines), it seems to be crashing regularly (Approx. %4 of the devices) without any user input or fixed time between crashes.
I reviewed the code several times but never found any background tasks running, or any reason for the Chrome to crash at all.
Because the crashes are irregular, I cannot connect to a problematic device and wait for it to crash for hours to debug the process. And because the app is automatically started via a VB script when Windows is started, the clients often "solve" the crashes by restarting the Kiosk machine, which is time consuming and leads to tons of complaints.
So my questions are;
Can I somehow force Chrome to restart, or lets say Go to first page in history if it crashes?
Can I catch errors globally without using ErrorBoundries in JavaScript (It is already implemented and is used for other things)
I tried using --remote-debugging-port=9222 to use Developer Tools, but I need to be connected to the machine and go to localhost:9222 port manually to use this and cannot afford to be connected to the device all the time. So is there a way to connect and use Developer Tools on 9222 port remotely?
I tried saving console logs to a file (using Chrome Command Line Arguments) but never saw any "Errors" on the list, so is there any arguments to help me save crash logs to a file to inspect them after the crash?
Thanks for all your help.
I have remote_autostart disabled and no cookie present:
Still, Xdebug is connecting to my IDE (PhpStorm) at 192.168.22.101:9000 and zero-config debugging works. Why? How do I disable it? (It looks like autostart is somehow enabled and the PHP app is slow.)
My first bet would be that this is not the php.ini you're looking for. If you have CLI and normal php.ini, make sure you have this set up in both. Integrated PHP server counter-intuitively uses web php.ini instead of CLI one.
Next step would be to check whether it's actually xdebug that's causing the issue. I'd do that by disabling the extension alltogether.
Note that xdebug can slow down you app in some cases no matter what just by being enabled.
Next I'd check that xdebug profiler information is not generated. If the app is slow in general it's the profiler. If it just hangs for few seconds and then runs normally it's waiting for remote debugger. Might be a good idea to measure (even by simple means like putting dump on first and last line of code) speed of the app to rule out this possibility.
I have been having exactly the same issue for a few days now. remote_autostart is set to off but it still triggers even on my own <?php phpinfo(); script. The debugging session even starts when using an incognito browser session.
Notice the odd IDE key btw, it is set automatically.
Update: Even with xdebug.default_enable on off, it still activates Xdebug in my IDE.
I am developing an app using react native, I use some code base for ios and android, the ios version run smoothly.
But the android version run very slowly. the weird thing is:
When I shake the phone, and click "Debug JS" to enable debug in chrome feature, it run faster, anyone have a clue about the reason?
Sometimes, one or more than one active console.log() lines cause this issue.
console.log lines should be searched and deleted if they exist.
Also in production, babel-plugin-transform-remove-console can be used to clear all console.* methods automatically.
The reason for different execution speeds of javascript code when running in debug mode and without is that when you are in debug mode, in order to enable the debugging experience React Native executes the code in the Chrome browser on your computer, and the results of the execution are bridged onto the device.
Outside of the debug mode, the code is executed in the JavaScriptCore engine on the device itself.
That said, I cannot explain why the execution is so slow on the device. Are you perhaps running on an low-powered device, or an emulator with limited allocated memory?
React Native app does run slower on Android. But the performance is not real during your development. You can build a release version to check the real performance, release version is much faster than dev version.
There are also some bad codes which can make your app slow. Like console.log(), it does slow the app during development. Avoid unnecessary re-render the view, don't use arrow function and .bind in render, etc.
I have the same issue on IOS device (ipad4, ios10). I don't use redux-logger and removed all console.log, still don't know what makes the app so slow. It takes 2s to swich between tabs.
"react-native": "0.41.2",
"react": "15.4.2",
"native-base": "^2.0.10",
I know it is an old topic but suffered the same problem. I applied the above solutions but the problem still presisted. Later I found out that problem caused by a emulated USB storage device rather than mounted as a USB disk. Because when you upload signed Apk file and install the appllication from this file it causes problems and gives write error e.g. hiddenly but don't gives error messages much. I hope changing from emulated storage device to mounted as a trivial disk helps who suffer the same problem like me.
I spent some time debugging a SL3 application with VS 2010 in IE9 beta today and noticed a few quirks. Sometimes when launching the Silverlight app in VS it fails to load in the browser, but refreshing with F5 tends to fix the problem. Also, there are sporadic scripting errors that pop up a debug dialog - these also seem to be fixed by refreshing the page. Has anyone run into these problems and found a fix?
EDIT: My most prevalent error is:
Error: ASP.NET Ajax client-side framework failed to load.
I don't understand why, but someone without a name at the Silverlight forums has found a solution that worked for me:
Just add or uncomment this entry to your hosts file (%SystemRoot%\system32\drivers\etc\hosts):
127.0.0.1 localhost
I noticed this as well with Silverlight 4, but also when I start a simple web project.
IE9 has a shorter startup time that IE8. Debugging a Silverlight application starts the development web server to host the http:// site. The time that it took to start up the web server was less than the time to start up IE8 and greater than the time it takes to start up IE9.
#Michael S. Scherotter - It can't be because of the shorter startup time because making the host file change which fixed it for me would have zero impact on app startup time. Something else must be causing the browser and Cassini to not talk to each other correctly.
One other fix, related to the others is to change the StartURL to launch to the loop back address directly, rather than editing the hosts file. So, in one app, I've got this as the start URL:
http://127.0.0.1.:60525/
Of course, to make this work consistently, I've selected a "specific port" in configuration, as 60525 in this case.
(the trailing . after the loop back address is to allow Fiddler to do its magic).