Skip to main content

XPagesPreloadDB more evil than good

While doing optimization of application load time I found that XPagesPreloadDB notes.ini parameter didn't work in way I expected. With quick google search I realized that I'm not the first one to hit this problem as John Dalgaard wrote about the issue few years ago https://www.dalsgaard-data.eu/blog/caching-in-xpages-not-as-straightforward-as-you-would-believe/. My goal was similar. Just preload configuration as it's loaded from several places and even worse it's loaded using SessionAsSigner.

First of my issues was caused by my stupid mistake. I copied parameter in syntax for Notes client, so it contained server name. It worked, kind of. So if you want to try it, just check the URL from request that's processed by XPages and you get:

With Notes.ini setting:
XPagesPreloadDB=dev/pradny!!test/appload.nsf/entry.xsp
result was:
http://localhost:80/dev/pradny!!test/appload.nsf/entry.xsp

Which is different context than you'd normally use, so it's actually completely different instance of your application.

So next step was to test correct path to application:
XPagesPreloadDB=test/appload.nsf/entry.xsp
result was OK:
http://localhost:80/test/appload.nsf/entry.xsp

Application scope was correctly initialized during preload and stayed for first access. This was what I needed.

I was happy for few minutes, until I started to see strange things happening. It looked like that the app sometimes stopped working. After few tests I added ApplicationListener to the nsf and found the reason. No matter what I did, the application was killed after 30 seconds, so new request after this time hit clean application, which resulted in strange behavior I observed.

I tried to change xsp.application.timeout parameter, but with no luck. It was correctly obeyed when I started the app using normal HTTP request, but the pre-loaded instance was always killed even when requests were hitting the app.

Conclusion is simple. Don't use XPagesPreloadDB as it can cause you troubles. It didn't matter if I loaded just the nsf or an XPage. Application was killed in both cases.

[26853:00002-1723520800] 08/02/2016 04:05:07 PM  HTTP Server: Started
[26853:00013-402384640] 08/02/2016 04:05:17 PM  HTTP JVM: applicationCreated()
[26853:00013-402384640] 08/02/2016 04:05:17 PM  HTTP JVM: ID: 1
[26853:00002-1723520800] 08/02/2016 04:05:37 PM  HTTP JVM: applicationDestroyed()
[26853:00002-1723520800] 08/02/2016 04:05:37 PM  HTTP JVM: ID: 1

Problem probably won't have much impact on production environment as users probably won't be using the app 30 seconds after restart, but it makes this feature useless.

Also note that when XPages are processed during preload, session user name is anonymous with lowercase a, instead of normal Anonymous. So if you have some conditions in your code, make sure you use equalsIgnoreCase.

(problem was tested on 9.0.1FP4 on Windows and 9.0.1 without FP/FP6 on Linux)

Comments

Popular posts from this blog

XPages Date Field Issue: Solving the One-Day Jump on Every Save

 A user reported a very strange issue - when a document with a date field is saved, it changes the value one day to the past. With every save. But only for some dates, not all. It turned out to be a mystery that goes deep into XPages and Notes/Java APIs. I've posted a sample on OpenNTF Discord and Serdar tried it on his server - no issue. But he uses the GMT zone and I have CET (Windows set to UTC+1 - Amsterdam, Berlin... to be precise). To cut it short, the issue is caused by daylight saving interpretation between Notes and Java. The date fields (because XPages have no notion of real date-only fields) are stored with 00:00 time component and for some dates the conversion back to Java Date resulted in 23:00 on the previous day. XPages that get the date component as String for the input field, which is then saved back as a previous day during document save. The app is full of date fields and I couldn't add custom logic to every save operation, so I tried to fix it at XPages conv...

HCL Domino 12.0.2, Engage 2022 and HCL Factory tour Milan

 I haven't published my recap after Engage this year and the recent HCL Factory tour in Milan is a great opportunity to write a summary about what's happening in HCL (mostly Domino) space. It's a mix of news about 12.0.2, future directions, and my impressions, so it can be a bit chaotic, but I got the impression that many people see it similarly.  Engage 2022 Engage 2022 was great (as always). I love the atmosphere in Brudges. I visited it once after Engage a few years ago and I was happy to come back. This was also the first time I had the opportunity to speak at Engage, which obviously made it a bit more stressful, but also more fun. Together with Domino Jams, HCL continued conversations with customers and partners about the future of their products at Engage. Many of these ideas were now discussed in greater detail in Milan, some of them were even demoed.  My main takeaways from Engage were: Nomad (web and mobile) are a great addition to Notes family Restyle is a great...

XPages EL/class-loader memory leak (now with solution)

 We have recently experienced OutOfMemory crashes of XPages app server. The server was recently upgraded to 12.0.1FP1, but we were getting some panic crashes in HTTP even before the upgrade (it was 9.0.1FP10). Our hopes were that the upgrade would stabilize the server, but it's not the case. At least now I start to see what's the problem.  update 8.12.2022 There were actually 3 different leaks. I have rewritten the article to be a bit more clear. I also re-run some of the tests on 9.0.1FP10, so I assume the problems are also in earlier versions. Problem 1 The server is hosting over 1000 NSF sharing the same design + some other custom apps. Not all NSFs are used via web as the app still has classic Notes UI in parallel, so it's a bit tricky to estimate the load. By using tell http xsp show modules I usually see around 350 NSFs active. We kept the default application timeout that should provide reasonable application recycling if it's not used continuously.  We started to...