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)
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
Post a Comment