I have made a Wai web application and it is being run using Warp. However I have one AJAX request that takes quite some time to finish, while that request is pending, no other requests will be accepted by the server. I thought Warp was capable of handling concurrent requests. Am I missing something? The way I run Warp is just by calling run port app where run is imported via import Network.Wai.Handler.Warp (run) and app is my Wai application.
I was trying Happstack Lite to see whether it would solve my problem, and there the -threaded flag was used when compiling the web application, which also solved my concurrent requests problem in the Warp application. I was under the assumption that GHC would have threading support by default, but apparently this have to be specified explicitly during compilation.
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 working on the design of an with RAP/RWT, working under Tomcat. I'm learning RAP now, and a couple of questions come to my mind.
My application has a backend that works continuously gathering data from certain sources. On the other hand I want to create a frontend (RWT standalone application, or RAP with workbench functionality, not decided yet) running as a webapp.
First question: should I keep the backend as a separate process, and let the frontend RAP application communicate somehow with it? Or can I integrate everything together in the RAP application? Integrating everything together leads to the second question.
Second question: how can I detect from within the RAP application, when is the browser window/tab holding my app, closed? I would like to do some resource cleanup when the user closes the graphical interface (i.e. closes the browser). I cannot find anything equivalent to ApplicationWorkbenchWindowAdvisor#preWindowShellClose in RWT standalone applications. Same to dected when the application is started. In general, are there callbacks to follow the webapp lifecycle in RWT standalone applications?
Thanks a lot for your help!
Regarding your first point: When you use EJBs, please be aware that you can only directly access Java EE contexts from the request thread. This is not a problem when you run in JEE_COMPATIBILITY mode, but in SWT_COMPATIBILITY mode you may need to access your EJBs through RWT.requestThreadExec( Runnable );.
As for your second question, the RAP server is currently not informed on browser closes. This issue is discussed in bug 284273 - Session kill mechanism on browser close. It is not yet implemented because IIRC we couldn't find a reliable method of doing so that works in all browsers.
You could implement your own solution using a) the JSExecutor to put some JavaScript on the client that sends a request on browser close, and b) a PhaseListener that listens to these requests and terminates the session.
(*) First: decoupling is always the best practice. I use RMI stubs for receive notifications from backend application (another RMI object or EJB beans).
MyEJBListener stub = UnicastRemoteObject.exportObject(new MyEJBListener(display, page,
manager, handlermanager), 0)
MyEJBClient client1 = MyEJBLocator.findEJBClient("abc");
client1.addListener(stub);
In the stub use something like
public void notify(Event event){
UICallBack.activate("stubthread");
Display..asyncExec(new Runnable() {
// update event info
});
}
(*) Second:the method WorkbenchWindowAdvisor#postWindowClose can help you?, and call somethig method form backend app.
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.
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.)