If you did read my post yesterday about how to break long running requests on the Domino server if not you can find it here The wait is over part 1
Sven Hasselbach commented that this didn’t work for him and yes he is probably right because I suspect that Sven was trying a long running XPage and yes you can’t break them using Restart Task Http but I have a solution/workaround but that requires you to implement a failsafe into your long running code.
If you add this inside your long running loop
And create an Admin Failsafe XPage with a “Break it All” button with the code
And a second button called “Reset” with the code
To bring back the application to a normal state.
If you then open up the “Failsafe” XPage if your code has gone wild and click the button you can quit the code that has gone wild.
If you add some code behind a button, and a user clicks that button. This code will run until it’s finished no matter what you do.
var LoopBreak=0;var x=0
If you place the code above behind a button on an XPage.
(Of couse at your own risk, and not on a production server)
Open the XPage in a webbrowser, also open up so you can watch the server console in realtime.
Click on the button and close the browser window directly afterwards, and watch the server console.
The code will continue to run until it’s done, imagine what will happen if you remove the line LoopBreak++ you will get a infinite loop.
And the CPU of your server will boost up to 100% and you will not be able to stop your Domino server with out killing it.
So my tip to you is to always have a fail safe, a loop breaker for your loops.
I have added my first XSnippet today and it’s the Standby custom control.
If you add the code to a custom control and drag in into an XPage all events done in this XPage will be intercepted and if the event taks more than 200 milli seconds the dojo standby widget will show up and prevent the user from clicking.
Some of the code were originally created by two great XPage guys
Tommy Valand and Serdar Başeğmez
Sven HasselBach blogged (Link) about that you could change the datasource of any XPage using a url parameter called databaseName. Doesn’t ACL apply you might ask. Yes it does so that isn’t a problem.
OK, isn’t there a setting to ignore url parameters, yes there are but If you use this you will get problems with the built in controls. They use url parameters.
Is this a problem then ACL apply shouldn’t that be enought?
No because there might be some databases where the user should be able to create documents in.
and this could create documents of a certain type in a database were they shouldn’t be.
To prevent the use of the databaseName parameter I have created this code that you can place in the onClientLoad event in a customcontrol or directly in an XPage
Where does SSJS Print() in the client end up I answered a question in the XPage forum yesterday but I thought that this might be something worth writing
a line about because this is one of the things that I was wondering about when starting with XPages. To view the print statement you should look in the menu
Help -> Support -> view trace
Or you could create a new icon and in the property box for target
add the following -RPARAMS – console
The last param is also great when debugging Notes clients that doesn’t startup. But beware if you close the console window the client crashes!!
Your XPage app may run out of memory if you put js functions/classes or domino objects in scoped variables because these objects is not Serializable. So because you can it is not always ok to do that 😉