I have a strange thing occurring; as usual, I can't post code, unfortunately, so I'm describing the problem in case anyone can suggest a possible cause.
I have an xpage with a custom control included on it; the custom control handles document locking and changing to edit/read-only modes via links. The document locking is done by setting an applicationScope variable based on the UNID. To make it more friendly for other users on the system, I run a function periodically on the page to check whether the document is locked or not and update a link/label/tooltips appropriately (e.g. if locked by another user, then the "Edit" button is disabled; when the lock is released, it's re-enabled). This is done by calling an "xagent" through a standard, simple dojo-based ajax call.
For some reason, the behavior of the system gets erratic after 45 seconds to a minute. I'm checking the lock status every ten seconds or so, so it's not happening with the first call. I'm displaying a list of records associated with the document; each record is a row in a repeat. When I first go into edit mode, the controls are all displayed as they should be, i.e. editable. If the user changes a particular value with a combobox, it updates the whole row with a partial refresh. When things get erratic, I noticed that the row starts refreshing in read-only mode, which suggests to me that the document is changing edit mode. The only time I knowingly change edit mode is if a "Cancel" or "Save" button is pressed. (The locking mechanism itself doesn't have anything to do with the edit mode.)
It certainly seems like the ajax call I'm making is at the root of this. But I've stripped the xagent and the client-side code down to practically nothing, and it's still happening. I can't see what would be causing this behavior. Can anyone hazard a guess? Thanks....
Maybe check if the server log file has warnings like:
WARNING CLFAD####W: State data not available for /page because no control tree was found in the cache.
If you're seeing those warnings, it could be that the server can no longer find the current XPage page instance in the cache. In that case the page will revert to the initial state, like when the page was first opened. That might be why the document goes to read-only mode.
The session cache of server-side page instances only holds 4 pages when xsp.persistence.mode=basic, or it holds 16 instances when xsp.persistence.mode=file or fileex.
If you load 4 xagent page instances, then that will fill the cache, and it will no longer be able to find the page instance for the current XPage you are viewing. So the XPage will stop performing server-side actions, and partial refresh will always show the initial state of that area of the page.
To avoid that problem, in the xagent page you can set viewState="nostate" on the xp:view tag, so that page instances are not saved for the xagent page, as described here:
https://tobysamples.wordpress.com/2014/12/11/no-state-no-problem/
Or else you can create and reuse one page instance for the xagent, so only one is created. That is, on the first call to the XAgent, have the xagent return the $$viewid value for the xagent page instance (#{javascript:view.getUniqueViewId()}), and then in subsequent requests to the xagent use that $$viewid in the request, to restore the existing xagent page instance instead of creating new instances that will fill the cache. So the subsequent xagent requests will be like so:
/myApp.nsf/xagent1.xsp?$$viewid=!aaaaaaaa!
It's hard to troubleshoot without code, but here are a few thoughts:
How are you checking document locking? Via a client-side JavaScript AJAX call or an XPages partial refresh? If the latter, what is the refresh area? If the former, what is the refresh area you're passing and the return HTML? Does it always occur when you're in edit mode on a row and the check happens, or independently of that? The key thing to check here is what the check for locking is doing - is it checking the server and returning a message outside the repeat, or checking the server and returning HTML that overwrites what's currently on the browser with defaults, e.g. the document mode as read mode.
What network activity is happening between the browser and the server and when? Is something else overwriting the HTML for the row, so resetting the row to read mode.
It's unlikely to be random, the key is going to be identifying the reproduceable steps to identify a common scenario/scenarios and cause.
EDIT
Following on from your additional info, is there a rendered property on the Edit link? If that calculates to false in earlier JSF lifecycle phases, the eventHandler is not available to be triggered during the Invoke Application phase. Because the eventHandler also includes the refreshId, there is no refreshId and refreshMode, so it defaults to a full refresh with no SSJS running. See this blog post for clarification http://www.intec.co.uk/view-isrenderingphase-and-buttons/.
Related
I have an XPage that displays fields in a document. I also have the ability to pop out a new window that displays those same fields. I'm implementing a document locking scheme so that the two instances can't cause conflicts (and this is how I'm testing it).
A problem I've run into is that when the user edits the document in the pop out and saves it, a partial refresh of the panel containing those same fields in the original page doesn't show the updated data.
The save in the pop out was successful, and I can see in the Notes client that the document does indeed have the new value, but the original page simply won't show the new value. A complete page refresh using the reload button in the browser works, but I'd like to trigger this programmatically and as quickly as possible, hence the partial refresh.
Does anyone know what is going wrong? Is the NotesXspDocument in the original page getting out of sync with the backend document? I read about document1.getDocument(true), but that doesn't seem to do anything.
(As usual, I can't supply source code unfortunately....)
Once the NotesXspDocument is loaded with the XPage, a partial refresh does not update the xspDoc from the back-end DB, but from the in-memory DataSource.
You will need to refresh the XPage:
Reload the url from browser or in ssjs with a context.reloadPage()
I have an xpage with a bunch of controls on it. One of them is a simple label that I'm updating with a partial refresh every five seconds. (I'm implementing a document locking scheme, and the label indicates whether someone has locked the document.) A button on the page fails to execute its event handler if I press it while the partial refresh of the label is occurring. At other times, it works fine. Is this a known issue, or is there perhaps something else going on that may explain this behavior?
(I'm unable to post sample code, unfortunately.)
You need to change your approach. Instead of a partial refresh, have an independent Ajax call to an XAgent for your locking (IMHO 5 sec is way to frequent, the WebDAV standard uses 30sec).
The openNTF WebDAV project has locking code you might be able to repurpose for your needs.
The independent Ajax call frees up the jsf lifecycle to run your other events.
I was recently developing an XPage that had an inputText control using a viewScope as the value. Below is the initial XPage name being used:
and this shows the viewScope values:
now when I switch to this Xpage:
the viewScope value for AccessNumber is not listed as expected:
So, now you would think that since the viewScope value for the AccessNumber has been removed from the viewScope map that if I return to the xpNewOrderFax.xsp page I would have to re-type my value. However, that is not what occurs. The viewScope value is listed once again as shown:
My question is whether this is an issue or by design because it was my understanding that a viewScope is available until you leave the current XPage. I have been able to get a co-worker to replicate this issue where the viewScope value disappears when leaving the current XPage and re-appearing when returning to the XPage. In the XPages Portable Command Guide on pg 213 it sounds like this is by design, but then on pg 215 it sounds like it is an issue. There is no value set for the application or session timeout settings on the XPage properties page.
Hopefully, someone can clarify this not only for me, but the many others using this research outlet.
Update at request of Per:
This is the code for the inputText control and I did a search to be sure I wasn't doing a viewScope.put("AccessNumber") or a viewScope.get("AccessNumber") anywhere else.
I didn't use the browser Back button when discovering this. I am using an outline entry, code below, to navigate from one page to the other, then a tab in the OneUI layout, property settings below, to navigate back.
I think Mark's comment is likely on the right track: if you go back in the browser and continue using the older page, you'll probably pick back up on the older page instance. The viewScope is tied to a combination of the page name (e.g. "/xpNewOrderFax.xsp") and the $$viewid value (e.g. "!dsk58bqeqm!"), and so the viewScope lives on the server for a little while after the user leaves the page, since the server doesn't know if the user is going to come back to it. If you visit another page and then go back in the browser to the previous one, it could resurrect the sleeping ID-keyed instance of the page and pick back up where it was, viewScope and all.
I suppose the same could also happen if you're in an environment where the initial page load is overly cached and it doesn't even re-fetch a new instance from the server on a new GET, but that would be a network/proxy/browser problem more than something with Domino.
Background: Xpage with multiple data sources. Each row of tabbed table contains an edit panel bound to a different data source than the main page. Each page contains a table to enter new documents. These documents are children of the main document. There is a view control that shows the user created documents immediately. The button in the table saves the document in addition to adding some control fields. It does a partial refresh of the editPanel.
Recently I added validation to the fields in the entry table. I use a function, and prevent updating from anything but the button. I am using Tommy Valand's method from this blog post: http://dontpanic82.blogspot.com/2010/03/xpages-making-validation-behave.html. If I don't use Tommy's method, then the validators fire when switching tabs, and are useless.
All of this works sort of, but I am experiencing the following issues.
1) I have to push the button twice to get the partial refresh to fire. Not only that, but the validation messages to not fire until the button is pushed twice. The first part was still an issue prior to adding the validation.
2) The table values do not clear after the refresh does happen. This used to work prior to adding the validation. The only way to get the values to clear now, is to do a full refresh (F5).
I really just need partial refresh to behave like it should. Any help is greatly appreciated.
I am answering my own question because I think that I might have found out why the partial refresh was acting so flaky. Here is what I did that solved my issues: Each tab had an editPanel. If I make the edit panel do a partial refresh to itself then the buttons on that panel seems to behave as you would expect them to.
When I create a new core control panel, the default in No submission. I do not know whether this issue manifests itself only when using multiple data sources and/or tabbed tables. Hopefully this fix will be of use to someone down the road. It is worth a try if you are having issues with partial refresh working correctly.
I hope someone can help me solve a very serious problem we face at the moment with a business critical application losing data when a user works in it.
This happens randomly - I have never reproduced this but the users are in the system a lot more than me.
A document is created with a load of fields on it, and there are 2 rich text fields. We're using Domino 8.5.3 - there are no extension lib controls in use. The document has workflow built in, and all validation is done by a SSJS function called from the data query save event. There is an insane amount of logging to the sessionscope.log and also this is (now) captured for each user in a notes document so I can review what they are doing.
Sometimes, a user gets to a workflow step where they have to fill in a Rich Text field and make a choice in a dropdown field, then they submit the document with a workflow button. When the workflow button is pressed (does a Full Update) some client side JS runs first
// Process any autogenerated submit listeners
if( XSP._processListeners ){ // Not sure if this is valid in all versions of XPages
XSP._processListeners( XSP.querySubmitListeners, document.forms[0].id );
}
(I added this to try and prevent the RTF fields losing their values after reading a blog but so far it's not working)
then the Server-side event runs and calls view.save() to trigger QS code (for validation) and PS code to run the workflow agent on the server.
95% of the time, this works fine.
5% of the time however, the page refreshes all the changes made, both to the RFT field (CKEditor) and the dropdown field are reloaded as they were previously, with no content. It's like the save hasn't happened, and the Full Update button has decided to work like a page refresh instead of a submit.
Under normal circumstances, the log shows that when a workflow button is pressed, the QuerySave code starts and returns True. Then the ID of the workflow button pressed is logged (so I can see which ones are being used when I am reviewing problems), then the PostSave code starts and finally returns true.
When there is a problem, The QuerySave event runs, returns true if the validation has passed, or false if it's failed, and then it stops. The ID of the workflow button is also logged. But the code should continue by calling the PostSave function if the QuerySave returns true - it doesn't even log that it's starting the PostSave function.
And to make matters worse, after the failure to call the PostSave code, the next thing that is logged is the beforePageLoad event running and this apparently reloads the page, which hasn't got the recent edits on it, and so the users loses all the information they have typed!
This has to be the most annoying problem I've ever encountered with XPages as I can find no reason why a successful QuerySave (or even a failure because mandatory fields weren't filled in) would cause the page to refresh like this and lose the content. Please please can someone help point me in the right direction??
It sounds as if in the 5% use cases, the document open for > 30mins and the XSP session is timing out - the submit causes the component tree to be re-created, and the now empty page returned back to the user. Try increasing the time out for the application to see if the issue goes away.
I would design the flow slightly different. In JSF/XPages validation belongs into validators, not into a QuerySave event. Also I'd rather use a submit for the buttons, so you don't need to trigger a view.save() in code. This does not interfere with JSF's sequence of things - but that's style not necessarily source of your problem.... idea about that:
As Jeremy I would as a first stop suspect a timeout, then the next stop is a fatal issue in your QuerySave event, that derails the runtime (for whatever reason). You can try something like this:
var qsResult = false;
// your code goes here, no return statements
// please and if you are happy
qsResult = true;
return qsResult;
The pessimistic approach would eventually tell you if something is wrong. Also: if there is an abort and your querySave just returns, then you might run in this trap
function noReturn() {return; } //nothing comes back!
noReturn() == true; --> false
noReturn() == false; --> false
noReturn() != false; --> true!!!!
What you need to check: what is your performance setting: serialize to disk, keep in memory or keep latest in memory? It could be you running foul of the way JavaScript libraries work.
A SSJS library is loaded whenever it is needed. Variables inside are initialized. A library is unloaded when memory conditions require it and all related variables are discarded. so if you rely on any variable in a JS Function that sits inside a SSJS library between calls you might or might not get the value back, which could describe your error condition. Stuff you want to keep should go into a scope (viewScope seems right here).
To make it a little more trickier:
When you use closures and first class functions these functions have access to the variables from the parent function, unless the library had been unloaded. Also functions (you could park them in a scope too) don't serialize (open flaw) so you need to be careful when putting them into a scope.
If your stuff is really complex you might be better off with a backing bean.
Did that help?
To create a managed bean (or more) check Per's article. Your validator would sit in a application bean:
<faces-config>
<managed-bean>
<managed-bean-name>workflowvalidator</managed-bean-name>
<managed-bean-class>com.company.WfValidator</managed-bean-class>
<managed-bean-scope>application</managed-bean-scope>
</managed-bean>
</faces-config>
Inside you would use a map for the error messages
public Map<String,String> getErrorMessages() {
if (this.errorStrings == null) { // errorStrings implements the MAP interface
this.loadErrorDefinitions(); //Private method, loads from Domino
}
return this.errorStrings;
}
then you can use EL in the Error message string of your validators:
workflowvalidator.errorMessage("some-id");
this allows XPages to pick the right one directly in EL, which is faster than SSJS. You could then go and implement your own custom Java validator that talks to that bean (this would allow you bypass SSJS here). Other than the example I wouldn't put the notes code in it, but talk to your WfValidator class. To do that you need to get a handle to it in Java:
private WfValidator getValidatorBean() {
FacesContext fc = FacesContext.getCurrentInstance();
return (WfValidator) fc.getApplication()
.getVariableResolver()
.resolveVariable(fc, "workflowvalidator");
}
Using the resolver you get access to the loaded bean. Hope that helps!
My experience is that this problem is due to keeping page in memory. Sometimes for some reason the page gets wiped out of memory. I'm seeing this when there is a lot of partial refreshes with rather complex backend Java processing. This processing somehow seems to take the space from memory that is used by the XPage.
The problem might have been fixed in later releases but I'm seeing it at least in 8.5.2.
In your case I would figure out some other workaround for the CKEditor bug and use "Keep pages on disk" option. Or if you can upgrade to 9.0.1 it might fix both problems.