SPR

Technote

Problem:
This issue was reported to Quality Engineering and has been fixed in Domino
6.5.5 Fix Pack 1 (FP1), 6.5.6 and 7.0.2.
Excerpt from the Domino Release 6.5.5 Fix Pack 1 fix list (available at
http://www.ibm.com/developerworks/lotus):

Design
SPR# THTO6BTQPE - Provides a performance fix for Abstract, which can improve
rules performance when searching the body of a message in the Router for
certain types of messages.

Refer to the Upgrade Central site for details on upgrading Notes/Domino.



The situation can occur when there is just one mail rule in the recipient's
mail database. The type of rule does not matter.

The delay factor will be greater depending on the following factors relating to
a particular MIME message:

- The amount of text and/or line feeds present in the Body field.
- The number of rules in the recipient's mail file.

Troubleshooting:

Identifying particular user mail file databases which are contributing to the
issue.
The specific user mailfile databases which are contributing to the problem can
be identified by enabling semaphore debugging, but in some cases getting
consecutive NSDs may be necessary.

If the semaphore debug contains more than 5-10 entries for the same STREADER
thread ID, when the message finally routes for that thread ID, then you would
note to whom the message was delivered.

For example:
In the example below, let's say the Overall Control semaphore repeated numerous
times for the STREADER entry for ID 164408:01029. The thread ID is 01029. You
want to then locate the router message-delivered entry for the thread 01029,
and note that the message was delivered to John Doe/Widgets.

[197968:00011-06954] 06/27/2005 14:06:44 SMTP Server: ABCDEFG.COM
disconnected. 1 message[s] received
ti="006E7AD0-8725702D" sq="003E7992" THREAD [284314:00171-14393] WAITING FOR
FRWSEM 0x03CE Monitor manager: Overall control semaphore (@50DEC42C)
(R=1,W=0,WRITER=00000:00000,1STREADER=164408:01029) FOR 30000 ms
<<above entry repeats numerous times>>
...
[164408:00007-01029] 06/27/2005 14:06:45 Router: Message 006DFBAA delivered
to John Doe/Widgets.

In cases where the "Overall control" semaphore does not repeat as numerously,
it may be harder to identify the messages that are contributing to the problem.
In these cases, you would run consecutive NSDs to observe entries for the
AbstractInternal function.

The function entires will be proceeded by a thread ID (pthr-id value) which can
then be compared to the thread ID in the semaphore debug output entries for the
router message-delivered entries with the same thread ID. This will identify
the user's mail file.

For example:
The NSD output below contains the AbstractInternal function entry and is
relative to thread ID 1029. The thread ID is then located in the semaphore
debug output (refer to the example above) for the router message-delivered
entry. This reveals the owner of the mail file as John Doe/Widgets.

NSD output:

5866: ## thread 5/45 :: router pid=164408 k-id= 152141 pthr-id=1029

LNL_advance_to_nullterm
NLS_advance_to_nullterm
Cstrchr
LookingAtHeader
FindEndOfTextChunk
FindChunksInText
DoChunks
AbstractInternal
Execute__10AtAbstractFv
ComputeVariants__14AtFunctionNodeFv
ComputeVariants__14AtFunctionNodeFv
ComputeVariants__14AtFunctionNodeFv
ComputeVariants__4AtIfFv
ComputeVariants__18MainExpressionNodeFv
ComputeVariants__8RootNodeFv
Eval__7ComputeFv
NSFComputeMainFormula2
...

Supporting information for the zSeries:
Gather the following information and contact Notes Product Support:

-- NSD
-- Notes.log
-- Operator-initiated SVC dump

Supporting information for AIX:
Gather the following information and contact Notes Product Support:

-- NSD
-- Console Log
-- Semdebug.txt (semaphore timeout debug file)

For assistance, refer to Document #1090415, "How to Gather Information for a
Domino Hang on the S/390." More >