Richard Pajerski  Software development and consulting

[February 2023 update: DOTS follow-up, SPR for applet bug]

I recently took advantage of DOTS being back in the Domino 12 server, to replace a Java agent with a scheduled DOTS tasklet and have been pleased with the results.  Using tasklets is generally going to be far more efficient than using Java agents in Domino since a JVM is loaded once with the DOTS server task and remains resident in memory until the DOTS task is stopped whereas with each agent invocation a new instance of the JVM is started.  There are other benefits to using tasklets over Java agents which I may take up in a future post but for the moment, I've run across an issue on a Windows 2019 server installation.

Although the deployment above uses a scheduled tasklet, I was originally hoping to use the triggered NSFDBHOOK events in order to capture some document saves in (more/less) real time.  But while testing on Windows 2019, I noticed that the HOOK_EVENT_NOTE_UPDATE and HOOK_EVENT_NOTE_OPEN events were not being emitted at all or only very infrequently.  I had earlier tested the same tasklet on a Domino installation on a Windows 8.1 client and the events fired more/less as expected.  Aside from the OS difference, everything about the Domino installations was identical -- with one exception: the Domino program installation directory on the Windows client had no spaces but the Windows server was installed in the default C:\Program<space>Files\HCL directory.  Sure enough, after reinstalling Domino on the Windows 2019 server without the space (specifically in C:\Domino), events began firing again.  HCL has also reproduced this and may open an SPR.

In the meantime, after working a bit more with those NSF hook events, my impression is that they are not altogether reliable -- or at least, there doesn't appear to be a one-to-one correlation with each document save/open and a DOTS-generated event.  Some document saves/opens never fire an event.  The source code for the older versions of DOTS is on openntf.org here: https://stash.openntf.org/projects/DOTS/repos/dots/browse/sources but I'm not sure if this is the same code being shipped with the Domino 12 server (though I assume it's pretty close).

If I'm looking in the right place, lines 79 and 80 of the postMessage method (https://stash.openntf.org/projects/DOTS/repos/dots/browse/sources/dotsNSFHook.cpp), have:

STATUS error = MQOpen(queueName, 0, &dotsmq);
 if ( error == NOERROR ){

where DOTS presumably intercepts the necessary events from an internal Domino queue.  But what if there *are* errors here?  Will our DOTS tasklets ever know about them?  Maybe errors are unlikely here but perhaps this is the source of some missed events.

[February 2023 update: DOTS follow-up, SPR for applet bug]

For the first time in the history of Notes, HCL last month released a fully supported 64-bit version of the Notes standard, Domino Designer and Domino Administrator clients with release 12.0.2.  Overall I've found it to be more stable and certainly faster than its 32-bit counterpart and so I now use it regularly.  However, it's not without its issues with reports popping up here and here.  And I have another to add: Java applets won't load in the 12.0.2 64-bit client.  I submitted a ticket to HCL and they could reproduce this so they're preparing an SPR.

A notable aspect of this bug is that there are no error logs (that I could find) to indicate something's wrong.  Nothing in the Java Debug console, the IBM_TECHNICAL_SUPPORT folder, log.nsf, etc.  You will see the Java coffee cup but I think most end users will not immediately interpret it as a problem:

This issue is probably not an inconvenience for most deployments since Java applets were never widely implemented in Notes (in my experience).  But where applets are used, they can bring quite a bit of power (e.g. custom interfaces for any third-party system with a Java API -- databases, message queues and so on).  The good news is that applets do still work in 32-bit Notes 12.0.2 and will likely be supported in Notes as long as Java 8 remains the default runtime.

It looks like the expiration date for APNS p12 certificates that shipped with Traveler 12.0.1 was on or about December 19, 2022.  If you have a Traveler 12.0.1 (November 2021) installation and started seeing Domino console messages similar to:

[1034:0002-1038] 12/21/2022 01:38:08 PM  Traveler: SEVERE <User> Unable to get the PushNotificationResponse for apnsId null Exception Thrown...

on or after that date, the resolution is to apply Traveler 12.0.1 Fix Pack 2 which includes new APNS p12 certificates that expire in September 2023.  Until that fixpack gets applied (or you upgrade to Traveler 12.0.2 which also contains updated certificates), iOS users will no longer receive notifications of new email on their devices.

More here:  What's new in Traveler 12.0.1 Fix Pack 2?