Community
Participate
Working Groups
Build Identifier: 1.4.0.20111209-1413 Occasionally we face Javascript errors during startup of our application. The exact message differs between Firefox and IE. But in both browsers the place where the problem manifests is org.eclipse.rwt.HtmlUtil.removeStyleProperty(). In case of an error the execution path leads us through the else block of the method. Using FireBug we observed the parameter "b" (or "target" when using the names of the long version of the JavaScript) and saw that it was either of type org.eclipse.swt.widgets.Shell or org.eclipse.swt.widgets.Composite. We could not get any further information on why the instanceof expression was evaluated to false. The whole thing seems to be a timing issue. On some of our developers' machines the phenomenon never occurs, while other colleagues face the problem in about 1 of 10 startups. When the problem occurs only a server restart helps. Reloading the page or switching browsers does not work. So there seems to be a stable server side error situation. We were never able to observe the problem when using the debug variant of the client-side library. Reproducible: Sometimes Steps to Reproduce: Start server. Try to start application.
Created attachment 208589 [details] Error message when using FireFox
Created attachment 208590 [details] Error message when using Internet Explorer
Does it not happen with webkit, or did you not test it with Safari/Chrome?
Created attachment 208604 [details] Error message when using Chrome
Created attachment 208606 [details] Error message when using Safari
The problem is independent from the browser. I've attached the logs if tried from Chrome or Safari
This is very strange. Do you have this only with your own application, or also with any of the demo applications? Could you perhaps attach the javascript-client-code that was recieved by the browser when such an error occured? In Firbug go to the Network tab, open the request that delivered the JS (the first big one), and copy all Content from Headers and from Answer to a text file.
Created attachment 208617 [details] Zipfile containing headers and response of the javascript library
Interresting. The javascript client is delivered TWICE (client-core->custom-widgets->client-code again). Since there is no check against that, the second client partially overwrites the first one, and some classes seem to extend classes from client1, others those of client2, and *booom*, instanceof fails.
Created attachment 208657 [details] Zipfile containing response of the javascript library without custom widgets We can confirm the duplicate entries in case of error. In the good case the transferred library has half the size. We found, that we deliver custom widgets too. To eliminate possible problems, we disabled the custom widgets. The problem still occurs. The attached response contains only plain rap scripts.
This issue reminds me of the problems we had with concurrent requests right after startup (bug 277994). Before RAP 1.5, the first user session had to run "isolated". Can you also reproduce this issue when you ensure that there are no concurrent requests immediately after startup?
During the test, there is only one user using the application. It is started as RAP Application in Eclipse, one Browser is accessing it. During startup a login is performed and the user is directed to a login page if he is not authenticated. After user and password entry the application start is retried. If I set an breakpoint on the write method of ResourceUtil, I can see that the client.js is registered once per login with its original size. The written file in the .metadata directory is exactly the same as those within the q07 bundle.
Although the resourceUtil is writing the client.js in the correct size to the metadata directory on each startup request, this does not affect the cached content in JSLibraryConcatenator. Those stores the mixed content of two times the original client.js which is then delivererd to the browser. So the problem seems to be similar to those dscribed in bug 277994 you mentioned.
After a longer debugging session I have been able to reproduce the problem regularly: Our application registers a ServiceHandler and embeds an hidden object on the main application page to connect this ServiceHandler periodically. This is used for session and license tracking. If a browser window is kept open after successful login (so the connect requests to the ServiceHandler are activ) and the server is restarted, then the application will run into the script error if the ServiceHandler is called by the old browser window before the login on the new window has been performed. Vice versa I have not been able to reproduce the problem, if all browser windows to the application have been closed before restarting the server.
The cache is opened for writing during registerJSLibraryServiceHandler() by calling: JSLibraryConcatenator.startJSConcatenation() It is kept open until the StartupPage is completely loaded. Another request for a LifeCycle gets mixed up with the orignal request because it is only closed during the generation of the startup page. I could fix the problem localy by installing a patch bundle where I put a sychnronize block around the getStartupPage in LifeCycleServiceHandler.runLifeCycle() Thanks for your hints they lead me to this workaround.
(In reply to comment #15) Harald, good to know that you've found a fix that works for you. We're already in the release candidates of the last service release for 1.4 and we're going to avoid patches that affect internals like this for 1.4.2. Even if unlikely, there's still a risk of introducing a deadlock or degrading performance. Our advice for RAP pre-1.5 has always been to start the server in isolated mode, e.g by opening a firewall not before successful startup. Since this issue is not present in 1.5 anymore (see comment 11), I'll mark this bug as fixed for 1.5.
