Last month we had a big customer with some Lotus Notes issue. The client has some help desk forms to restore passwords using the complicated lotus notes procedure with just a few clicks of the mouse and reset the password not only in lotus notes, but also in AD, fully automated. Also they can create a user on Notes and AD in a few clicks, or disable them etc.
We use the lotus notes c++ and C api to communicate with Lotus Notes. However, this API has a lot of problems and "undocumented features" aka bugs. Well of course any product has, but those are still annoying. Especially when they cause crashes of the whole lotus notes client and any programs running the notes api. So this client came to us with an unexpected UMRA service shutdown. This kind of support request always get big attention immediately, because unexpected shutdowns (crashes) are well not tolerated. The program should always close nicely, so if it doesn't we fix it. Happily for us it does not happen a lot. Unfortunately it happens at a large international client, using lotus notes. Because of the extensive logging we soon found out it was caused by the lotus notes api and investigating a little further brought us to the underlying problem. When Lotus Notes items are going to be big (32KB for items with the summary flag and 64KB for items without this flag) the lotus notes api should return an error code. It doesn't it throws an exception in an other thread, not handled by UMRA causing a crash and some kind of shutdown of all lotus applications running at that moment. After confirming this was the problem (the clients notes item where 31KB+ while we added some bytes...) we installed a beta release at the customers site today. Not only preventing the crash, but also anticipating on items getting to big, by creating a new document and redirect the output to the new document.