I have a decent machine capable of running 64 bit Windows 7. So how come any time I stop a small sample GWT app in "development mode", edit it and restart it it takes 30 sec to become responsive in the browser, both in latest Firefox and latest Chrome?
Is that sort of molasses-based edit-compile cycle just the normal, expected thing for GWT developers nowadays?
Will it get much worse for more realistic apps or is the whole of those 30 sec just the framework overhead, and my own code would not make it much more bloated than that any time soon?
Can this problem be alleviated by using some other "mode" or by whatever other tweak solution?
Do Google people have much faster machines than I do on which this is less of a pain or do they suffer like the rest of us?
During development, a GWT application can be run in different modes, and there's often a bit of confusion about when it's necessary to
restart the server,
reload the server,
refresh the browser,
or just click somewhere in the web page.
Let's take a step back and look at all the differences between Development mode/Production mode on the one hand, and "With Debugger"/"Without Debugger" on the other hand. Of course, everybody using GWT has already heard of them...
Mode
Development mode
Runs the client side with a special browser plugin that attaches to a code server. You can always identify this mode easily by looking at the URL - it will contain something like ?gwt.codesvr=127.0.0.1:9997
The main advantage of Development mode is, that it doesn't require you to compile your code to JavaScript first - it runs the client side as Java bytecode in the code server. This is basically a JavaScript emulation - but it's so close, that most people don't notice the difference anymore (some even believe, that GWT compiles Java to JavaScript in Development mode, which is not the case.)
Since the code is run as Java bytecode, this mode also allows you to attach a debugger for the client side code, as we will see a little bit below (but you don't have to!)
Production mode
Runs the client side as compiled JavaScript. Before you can use it, you have to use the GWT Java to JavaScript compiler first (often known as gwtc, or "the one with the
icon")
After it's finished (takes a while!) just start the GWT embedded server like in development mode, but this time remove the ?gwt.codesvr=127.0.0.1:9997 from your URL. (Alternatively, you can deploy the war to a separate server (e.g. Tomcat), and run it from there.)
The advantage here is, that a) you can test the real compiled result, and b) that browser refresh is very much faster than in Development mode.
Launching
"Without Debugger"
You can simply run the application without attaching a debugger (that's possible both in Development and Production mode). Use "Run As...", if you use Eclipse.
In Development mode, this means that you run a web server (embedded Jetty, usually on port 8888) and a code server (usually port 9997). In Production mode, you don't need the code server.
If you have client side changes, they will be reloaded when you refresh the browser. This is relatively fast - you don't have to restart the (code) server. But it's not as immediate as with a Debugger.
If you have server side changes, you will have to do a server web application reload (in Eclipse, you use the small yellow reload icon in the Development view) This is much faster than a full server restart, but once again, it's not as immediate as with a Debugger!
"With Debugger"
Both in Development and Production mode, you can run the application with an attached debugger. Use "Debug As...", if you use Eclipse.
For Development mode, the debugger attaches both to the client and the server side of the code - whereas in Production mode, it can only attach to the server side!
If you have client side changes with an attached debugger, code changes will take effect immediately, so all you have to do is to click somewhere in your web page that causes the code to run.
If you have server side changes with an attached debugger, likewise, code changes will take effect immediately, so all you have to do is to perform some action that causes the corresponding server call.
All of this is extremely fast, but the drawback is, that Java debuggers can cope only with certain kinds of code changes. If you have more severe changes, the debugger will exit, and you'll have to restart the server (I'm still looking for a way to just reload and reattach in this case - I think it should be possible, but does anyone already have a working solution?)
Also, with debuggers, you'll have to be careful with the state of your application. Remember, that the changes to your code won't re-evaluate the existing state!
So you basically have four combinations
Development mode without Debugger
Client change: Use browser refresh (medium)
Server change: Reload server (fast)
Development mode with Debugger
Client change/server change: Just click on the web page (very fast). Restart server, if this fails (very slow).
Production mode without Debugger
Client change: Recompile, then refresh browser (very slow)
Server change: reload server (fast)
Production mode with Debugger (for the server side)
Client change: Recompile, then refresh browser (very slow)
Server change: Just click on the web page to cause a new server call (very fast). Restart server, if this fails (very slow).
Additional differences:
A simple browser refresh in Production mode is much faster than in Development mode.
GWT-RPC in Production mode is much faster than in Development mode.
Each combination has its own benefits and drawbacks for development speed and convenience. I like to use all of them, depending on the situation.
This post has become a bit long, but I have seen lots of questions around this topic, and I wanted to write it all down in one place. Thanks for reading :-)
I guess my answer is in the form of a question, "Are you sure you're really needing to restart at all?"
Assuming you're running it hosted within the browser (which it sounds like you are) then most changes are "hot" almost as soon as you've finished them. I spent yesterday doing all kinds of changes to the main code file in a module and didn't have to restart the server for any of them.
I often had to reload the page within the browser to see the changes, but that's a different issue.
In GWT development mode every time you reload a page the dev server recompiles the GWT app's source. This enables you to just do some changes to your GWT code and just reload the page in browser to see the changes - no need to restart the dev mode server.
When you deploy your app on production server you deploy already compiled javascript files. So the delay you will see will be time to load those pages.
Related
I have built and started an OPC UA embedded Openmodelica server with the BouncingBall model like so:
$ omc +s path/to/model
$ ./BouncingBall -embeddedServer=opc-ua -rt=1
Now I'm trying to interact with it using an OPCUA client. However, I don't understand how I'm supposed to interact with the server properly. As far as I know this is undocumented.
The most promising approach seems to be to set enableStopTime to false and run to true. Then the simulation seems to run indefinitely and the values seem to make sense. It seems I'm only able to extract the values in real time however. While running, when I set run to false it seems that the server enters an erroneous state and it refuses to give any values back.
If I restart the executable and instead set step to true nothing seems to change and after trying to set step to true a second time the server becomes unresponsive. The -rt=1 option doesn't seem to matter. Seems like it enters the same state as above (1).
(After restart) If I leave enableStopTime to be true and set run to true the simulation runs to stop and then the server quits with message The simulation finished successfully. Maybe this is intended. Kind of seems odd. Would make sense to be able to restart the simulation or trigger it with new options.
What I would hope to be able to do: Start and stop simulation as well as rewind to a certain point to check the value at that point. It seems to me that the API "affords" this functionality and it could probably be provided by hackingly wrapping the executable and API. Are the above bugs or intended? What is the intended way to interact with an OPC UA server in these cases?
The OpenModelica compiler version is 1.16.0~1-g84b4a71
Please try the latest nightly build
It includes the following commit.
That might solve it. I believe things worked without subscriptions before, since I could never reproduce this without them.
(By the way, do people go on our git commit feed and try to reproduce bugs fixed in the last 24 hours; we quite often get questions that were just recently fixed)
To set the seem, I'm an experienced developer and have coded many languages over the years, including a good bit of Perl back in late 90's early 00's. Since then I haven't touched Perl, but now have a client who wants some changes making to an existing open source project built using Perl5 and Catalyst. I've quickly worked through the Catalyst tutorials, read a few books online and am now starting to feel my way.
I have the existing project up and running on a clean Debian Wheezy VM and am testing the code an my changes using the Catalyst Development Server.
While working through the tutorials and writing a few test apps, the development server would always output a lot of useful information when run, such as the configured routes etc.. But under this project, when I run the server I don't get a lot of output. I don't even get messages sent to $c->log->debug();
I run the server with the following command:
perl ./script/asnn_panel_server.pl -d -r
Which outputs the following:
HTTP::Server::PSGI: Accepting connections at http://0:3000/
I can access the server and the application is running fine.
In a test controller action I can try the following lines:
$c->log->debug("A test debug message");
print "A test print message\n";
The debug log message does not appear in my development server output, but the print line does. So I know the call to $c->log->debug() is not blowing up, because the next line is executing, but where is it going?
So essentially I feel I 'could' get more useful output from the Catalyst Development server, but am not.
I have googles but can't find anything of relevance. Sorry if I'm going in the wrong direction here, I do know what I doing in general, but have a lot to pick up here in a short amount of time!
I suspect my issues might be specific to the open source project I'm working on, but there's not a lot of help to be had from that direction. Could anyone give me any pointers as to what to investigate?
UPDATE : I now realise that the application is using log4perl, which is configured to send $c->log->debug() to syslog. I still don't know why the Catalyst Development server isn't providing much output.
:wq
For anyone coming upon this later, if you want to see the developer debug stream (stuff about the routes and classes and models your application is using, etc you need to be in debug mode, which you can do easily by setting CATALYST_DEBUG=1 in your env (I often start my app like "CATALYST_DEBUG=1 perl -Ilib script/myapp_server.pl"
There is sadly a difference between debug as a log level and debugging mode. The way catalyst works is that if you are in debugging mode (via CATALYST_DEBUG=1, or any of the other documented ways this gets turned on) all this debugging stream gets sent to the log, most of it logged at the debug level (again debug as a log level is distinct from debugging developer mode :( ) So you need both debugging mode and your logger should be set to listen at the debug level.
If you use the default catalyst log, it is debug level by default, so doing CATALYST_DEBUG=1 is all you need. If you use a different logger be sure to enable debug log level for your development setup, if you wish to see those developer stream logs.
Messages sent to $c->log->debug() are generally disabled in production environments. If it doesn't seem to matter whether you start your scripts with or without the -d switch, then I'd suggest something downstream in the sequence is setting the environment variable CATALYST_DEBUG to 0 or undef unilaterally.
That said, you should be able to see the output of $c->log->info() or $c->log->warn() calls. The answer to that question should help you determine if the problem is log4perl or Catalyst related.
Hopefully that will get you on your way.
I am using GWT 2.5.0 and in my server side code there are several datasources so i am not able to run embedded jetty server.
So, I am resolved to use gwt debugger with -noserver option. Now i am able to debug my application but every time i refresh my browser, it takes hell lot of time to load application on browser and also it is very resource consuming.
On my eclipse, i can see through log message on console that every time i refresh, it recompiles all the RPC classes and verify.This process takes a lot of time.
My question is that it should happen only for the first time app gets loaded on browser not on every refresh. Is there any way, to get rid of this. It really takes lot of my time.
Looking forward for the help,
regards,
pankaj
We use JRebel. It spared us months of redeployment efforts. I consider it much better than GWT super dev mode.
I'm doing some stuff using GWT with rpc calls in order to get MySQL queries. These queries can be big (up to 500 entries). When I do the RPC call, the browser freeze ( for example, my loading .gif image is frozen ). I thought using RPC call with asyncallback would avoid this problem but obviously It doesn't.
My tests are made on Eclipse (GWT dev plug in) in development mode so I was also wondering if the problem does not come from the server provided by Google. Moreover, I would like to know if this problem will stay when I will deploy the application to an other server. If no, could give me some advices to avoid this type of problems.
First of all, are you running this query on the load of the application? If it is the case, then it is normal.
From my experience with gwt, elcipse and Tomcat, the freeze only happen in Eclipse. When you deploy your application on a server such as Tomcat, this problem will disappear even if the RPC call is on the load of the application.
I'm having trouble with Web Start.
There is no problem if I start the application from IntelliJ.
With Web Start it's working ok most of the time but at a point I'm loading 10000 records from database and there it's getting very slow.
What can I do?
Thanks,
It is possible that running as a WebStart application, your application has diferent memory settings. You should attempt to tweak those (as described here) and see if that makes a difference with application performance.
Other than that, you should profile your application to see where the delays occur (which parts of the application, what kind of operations, constantly or intermittently etc.)