Unable to reliably deploy XPages using XSCD

December 20th, 2011

We’re late to the XPages game and it’s only in the last few weeks I’ve felt confident enough to push XPages into our system’s templates. I only allow new Domino tech to be deployed when I’m confident that the technology works because we run on a very constrained 32-bit Solaris Domino install. I was ready to use XPages on 8.5.2 but we ran into issues pushing out a XPage Single Copy Design to websites. I tried using standard Domino single copy design templates but whenever we updated an XPage we received various errors. So I waited until 8.5.3 as this version was meant to fix our issue with XSCD.

Although we can now push our XSCD’s through our templates, unfortunately moving to XSCD has not solved our issue. We are still unable to reliably deploy changes to XPages to all servers in our cluster without receiving the error:

 

HTTP Web Server: Command Not Handled Exception

 

In the XPages error log:

Exception Thrown
 java.lang.NullPointerException
 at com.ibm.xsp.webapp.FacesServletEx.service(FacesServletEx.java:87)
 at com.ibm.xsp.webapp.DesignerFacesServlet.service(DesignerFacesServlet.java:103)
 at com.ibm.designer.runtime.domino.adapter.ComponentModule.invokeServlet(ComponentModule.java:576)
 at com.ibm.domino.xsp.module.nsf.NSFComponentModule.invokeServlet(NSFComponentModule.java:1267)
 at com.ibm.designer.runtime.domino.adapter.ComponentModule$AdapterInvoker.invokeServlet(ComponentModule.java:847)
 at com.ibm.designer.runtime.domino.adapter.ComponentModule$ServletInvoker.doService(ComponentModule.java:796)
 at com.ibm.designer.runtime.domino.adapter.ComponentModule.doService(ComponentModule.java:565)
 at com.ibm.domino.xsp.module.nsf.NSFComponentModule.doService(NSFComponentModule.java:1251)
 at com.ibm.domino.xsp.module.nsf.NSFService.doServiceInternal(NSFService.java:598)
 at com.ibm.domino.xsp.module.nsf.NSFService.doService(NSFService.java:421)
 at com.ibm.designer.runtime.domino.adapter.LCDEnvironment.doService(LCDEnvironment.java:341)
 at com.ibm.designer.runtime.domino.adapter.LCDEnvironment.service(LCDEnvironment.java:297)
 at com.ibm.domino.xsp.bridge.http.engine.XspCmdManager.service(XspCmdManager.java:272)

 

This appears irrespective of the complexity of the XPages. It doesn’t matter if the XPages included complex code or simply says ‘Hello World’. The server the code is replicated to will 95% of the time display the error message, and the other servers in the cluster fail around 50% of the time. At the point that the new XPages fails. Every XPages in the database fails.  The odd thing is that after an hour the page starts to work. Which suggests some sort of cache is being flushed.
 

Things I’ve tried unsuccessfully:

  1. Make a minor change and re-replicate.
  2. Make a minor change to the XSCD template directly on the server.
  3. Use the ‘Build’ function to rebuild the database and replicate.
  4. Rebuild directly on the server.
  5. Re-sign the database and replicate
  6. Re-sign the database on the server.
  7. Delete page and redeployed
  8. HTTP refresh
  9. Accessing an XPages immediately after the JVM purge period has expired.
  10. Changed the page persistence from disk to ‘keep pages in memory’
  11. Changed the page persistence to ‘keep current page in memory’
  12. Changed the minimum supported release to 8.5.3
  13. Uninstalled Notes client and reinstalled, build, re-sign and re-deploy.

 

Things I’ve tried successfully:

  1. Restarting HTTP server (unacceptable with 900 active web users per server, many of whom are students assignments)

 

Because we run on Solaris and IBM refuse to move Solaris to a 64-bit platform, our JVM is set to 256mb and is set to use OS memory for the HTTP task otherwise our server collapses due to a lack of headroom. So we do not have much leverage to change this figure.

Has anyone experienced this problem?

Posted in Domino, XPages

XPages Single Copy Design

September 9th, 2011

I’m posting this on behalf of my colleague David Harding (@dharding) who’s been investigating XPages Single Copy Design. I think it’s best I leave it to Dave to explain:

We are looking to roll out XPages Single Copy Design to several thousand databases.  So far, we have not been able to find a recommended practice for rolling out the XPages Single Copy Design flag and template path to all of these databases.

Documentation on the Lotus Notes and Domino Application Development wiki (http://www-10.lotus.com/ldd/ddwiki.nsf/dx/Single_Copy_XPage_Design#Does+employing+SCXD+typically+have+a+positive+or+negative+affect+on+speed+of+performance%3F) suggests that setting the options in the template should propagate to databases that inherit from that template.

Quote from page:

“Is it true that selecting or de-selecting SCXD in a template does not propagate to applications already created with that template?

This is not the case. If a template is set to use a SCXD database and an application is created from this template then the new application will have the XPages from the SCXD database. And changing the template to say another SCXD or no SCXD database set will reflect in the database that inherits its design from the template.”

In testing, we have not found this to be the case.  Testing adding in the Xpage template path and checking the flag in the template*, combined with all combinations of HTTP Restarts and Design updates do not seem to visibly update the database.properties file in the inheriting database to include the $XPageSharedDesign and $XpageSharedDesignTemplate items.

*When I say Template here, I am referring to the ntf file that the database inherits from, not the Xpages source database that will be the path in the $XpageSharedDesignTemplate item in the database.properties file.

In an attempt to find an alternative, reliable method of deploying this setting we have looked at using a NotesNoteCollection to access the database.properties file and adding in the values.  There doesn’t seem to be an obvious way to locate this file, though tests have indicated that it is the only one in the database with a $Daos item, so we have been able to get a hold of it by filtering for that in the NotesNoteCollection.

So the questions are, is there a ‘best practice’ for rolling out the Single Copy XPage flag? Is the NotesNoteCollection method a no-go area?  Why are our experiences with the template not in line with the claims in the aforementioned quote?

Posted in Domino, XPages

Screen reader survey

February 21st, 2009

A survey by WebAIM on how users of screen readers interact with web pages is worth a read. It gives a small insight into how screen reader users navigate around pages and some of the problems they face. The survey failed to clarify the term Web 2.0 so the survey hasn’t helped to understand if AJAX based sites disenfranchise partially sighted users but it does confirm some of the advice accessibility experts make. It also reinforces some of the point I tried to make to the Domino developers at Lotusphere about where the new XPage technology fails to meet basic accessibility criteria, namely that screen reader users use the page’s semantics to navigate around the page. A good practice that XPage authoring using the visual interface fails to support.

When html was originally specified it was intended to be a docuument markup language and the tags selected define the page’s content – headings, paragraphs, lists, etc. As web developers we all know this, it’s really basic stuff.

Since headings are more important than paragraphs, a significant percentage of screen reader users use headings to quickly navigate around sections of the page and this confirms the advice accessibility experts have been giving for years. Define a readable document and then style it to look like an application. XPages gets this fundamentally wrong and provides no visual tools to generate standard page markup, a glaring omission that no other editor that I’m aware off fails to include.

All’s not lost. If you want to develop a semantic page it’s just a case of switching to code view and you can add normal markup and it wouldn’t take much for Lotus to add some simple page editing tools.

Hopefully surveys like this help developers see how some simple changes to their pages can make page browsing easier for a small forgotten number of web users

Posted in Accessibility, Domino, Web Design, XPages