Solved : Before Mail Arrives Agent stops inbox refreshing

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.

2015-10-09_17-56-36

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.

Sean

@Unique(view1.getColumnValues(0)) = Repeatable XPages Server Crash

We have been chasing our tails with a server that has ruin really well for a number of years and suddenly started to crash over the last few weeks.

We scoured the logs, domlog, server stats etc.. and couldn’t find a pattern. It turns out it was a 4 year old bug that IBM choose not to fix. ( I have raised a PMR and sent an example )

Just like in classic notes a lookup can get too big – the 64k limit. Obviously it is good coding practice not to create such errors but why of why does such an error crash the server ?????

The original bug report was here => http://www-01.ibm.com/support/docview.wss?uid=swg1LO59373

There is a Stack Overflow article with some good solutions by Knut Herrmann here => http://stackoverflow.com/questions/23264890/how-to-avoid-the-64k-limit-when-retrieving-data-from-a-view-column

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.

[03093:00012-97270640] 22.06.2015 15:15:52   HTTP JVM: Java_lotus_domino_local_View_NgetColumnValues+0x205 (0x03BF8241 [liblsxbe.so+0xc7241])

 

 

 

FoCul Best Practice – Faceted Filtering in XPages Using Java Beans

Improved User Experience

We have found that one of the most difficult parts of developing modern XPage applications has been providing the faceted filtering that users expect from modern web apps.

By faceted I mean filtering that is intelligent – If I choose the Ford manufacturer I should not then be presented with choices for models from Audi. Continue reading “FoCul Best Practice – Faceted Filtering in XPages Using Java Beans”

SNTT – getting access to a Git derived nsf/ntf when you are not in the ACL

Sometimes when you pull down a git based Notes design you find that you cannot open the NSF that you have crated from the On Disk Project because you do not have access in the ACL.

Open the folder structure of the ODP at file system level and use a text editor to change the line below.

2014-08-20_16-50-03

You then need to refresh the ODP via Package Explorer.

Don’t forget to push this change back to Git or the next person will struggle too.

 

Adding Jar and zip files to SourceTree Repositories

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.

git ignore
git ignore