This was a new one to me and IBM support did a great job of helping us to find the issue.
We modified a customers mail template to add some core business functionality that processed the inbound emails before they appeared in the in-box and provided some quick filing suggestions based on some business rules.
In order to present the options in the UI we had to add information to the new emails – this is where we go caught out.
If you use document.save as part of the “Before Mail Arrives Agent” then the inbox will not refresh automatically – or the refresh will be delayed. On our customers server the refresh failed in 100% of cases whereas on my dev server it was delayed 60% of the time and failed 40% of the time. For IBM support it was never delayed or failed.
When you look at the help document for the DocumentContext property it states
For an agent activated “Before New Mail Arrives,” the in-memory document is the email that is about to be delivered. Because the agent is activated instantly for each email as it’s about to be saved into the mail database, each time the agent runs you are working with a single unsaved document. The UnprocessedDocuments property in AgentContext will not return any documents for this agent type.
So if you modify it you do not need to save it – because it is about to get saved.
So we removed our document.saves while session.isonserver = true and the inbox refresh now works.
Many thanks to Djesus Rex C. Cada from IBM support who went though the past tickets and found the work around for us.
The bug is nasty in that the usual log entries are not written before the crash making it very difficult to track it down. The NSD logs didn’t seem to work with the Lotus LND tool, I need to check if this is still valid.
The problem does occur in 9.01 FP2 FP3 on Linux but not in XPinC 9.01
Update 2 : It appears to have been fixed in 9.01 FP3 under and I can confirm that it does not fail in 9.01 FP4
YSAI9CCBYGFixes Domino Server crash when executing notesView.getColumnValues method, if there are many documents in a database.
Update 1 : NSD logs did point to the problem
Looking at the console_acme.com_2015_06_22@15_13_49.log I can see the following line in the “Stack Backtrace” section. This gives a good hint to the problem although the individual XPage is not listed. There may be other debug parameters that would help with that.
When we use JAR files such as DocX4J for exporting from XPages we need to store these within the git repositories so that the developer can add them to their /jvm/lib folder when building the XPage application. If the correct jars are not present the build fails.
The files are stored in a /jar folder away from the /notes folder where the Noes design elements are. We also use a /documentation folder for user guides etc..
When you add these jar or zip files to the repo they do not appear in SourceTree. In my case all that appeared was the /jars/readme.txt file.
The project specific .gitignore file was blank but the default settings in git are to ignore all compiled files and all zipped files. Given that we store documentation and artwork files int eh repo the .zip would also a problem for us.
You need to modify the global .gitignore file as shown below. The project specific .gitignore file is additive tot he global settings and does not replace them.