This issue may have to do with a very specific Domino version (see below), so I start with a few technical details:
Server in question is a virtualized Windows 2008 R2 64bit machine. Domino release is
IBM Domino (r) Server (64 Bit) (Release 9.0.1FP4 HF70 for Windows/64)
The latest JVM security patch (9.0.1.4 dated 20150724) is installed.
I may be wrong but I feel that the issue started after we installed the latest patches (FP4 HF70 and JVM):
On an Xpage I have a very simple "Refresh" type button just triggering a partial refresh on an xp:panel (id="pnMainContainer") surrounding the bigger part of my page. Amongst other components there is a tabbed panel inside pnMainContainer. This is set to open with the first of three tabs upon loading the page.
Assuming that I have the third tab open, usually if I click the Refresh button tab #3 stays open, and its contents are freshed as expected.
Sometimes however, after I left the page open for a several minutes (can't really say how long, maybe somewhere around half an hour), the refresh obviously is returning to its initial state, showing the first tab instead of the one that was open before, and emptying all editable fields that were filled before.
When that happens I see the following warning appear on the console:
HTTP JVM: WARNING: CLFAD####W: State data not available for /myPage
because no control tree was found in the cache.
I am aware of this post here: Xpages document changing document mode?, and although I don't use Xagents in my application I tried setting my page's viewState property to nostate. This apparently didn't help solve the problem.
One more detail that might be helpful is the fact that the page in question makes use of a managedBean bound to the viewScope.
Any ideas what could be causing this, and - moreover - how to change this behaviour?
Update 2015-09-10: following #Paul's suggestions below I set my application's session timeout to 120 minutes last night (xsp.session.timeout=120). This morning I tried again: loaded the page in question then let it sit there for approx. 45 minutes. After that time hit my partial refresh button. Result: page is reloaded to its initial state, and server console is showing the same warning as yesterday.
For completeness sake here's the entire contant of my application's xsp.properties as it is at the moment:
xsp.error.page.default=true
xsp.library.depends=com.ibm.xsp.extlib.library
xsp.resources.aggregate=true
xsp.theme=oneuiv3.0.2
xsp.session.timeout=120
xsp.application.timeout=120
xsp.persistence.mode=basic
Is there probably something in there that would be causing this behaviour?
Some more details: did some more testing and found the following details:
with the above mentioned xsp.properties caching appears to be stable for quite a while as long as I let the pages just sit there
as soon as I make any kind of adjustments somewehere on my page or in related codes (SSJS libs, managed beans, or the page itself) cache needs to be rebuilt as the state of my page is lost (even after a few seconds). It doesn't matter at all whether "Build automatically" is turned on in Designer or not
Tried setting page persistence from xsp.persistence.mode=basic to xsp.persistence.mode=file. This results in a "java.io.NotSerializableException" as soon as I open tab #3 which makes use of internal properties of a managedBean that is registered at a viewScope level
Built a very simple app on the same server with just a few partial refesh buttons: result is that page state is never lost for pages from this test application
As long as the cache is lost only when I update design I don't really care. But I'm afraid that this might escalate if many users are starting to access the pages.
Anything else I could do to improve performance?
viewState="nostate" basically means don't store the component tree or scoped variables for this page server-side. That's why you use it for XAgents, which will never be partially refreshed.
The key data is:
1) How quickly the XPages session is set to timeout. Once that times out, you'll lose state data. I don't think keepSessionAlive control helps here.
2) Whether other tabs are being opened in the browser. There are other XPages properties that determine the number of pages stored in memory / disk. The maximum is stored for the whole browser session and, once you hit the maximum, the earliest is dropped from memory, hence the same message (and the other reason for setting nostate on XAgents.
It sounds like the first is the cause. Note that XPages session timeout and http timeout are separate timeouts. The first is when the state data for the current session is removed and is application-specific (because each XPages app has a separate runtime JVM), the second when a subsequent request to the browser will prompt for authentication.
Related
I was wondering how to preserve an application when the user leave the application completly by going to another site (for example when the user logs into the application and then goes to nytimes.com and then comes back to the application some components go missing). To preserve the application on a refresh you can use the #PreserveOnRefresh annotation, but this does not preserve the application when you leave it. The header, menu and footer are disappearing. These three components are have their own class and are only declared in the main ui. Each view (or page) has its own class (which sit between the menu and the footer). Everything works fine until the user leaves the webpage and comes back the header, menu, and footer disapear So my question is how to preserve my vaadin application when the user leaves it and comes back?
Well, there could be problem with serialization and deserialization from session. Make sure you have implemented Serialization interface for your own classes.
Have you tried to repaint the missing components? They should be set to setImmediate(false) during repaintRequest.
Anyway, ordinary Vaadin application works without problem after returning back from other url. So good luck.
To solve this situation you can add a listener to the navigator which will get the uri to the page you are going to and check your permissions. If you do not have permission it will keep you on the same page and give you a notification saying that you are not allowed to go to this page. If they are allowed you will proceed to direct them to that page.
What components are missing when you go back to the application? Vaadin applicaction lives as long as web session. If I go to nytimes.com and then go back before the web session ends, the Vaadin application will survive (if it has #PreserveOnRefresh) or will be renewed
I'm having this very annoying problem to troubleshoot and have been going at it for way too many days now, so have a go at it.
The Environment
We have 2 app-servers, which can be located on either the same machine or 2 different machines, and use the same signing certificate, and host 2 different web-apps.
Though let's say, for the sake of our study case here, that they are on the same physical machine. So, we have:
https://company.com/webapp1/
https://company.com/webapp2/
webapp1 is GWT-based rich-client which contains on one of its screens a menu with an item that is used to invoke a Java WebStart Client located on webapp2. It does so by performing a simple window.open call via this GWT call:
Window.open("https://company.com/webapp2/app.jnlp", "_blank", null);
Expected Behavior
User merrilly goes to webapp1
User navigates to menu entry to start the WebStart app and clicks on it
browser fires off a separate window/dialog which, depending on the browser and its security settings, will:
request confirmation to navigate to this secure site,
directly download the file,
and possibly auto-execute a javaws process if there's a file association, otherwise the user can simply click on the file and start the app (or go about doing whatever it takes here).
If you close the app, close the dialog, and re-click the menu entry, the same thing should happen again.
Actual Behavior
On Anything but God-forsaken IE 8
(Though I admit there's also all the god-forsaken pre-IE8 stuff, but the Requirements Lords being merciful we have already recently managed to make them drop these suckers. That was close. Let's hold hands and say a prayer of gratitude.)
Stuff just works. JNLP gets downloaded, app executes just fine, you can close the app and re-do all the steps and it will restart happily. People rejoice. Puppies are safe and play on green hills in the sunshine. Developers can go grab a coffee and move on to more meaningful and rewarding tasks, like checking out on SO questions.
Chrome doesn't want to execute the JNLP, but who cares? Customers won't get RSI from clicking a file every other week.
On God-forsaken IE8
On the first visit, the dialog opens and requests confirmation for the user to continue to webapp2, though it could be unsafe (here be dragons, I tell you). The JNLP downloads and auto-opens, the app start. Your breathing is steady and slow.
You close the app, close that SSL confirmation dialog, and re-click the menu entry. The dialog opens and auto-closes. Nothing starts, the file wasn't downloaded to any known location and Fiddler just reports the connection was closed. If you close IE and reach that menu item to click it again, it is now back to working correctly. Until you try again during the same session, of course.
Your heart-rate goes up, you get some more coffee to make matters worse, and start looking for plain tickets online and a cheap but heavy golf-club on an online auction site to go clubbing baby polar seals to avenge your bloodthirst, as the gates to the IE team in Redmond are probably more secured than an ice block, as one would assume they get death threats often. Plus, the IE9 and IE10 teams are already hard at work fxing the crap left by their predecessors, so maybe you don't want to be too hard on them, and you don't have money to waste on a PI to track down the former devs responsible for this mess.
Added Details
I have come across many problems with IE8 not downloading files over SSL when it uses a no-cache header. This was indeed one of our problems, which seems to be worked out now. It downloads files fine, webapp2 uses the following headers to serve the JNLP file:
response.setHeader("Cache-Control", "private, must-revalidate"); // IE8 happy
response.setHeader("Pragma", "private"); // IE8 happy
response.setHeader("Expires", "0"); // IE8 happy
response.setHeader("Access-Control-Allow-Origin", "*"); // allow to request via cross-origin AJAX
response.setContentType("application/x-java-jnlp-file"); // please exec me
As you might have inferred, we get some confirmation dialog because there's something odd with the SSL certificate. Unfortunately I have no control over that. Assuming that's only temporary and for development purposes as we usually don't get our hands on the production certs. So the SSL cert is expired and doesn't specify the server. And the confirmation dialog. Wouldn't be that bad if it weren't for IE, as other browsers don't care, just ask for confirmation, and execute as expected and consistantly.
Please, pretty please, help me, or I might consider sacrificial killings as an option. And I think I just found a decently prized stainless steel golf-club, so I'm right on the edge of gore.
Side Notes
Might actually be related to IE8 window.open SSL Certificate issue. Though it doesn't explain why the dialog would auto-close (that really is beyong me...), it could help to not have the confirmation dialog and not need the dialog at all. For instance, I was thinking that just having a simple URL in that menu instead of have it entirely managed by GWT code to invoke a Window.open would solve the problem. But I don't have control on that menu, and also I'm very curious how this could be fixed otherwise and why the hell it happens in the first place...
I've figured a weird issue with Wicket 1.5.x. All of the sudden, wicket started to append a number that increases to every url which looks like mydomain.com/home?1. For every Bookmarkable link I click, wicket sends a redirect to the browser increasing that number. Same happens for when trying to clean the url and calling mydomain.com/home I end up with another redirect and an increased number.
What's even worse is that on Google App Engine the version number when clicking a link increase by the factor of two which also seems to cause issues with submitting forms which simply do.. well.. nothing!?
I've tried to play around with setVersioned(false)/true and setStatelessHint(false)/true without any result. What could that be, how to get rid of it and how can it influence my app not working on GAE?
thanks a bunch
Alex
EDIT:
It looks like wicket is always incrementing the version for my page as my base page is stateful (shows user's name if any in a model). But nothing changes on the site yet clicking i.e. my Bookmarkable Link to my home site increases it's page id with every click so if the user clicks 10x times on the home link his history is polluted with 10 entries of the exactly same page as nothing has changed.. this doesn't make any sense at all so I am curious how to fix that without loosing being stateful!?
The number represents the version of the page. It appears when the page is stateful (thus the server must track its state).
It takes a little more than set the stateless hint to make a page stateless. You must avoid any component that holds state on the server side, and use stateless alternatives (StatelessForm instead of Form, StatelessLink instead of Link).
I answered this question with an example of a stateless page: Is it difficult to make a mainly stateless web application with Wicket?
There is a Jira ticket: setVersioned(false) should force single Page Version about this issue. The question has also been discussed in the mailing list. Expected complications: Page Reload on Submit of non-versioned Page
To clarify: There are several problems I'm facing here, the most annoying of which is that my app engine logs appear very late in the admin console. I think that they may be related, which is why I'm grouping them together.
I was testing my app after uploading to Google App Engine about two hours ago, and I was tweaking the code and re-deploying. I use the Eclipse plugin and it says deployed successfully. I did not change the version number at first, and apparently all my changes were not being reflected on the server at all. I found out because my logs showed the old build number.
At this point in time, my logs were being updated real-time, and I could see logs from requests that took place seconds ago.
Anyway, I figured that I needed to change version numbers, so I did that and re-deployed, and made the new version default. After this my logs remained empty, even though I was testing my app continuously. And none of the logs of any of the versions showed the latest requests.
I checked my logs about half an hour back, and now it shows me the logs for the requests I was making then. Any requests I made at that point in time didn't show either - apparently I'll have to wait another hour for them to show.
Am I doing something wrong, or is there something about the App Engine mechanism I don't understand?
This sounds odd, I know. And I couldn't find anything about it on Google.
Problem 1: Described above.
Problem 2: Do I need to change version numbers anytime I make even a tiny change?
Problem 3: When I make changes to a servlet while testing on the local dev server, it takes approximately 3-4 minutes to reflect those changes when I test the app, even if I stop and restart the server. JSP changes reflect immediately.
I see the same behavior: On the initial deployment of an app, log messages seemed to appear real-time, but after a couple of days and lots of deployments, I see delays of up to 30 minutes. Known issue, apparently: http://code.google.com/p/googleappengine/issues/detail?id=3338.
Not required. After deployment, changed code without changes to the version number is immediately available on AppEngine.
Item 3 sounds like a browser caching issue. Does a forced reload (ctrl-shift-r on firefox) refresh your stale servlet pages?
I am working on a demo for a client of what's possible with GWT-Ext for GWT. After browsing for the simplest way to get up and running, I decided on installing the Google Plugin for Eclipse and using the New Web Application Wizard.
First time around, I followed these steps for create the default application:
Selected File > New > Web Application Project from the Eclipse menu.
In the New Web Application Project wizard, entered a name for the project (ExtDemo) and a java package name, com.extdemo.
Unchecked the "Use Google App Engine" check box.
Clicked Finish.
Right clicked it in package explorer and selected Run As > Run Configurations
Put a check in the Automatically Select Unused Port checkbox.
Clicked Run to see the default GWT 1.7 application
This worked fine... it launched GWT's hosted browser and the app worked as supposed to.
(I then continued to import GWT-Ext and add all sorts of widgets building up a nice little demo app)
However at some point when relaunching the app in hosted mode, the hosted browser displays an empty iframe. I even reverted the code to a point where everything was working as supposed to and... same thing, an empty iframe with the surrounding static content.
Now what is really strange is when I go through the process of creating the default application again by following the steps above, the hosted browser launches with an empty iframe again.
However when I click on Compile/Browse, this sometimes allows the app to launch in Firefox.
Anyone have this happen to them?
I have seen some odd behaviors occasionally. Here are some basic suggestions (some are dumb and you might have tried them already):
Use a new workspace
I do not know if GWT plugin somehow caches stuff in the embedded Jetty. If you are re-creating the default app/project, try and use a different name for the project.
Try and re-use a fixed port so that there is no possibility of having multiple servers running.
Update: Found a new "classic" solution:
Delete the cache in IE and possibly Firefox too. Apparently the 'script' tag content tends to be cached by IE. If this works, we can all try tearing our hair out!
Found the updated answer at this link:
I have had the same problem in the past and found it is much more likely to happen if limited CPU is available. For example if my older laptop was running on battery and had stepped down the CPU speed to save power it frequently happened. When running on mains in max performance mode it only happened occasionally. Now I have a much newer and more powerful laptop and the problem has gone away.
Another cause I found was too many breakpoints set up in eclipse and removing breakpoints would often clear the problem.
I've had issues with the browser caching.
Try clearing your browser cache, refresh a few times after a failed load, etc.
You can also try using a different port so the URL is different.
It takes some time to download and run the GWT app, particularly if you are using extra libraries, so wait for a few seconds to see if the app finally loaded.
What makes the app loading to fail randomly is something I don't know yet, but I suspect, as stated by Daniel Vaughan, that is related with a lack of computer resources, CPU, memory, etc.