IBM®
Skip to main content
    Country/region select      Terms of use
 
 
   
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

I've been doing some research recently into what causes email to fail to be delivered into inboxes, although it is visible in the All Documents view. I was concerned with this mainly because the recommended corrective action (copy compact) isn't an option for SmartCloud Notes users and their local admins, who don't have access to the users' mail servers to issue console commands.

Conventional wisdom, and our technotes, claim that the problem is that the "inbox index gets corrupted". But it looks like that's not what's really going on.

The mail router wants a folder to put its mail into that has a $Name item with value "($Inbox)". But it doesn't search the database for such a folder every time it wants to deliver mail. Instead, for performance, it expects the note ID of the inbox folder to be available in a field of the database header, "InboxRRV". If this value is missing (zero), the mail router decides there's not an inbox folder. If it points to the wrong folder, the mail router cheerfully delivers the mail there.

The command fixup -j, or a copy compact should reset the InboxRRV (the latter because it reassigns all the note IDs). But as I noted, in some cases this is not an option, and even if the local admin has the rights to do it, it would be better if an end user could correct the problem themselves. (Or if it didn't happen in the first place, but I'll get to that).

I've learned that there's code in the "note update" to check whether the note being updated is the inbox, and assign the InboxRRV accordingly. That means that modifying the inbox folder design note should restore its function as an inbox. Refresh/replace design often doesn't work for this because, if the inbox folder already has the correct design; it doesn't get updated (unless you replace design from a different template).

How does the value of InboxRRV get clobbered in the first place, when there is a valid inbox in the nsf? I'm not sure I know all the ways, but suppose the folder referred to by InboxRRV gets deleted, or is updated in a way that makes it no longer a valid inbox. I believe the note update and delete events will clear InputRRV in this case. But they apparently fail to search the database for other notes that meet the criteria for being an inbox. So let's say a new folder gets created that has $Name="($Inbox)" (its $TITLE might contain a different name). It gets associated as the new inbox. If it is then deleted, or if it's updated and the $Name value is changed, the InboxRRV is cleared, but the inbox folder we'd like to use instead doesn't take its place. That's what I think is going on. I have to experiment and write up a bug report, if so.

I have a tool I'm working on to fix this problem, which can be used by a Notes client user who has only editor+views access to their own mail file. In addition to the above, this tool looks for duplicate inbox folders, views named "($Inbox)", and folders with $Name="($Inbox)" but a different title. I might think of some more things to look for (or you might suggest some).

The main corrective action is to "touch" the Inbox design note (after deleting or repairing other folders that may be confusing the issue). This should force an update on the InboxRRV (and in addition, if the index really is corrupted, it would force a rebuild, so we still win). As a last resort, this tool also has another button to blow away the inbox and create a new one. I think that should never be necessary, but I have it on there, labeled "try this last."

I'm giving this tool to our own support folks to see how well it works for SmartCloud Notes customers, and whether we ever actually need the "delete and re-create" button. If it works out I'll probably make it more generally available.

Andre Guirard | 13 June 2012 07:47:19 PM ET | | Comments (7)

Search this blog 

Disclaimer 

    About IBM Privacy Contact