Notes 9 and SmartCloud Activities – Heuston we have a…

Bit of a moan here.

I just upgraded from Notes R8.5.3 to R9.0.1 FP1. There are a lot a features that I really like in R9.x but something is REALLY bugging me.

In R8.5.3 I was an avid user of SmartCloud Activities in the sidebar – it worked really well.

In R9.0.1 “Social Edition”, you would have expected it to be truly social. But no. SmartCloud Activities just will not work. I understand that Connections Activities do but why the regression of functionality? Why Connections but no SmartCloud – it’s bizarre.

I’ve searched technotes and nearly every page on the whole Internet to look for a solution to this without luck.

If anyone can tell me how to get this working, my gratitude will be eternal as it’s like an old friend has left me….



Workaround for unread marks problem.

Scenario:  You’ve more than one Domino server, with more than one replica of a database (that’s everyone with Notes I think!) .  You’ve set unread marks to be maintained in Database properties BUT you notice at some stage (usually when a server crashes) that a replica that normally isn’t used has a completely different number of unread marks.  (it’s happened to us all!)

The usual lazy helpdesk solution to this is to select all, mark all as read and tell the end user “it shouldn’t happen again”.

However have you tried going to the workspace,  Click “View”, and then untick “Stack Replica Icons”.  (don’t panic it upsets your workspace layout, you can get it back!)

Then click on the two (or more) replica icons while holding ctrl and shift, and click “Edit”, “Unread marks”, and you’ll see another option “Exchange unread marks”.

It’s quite often overlooked but it usually fixes the problem!

Let us know if you found this useful!

Cormac McCarthy – Domino People Ltd




Lotus Domino R8.5.3 Interim Fix for Traveler (Win 64bit)

If you are running Lotus Traveler on Domino 8.5.3 FP1 (Windows 64 bit), there’s a new interim fix available that may avoid serious issues (such as server crashes).

Details are available at this IBM tech note –

(please note to download the fix requires an IBM log in)

The BES for Domino Extended Threading Model

Did you know that there is a default number of threads (40) on a Domino BES server that allow for connections to remote target mail servers which are used to read/write to users mail files?

Performance problems can occur if you have multiple target mail servers with a good number of target users. The Domino BES server by default will automatically allocate threads by target mail server numbers. A simple explanation is as follows:

Server A – 5 Users – 5 Threads Allocated out of 40 available – Ratio 1 Thread per user

Server B – 10 Users – 10 Threads Allocated out of 40 available – Ratio 1 Thread per user

Server C – 15 Users – 15 Threads Allocated out of 40 available – Ratio 1 Thread per user

Server D – 50 Users – 15 Threads Allocated out of 40 available – Ratio 0.3 Threads per user

From the example above, clearly Server D with 50 users will have potential performance issues with the BES server unable to allocate enough threads to facilitate the high user number which means there may be delays in delivering messages to handheld devices. The basic way of putting this is each BES will assign a number threads to mail servers(assuming they’ve at least one BlackBerry user) within your environment.

Now here’s a simple explanation of the difference between the two threading models:

The default threading model assigns the default pool of 40 threads purely by the number of mail servers.

The extended threading model assigns threads dynamically by the number of users on each mail server. (You can also increase the number of total threads in your pool for your BES beyond the default 40).

I use the following rule of thumb for when the default threading model will work efficiently for you if you’ve a BES server connecting to:-

-Only one mail server/cluster with a user base 100 or less


– Multiple mail servers /clusters with a similar number of BlackBerry users per server/cluster. (again with a total user base no greater than 100).

So the the conclusion from that is that it won’t work efficiently for you if  you’ve:

-More than one mail server/clusters with  differences in BlackBerry users per server/cluster


-A mail server with greater than 100 users (ie beyond that point 40 threads become insufficient).

If you’ve more than 100 users and you want your BES to be efficient, you need to start thinking about increasing your thread pool. One caveat is to be very careful increasing the number of total threads in your thread pool.  Do so incrementally and make sure the resources on your BES can handle an increase.

What does this mean for my end user?

The threads are used for every interaction with BlackBerry handhelds.  So if a mail server is “under served” by threads it will mean delays the delivery of mail to handhelds.

You also need to take into account, that not all threads assigned to a mail server will be effectively usable for most of the users on that mail server. There are no real hard and fast numbers with this, a number of factors (how big your mailfiles are, whether they’re on a custom design, the network connectivity to your BES) contribute to how quickly a mailfile is “read” by BES.   But usually, from experience most mail servers will have at least a small number of mailfiles who hold onto BES threads for significantly longer than others, so effectively several threads are “locked” from the majority of your users.  If your mail server isn’t adequately served by the remaining threads this will lead to mail delivery delays to your other users.

RIM’s explanation of the threading models and extending threads is here.

Let us know if you’ve found this useful.  There is much more detail I can go into on how to know if your users are “locking” threads consistently, how to measure if changes you’ve made to the threading model are effective and  and how to handle completely hung threads better than the built in alerts RIM provide.

If you’d like us to look at your environment for you and recommend improvements that could be made to make your BES threading model more efficient then please do contact us

Cormac McCarthy – Domino People Ltd