Clients may get error messages in the log files related to this and may want to know the impact of these error messages.
When a message is sent via SLUMP it usually contains a pointer to a function inside the sending process that is supposed to be called when the message is returned. These pointers are stored in a hash table; hence the variable name.
Hash tables are efficient and fast, but only if the approximate size of the hash space is known. A hash table distributes stored data into "buckets". If the number of buckets is too small, retrieval is slow because the system must search too many items in the bucket. If the number is too high, memory is wasted and retrieval can also be slow because pieces of the hash table will be paged out.
To understand what the above means in practical terms, consider the following message as noted in a Service Desk log which, although noted for the 'JavaClient' process but could equally be shown for any other process within Service Desk that uses SLUMP to send a message, e.g. domsrvr, web, vbop, and spelsrvr:
07/13 13:46:54.37 PC5041 JavaClient 3608 SIGNIFICANT callback.c 418 8193 objects registered; exceeds 100% of slump object hash size of 8192
The message is shown as an aid in tuning the hash table sizes, which has to be done empirically, since it is all a matter of probabilities and we cannot know how large the hashes will grow in practice.
If a message of the above sort is noted in the log, with a value greater than 500%, this would seem like a good point to say it is time to push up the hash table size for the process noted, by amending the relevant value in the @NX_SLUMP_HASH= variable.