You can view the simple testing page here
The page contains one textarea, a "create" button and a "remove" button.
When the "create" button is clicked, the "textarea" is used to create "wysihtml5".
When the "remove" button is clicked, the "wysihtml5" is removed with the code below:
$("iframe.wysihtml5-sandbox, input[name='_wysihtml5_mode']").remove();
$("body").removeClass("wysihtml5-supported");
(Please refer to this for reference.)
The problem I am having is that the memory of the elements(textarea, iframe, and links) created by wysihtml5 seem to be retained in the memory.
I take few heap snap shots with google chrome dev tool.
snap1 - when the page is initially loaded
snap2 - after the wysihtml5 is created
snap3 - after the wysihtml5 is removed
Are there memory leak? If there are, how do I prevent it from happening? (My backbone application can possibly create/destroy 100+ wysihtml5, so a clean removal of wysihtml5 is quite important!)
First of all it is not clear is the test works properly or not because nothing happens with the page when I click create button. It would be much more useful to have a repeatable test.
Nevertheless I did the test and found that the test page (working or not) have no leaks.
On the each click it allocates small amount of memory and releases it on the next click.
Sounds like the page creates the detached dom tree on the first creation and keeps it alive.
It makes sense to do warm-up create and delete actions before the first snapshot and filter everything except the objects that were allocated between first and second snapshot.
This technique was described here.
Related
I need to destroy a component on navigating away from it but I cannot figure out how to do it. I've tried clearHistory: true in RouterExtensions, but it doesn't work. The flow of our program is this:
Dashboard > link to Component1
Component1 > Save takes the user back to Dashboard.
If the user clicks the link to go back to Component1, I get an ExpressionChangedAfterItHasBeenCheckedError because the memory of the component is still resident.
It is bit tricky to remove a page from the navigation history in nativescrupt angular. I would suggest you to create a modal page for Component1, save it and when user close the modal, take it back to Dashboard.
or you need to handle the change detection manually, for further reading, you can refer here.
I solved my immediate problem by redesigning the page to use calculated values based on the data rather than ui state settings from the ngrx store which, as I thought about it, is a more stable solution.
I left the question up because I was curious if there was a way to remove pages from the navigation history.
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/.
I am using a tree within the left panel and a detail view (VerticalLayout with labels and buttons) within the right panel. Each node contains extensive data, that are saved by this way:
IndexedContainer nodeData;
.
.
.
tree.getContainerDataSource()
.getContainerProperty(itemId, "nodeData").setValue(nodeData)
The content for selected node is displayed in detail view. It can be modified using a modal window (clicking "Edit" button in detail view).
I am using nodeData.addValueChangeListener(detailView). The detail view implements function for updating its own content when the modal window saves nodeData. It works fine, but I have worries about memory leak. The right panel content (detailView) is destroyed when I select another node. Another view can be placed on the same place, because the nodeData of another node can have another structure. But nodeData container lives for long time and I can select it more times. My question is: Does it cause memory leak? Or the system is able to remove unaccessible object that are referenced only as a listener?
Thank you for telling me, if it can be problem. Any advices are appreciated.
I wouldn't worry about a memory leak in this case, as the listener is being injected into the component.
You can detect if there is a memory leak or not from the server, for instance, stopping Tomcat server will through some memory leak errors in the logs if there is a memory leak or any unreachable objects.
However, I would recommend overriding the detach() method on your tree to make sure you cleanup your resources once a view or a component is detached from the screen/view.
The problem is solved. It is possible to check out the component from listening changes, when it is orphaned:
if(!isAttached())
nodeData.removeValueChangeListener(this);
I am building an application that has very large documents, and many documents in the views. In my testing environment, these views take a view seconds to load, but for the customer, these views (shown in the dynamicViewPanel) are taking upwards of 12 seconds (or up to a minute the first time it is being loaded on a given day) to load. No update is made on the browser until add data becomes available. My question is not about performance however.
How can I go about immediately loading the xpage so that the user sees "something is happening and the browser did not swallow my request", yet load the view when the data eventually becomes available while using the dynamic view panel control?
Regarding partial refreshs Fredrik Norling made a neat control called "Standby Custom Control" that displays a "wait" icon when partial refreshs happen. Not sure if it will work when loading the whole page though...
http://openntf.org/XSnippets.nsf/snippet.xsp?id=standby-dialog-custom-control
If you are using Dojo modules there is a simple way to implement such a stand by for Partial Update and for opening new pages.
I found it in a blog by Vikas Tiwari
This is a two step process:
Add following Dojo modules to your XPage.
< xp:this.resources>
< xp:dojoModule name="extlib.dijit.ExtLib">< /xp:dojoModule>
< xp:dojoModule name="extlib.dijit.Loading">< /xp:dojoModule>
< /xp:this.resources>
Add following lines to the EventHandler of your button/link which is going to be used for Partial Update:
< xp:this.onStart>< /xp:this.onStart>
< xp:this.onComplete>< /xp:this.onComplete>
< xp:this.onError>< /xp:this.onError>
Not an answer to your question but you could try my ViewGrid plugin from here OpenNTF ViewGrid. If the view indexes are being build, the control 'waits' until that process is done (with a loading indicator)
In our MOSS '07 site we have a page that contains just a Page Viewer web part in it that points to a site on another server. However, I've noticed that on that page (and any others that have a Page Viewer web part on it) our drop down menus and hover effects are super slow and completely max out the CPU on the visitor's computer (process is IExplorer.)
Through testing, I was able to determine that it doesn't matter what URL the web part is pointed to...just having the Iframe on the page seems to cause it (just setting the viewer to load Google's homepage--which is probably the simplest site I know--still causes the problem). If I go and remove the web part, the menus start functioning just fine again.
I attached a debugger to the process and stepped through the Menu_HoverStatic and called functions and it seems to have a hard time when assigning panel.scrollTop to zero in the PopOut_Show function.
Has anyone else noticed this? ...perhaps found a solution to it? I can't find where to edit PopOut_Show function on our server (I think it's a resource in one of the .NET DLLs) or else I'd just comment out that line as I don't think it's really important anyway...at least on our site.
I really like the ability to have web pages from another server hosted in our SharePoint site, but the performance on the hovers is agonizing... and, honestly, unacceptable. Depending on the resources of the user's computer, the hover effects can take 15 seconds to complete at times!!!!
Any suggestions would be really appreciated!
SharePoint's built-in JavaScript is probably making the browser wait until the IFrame within the Page Viewer Web Part has completely loaded. If you can see a status bar message that says "Please wait while scripts are loaded..." when you attempt to click on the page then that's definitely the problem.
Thank you for your reply. I was actually able to discover what the problem was (my appologies for not sharing it here with everyone when I did!)
The problem wasn't so much from having the IFRAME on the page, it was because I had set the zone to be 100% width and height. Because of a but in IE, trying to calculate the location of the dropdown was erroring (I don't remember what javascript function or call was exactly to blame, but I remember stepping through it with the debugger.) I believe it had something to do with "location offset" or something like that. My take at the time was that it was trying to position the dropdown menu on the screen, and the calculation for positioning it was failing.
To get around it, I had to set a javascript routine to programmatically set the height of the zone after the page loaded. Exactly setting the height prevented the dropdown problem in the menus. Of course, it wasn't ideal because if a user resizes the window, the IFRAME (or, more precisely, the zone it's in) doesn't resize with it. But, it was a suitable band-aid for the problem.
I'm hoping that IE 8 will fix this when it's released.