We have a very complicated page with a bunch of partial refreshes going on getting data from several sources and utilizing DOJO and jQuery . Everything works as it should with no problem.
However, when the page is opened multiple times in the same browser on different tabs its seems to lose its session somehow. The partial refreshes don't work anymore and it keeps executing the before and afterPageLoad.
Everything client-side still works, but any calls to the server end up doing nothing.
This happens more when we duplicate the page very fast, if the page is allowed to load fully, the problem seems less frequent.
Telling the browser not to cache seems to make it worse, so it probably has to do with too much traffic.
The pages does use a lot of viewScopes to store data, but no sessionScopes.
Any tips where to look would be appreciated.
Are you losing viewScopes or the whole session? (For an application that requires authentication, you would be prompted to authenticate again when fully refreshing the page. It doesn't sound like that's happening, but I'm not certain.)
Xsp Properties has a setting to determine how many pages to store either in memory or to disk for each page for the current session. Because the current session means the browser session, you might be opening so many pages it dumps the page, so will also dump the viewScope for the earliest tabs. Even if it's the same URL, it will treat it as a separate page if it's a different tab. The number of pages kept is stored on the persistence tab of Xsp Properties. I can't remember what the default is, but 16 rings a bell. It should be documented in XPages Portable Command Guide and possibly Mastering Xpages Second Edition.
It seems it was the page persistence after all. I changed it to 40 and this time I restarted the HTTP task (neglected that the last time).
I can now load other pages without any problems.
Now if I load 40 pages fast, reloading before the page has finished loading, the first one stops responding. If I load it 'normally' 40 times everything works as it should.
seems like the server can't handle the quick reloads.
Related
Greeting, brethren,
So I inherited this app (yes, XPages can be legacy now ;-). It is meant for the Notes client only and one process takes a convoluted route via what I understand is called a Managed Bean (the Code/Java design element).
The database resides on a server.
When editing said bean.java, I meet two issues.
If I test immediately thereafter, I'm greeted with an Error 500 that won't go away unless I close then restart both Notes and Designer
In some cases, changes made to bean.java are not immediately available. So far I haven't been able to characterize those cases. For example, yesterday afternoon I could no anything, nothing would bring a change to the Notes client. (Yes, I cleaned & rebuilt and autobuild is disabled). This morning changes are apparent immediatly (save for the quit/relauch bore).
I've tried to set xsp.application.forcefullrefresh=true in the app's Xsp properties but haven't noticed much effect.
What am I doing wrong ? What could I do to fluidify the modifying of a bean ?
When working in XPiNC, after every change you have to close and restart designer. If I understand things correctly, it's trying to access class files that have been discarded. That's why whenever I've had to develop for XPiNC, my initial testing during development is on a browser, I would recommend this approach.
There are minimal differences in syntax, usually only encountered if manually creating URLs to files etc or using the bad practice "" to specify database location in #DbLookup. Wherever possible, avoid #Formula approaches, their performance is worse than object orientated methods (e.g. view.getAllEntriesByKey())
It's the same for the bean. There are only two ways to speed up picking up updates - use a browser or use XPiNC on a different PC.
Load any xPage
Refresh db design
Reload the xPage by either F5 or Ctrl+F5.
then almost all functions stop working without any errors. E.g. nothing happen if you click buttons or menu items. After restarting web browser some functions come back but some still doesn't work. After cleaning browser's cache almost 90% UI start working but some still need to reload the page few times. Is there any xPage app properties or Domino properties to adjust to fix that problem and make xPage app work smooth even after design refresh
Design Refresh didn't reload custom Java classes when refreshing with 8.5.3 FP1. This was fixed, I believe, in FP2. But that doesn't sound like it's causing the problem here.
Design Refresh will not reload jar files. That requires issuing "restart task http" to the console. ("tell http restart" doesn't properly reload everything XPages needs.)
If your application is using a Single Copy XPage Design to hold its XPages design, that too will not update until you issue "restart task http" to the server. The design seems to be cached by the server for better performance, but refreshing the design of the SCXD database doesn't reload that design. It's unclear if that's your scenario here.
XPiNC may also not update immediately, but I've not tried that. The runtime there is basically in the Notes Client itself, so I could understand that it would not update.
Otherwise, I would echo Thomas's experience, I've not seen any other issues (and my applications heavily use Java). I haven't needed to clean the application following a design refresh. Existing browser sessions will have problems with partial refresh calls, I would expect that. But a refresh of the page make all functionality work.
There are two scenarios I would expect to have problems.
The first is if you are storing anything in sessionScope or applicationScope variables that are required by your application, but your code only loads those on a specific page. If you refresh the design, the scopes will get dumped and so not reloaded until you go to the specific page. Typically I put such initialisation code on my layout custom control, so a page reload will always initialise it if it's dumped by a design refresh.
The second is if another user accesses the application and has Build Automatically switched on, which could result in the application being rebuilt without you realising it. It doesn't sound like this is happening for you though.
I am embedding an org.eclipse.swt.browser.Browser into a view in a modified eclipse (Indigo), for use as a preview pane of a form editor component. On a form model change or an element selection change the code renders the form via vaadin 6 and displays it in the browser component.
Now, this works like a charm in most cases. But for some highly complex forms the HTML+JS generated by vaadin generates a lot of stress on the browser, rendering it unresponsive for up to a few seconds. That in itself wouldn't be tragic (1), but as long as the SWT Browser component is busy rendering that stuff, the entire eclipse UI thread is blocked.
A simple way to reproduce this is to create an HTML page that blocks inside a javascript function (see https://gist.github.com/creinig/5150747 for an example) and display it in the SWT browser. As long as that JS function is running, the entire SWT application is not responding to anything.
The only info I've found on this problem are
one SO question (without resolution) and
one question on EclipseZone (unanswered).
Not that helpful :(
The API docs of the Browser component don't seem to offer any insight on whether its rendering is triggered periodically by the UI thread or if itself triggers something that blocks the UI.
Is there a way to decouple the Browser component's rendering from the SWT UI thread? Or anything else that could be done to protect the eclipse UI from hanging stuff in the browser?
(1): We need forms of this complexity level, we're already optimizing the rendering performance and a switch to vaadin7 will most likely also speed things up. But the problem will certainly persist, if only in reduced severity.
Not a real solution, but a workaround that Works For Me (TM):
As described here it is really easy to launch the system's default browser from SWT. So I'm going to add an option to the view containing the browser control that will "detach" the view by disabling the browser control and opening the system browser instead.
In case the linked page drops off the net, here's the gist:
org.eclipse.swt.program.Program.launch("http://my.funny.url/");
launches the application registered for HTTP URLs. In other words: the system default browser.
Happiness ensues :)
I have had a report that my company's website is resizing at least one employee's browser windows. I experienced this behavior myself on the user's computer, and it was mystifying because the resizing only occurred on our site, not on any other site, and it occurred on both Firefox and Internet Explorer. The user has a Windows 7 machine running updated software. She has no add-ons, themes, or plugins besides the usual (Flash etc.) and her settings are the factory defaults. I cleared the browser cache on both browsers and restarted the computer and it still occurred. The only thing left is the css, but none of it seems suspicious to me.
What is happening is, when she clicks a button or internal link on the site, then when the new page finishes loading, the browser window resizes to approximately 80% of the width of the content. That is, the very last thing the page does as it loads is to resize itself. If she zooms in or out, then on the next load, it again resizes to 80% or so of the smaller or larger size of the content. If she maximizes and then loads a page, then the window resizes to 80% but somehow maintains the "maximized" icon. (You then have to click twice on the "maximized" icon to maximize.)
The reason I am flummoxed is that I thought this kind of behavior was something you could only do with JavaScript, but I deliberately tested this with pages that had no JavaScript at all and it still occurred. There is exactly one page on the website that has browser-resizing JavaScript on it, but it resizes to a pixel size, not a percentage, and it's part of a web service that wasn't in use while I was testing.
What kinds of things should I investigate to solve this issue? Because this is an employee, I have to either fix the website or fix her computer, so ideas for investigating both would be great.
The problem turned out to be that single page with browser-resizing JavaScript I mentioned. Another set of pages had needed some JavaScript functions from that web service, so one person had copy-and-pasted the functions that were needed. Then someone else came along, noticed that the copy-pasting was a dumb idea, and decided to simply include the JavaScript file that had those functions instead.
The problem was, the command to resize the window was bare in that file. For that one user, that command was being carried out and resizing every window. For everyone else, their browsers were ignoring the resize command except on the web-service popup window. I can only assume she had the problem because she had factory-standard settings, and the rest of us didn't. To fix the problem, I moved the resize command from the JavaScript file to the head of the web service page.
I have developed a chrome extension. The extension itself works fine and fast.
But when I start the browser and click on the toolbar icon of my extension it takes about 2 seconds for the popup to appear and to show its content (this happens anytime the browser is restarted).
Any idea what causes this and how to fix that?
Tip 1:
Use your popup page for rendering exclusively. It should be as light as possible. All the heavy loading/processing (localStorage, XMLHttpRequests, blocking javascript) must be done in the background page.
The background page is loaded when Google Chrome starts. Basically, it allows you to execute code and keep a page always running (although the popup is not present). For instance, streaming audio in a html5 tag with no popup.
Note: If you are not using a background page yet, you should be taking a look to message passing first.
Tip 2: Warning: This could fail
I haven't tested this yet, but maybe using the HTML5 manifest.cache can help you preventing loading again resources stored locally. But beware, this is HTML5 and is prone to changes and unstability across versions. (also, I am not completely sure that the cached resources will be loaded in memory before the popup is opened)
Hope it helps!