hub subscriber limits

Document ID : KB000033649
Last Modified Date : 14/02/2018
Show Technical Document Details

Subscriber Limits

Windows OS

The hub can only handle a maximum of 64 subscribers in a Windows environment due to Windows OS (winsock) limitations on the number of open sockets. So, if a hub has more than 64 subscribers (i.e. more than 64 queues, (which includes temp queues) then the hub will start to service the queues in a "round robin" fashion. This means one queue will get temporarily dropped while another one is picked up, then that one gets dropped and another one is picked up, etc. This results in two undesirable effects. One effect is that the hub?s overall performance will be seriously degraded. Another effect is that if the queue from a probe gets dropped and the probe notices this, it would cause the probe to restart itself in an attempt to re-establish its queue.
Windows only allows you to WaitForMultipleObjects on 64 sockets, after which you have to split this information in two or more lists and WaitForMultipleIObjects on each of them. This causes an unacceptable delay in the message flow of messages on sockets not in the first list. Unix select() does not have this limitation, and so the limit is not relevant in Linux/UNIX.


The number of subscribers for Linux/Unix hubs is only limited by available resources. Note that in Linux/UNIX, once again, temp queues count as subscribers. Note that subscriber_max_threshold doesn't really matter for UNIX/Linux OS?s as it does not suffer from the Windows limitation of WaitForMultipleObjects on 64 sockets. Though, on Linux it's been seen before that if it runs out of sockets and or open files, open files must be increased to mitigate.

You can increase the open file limit on the server. Normally open files limit is set to 1024. On Linux open files configuration can be checked with 'ulimit -a'

# ulimit -a // to check the system limits especially on open files. default is 1024 which hub could be exceeding

# lsof // get total number of open files while issue is occurring to make sure it's not the open file limit issue

Consult with a Linux admin if you need to increase the number of open files.

Checking the number of subscribers
Select the hub probe and hit Ctrl-p to open the hub probe utility and press the green arrow button to execute the callback list_subscribers to see the current total subscribers number at the bottom of the subscribers section of the resultant output - Note you MUST add 1 more subscriber since the list starts at 0.

For example:
Probe? : /NMS/NMS-Server/NMS-Robot/hub
Command: list_subscribers

subscribers???? <TABLE START>???????????????????????? ?
?? 0??????????? -???????????????????????????????????? ?
????? name????? ?
????? subject?? _$HUBALL,alarm_stats????????????????? ?
????? count???? 1???????????????????????????????????? ?
????? inq?????? 0???????????????????????????????????? ?
????? establishe1395840520??????????????????????????? ?
????? postroute t_41????????????????????????????????? ?
?? 1??????????? -???????????????????????????????????? ?
????? name????? ?
????? subject?? alarm_new,alarm_update,alarm_assign,ala
????? count???? 1???????????????????????????????????? ?
????? inq?????? 0???????????????????????????????????? ?
????? establishe1395840519??????????????????????????? ?
????? postroute t_40????????????????????????????????? ?
?? 2??????????? -???????????????????????????????????? ?
??? etc
??? etc...

Note that the list of subscribers ends right before the section:

postroute?????? <TABLE START>

Alarming on the number of subscribers
Using the hub Raw Configure you can add a new key and value to set the configuration parameter in the hub section to alarm when the number of subscribers reaches a specific value (see below).


Specify the number of subscribers that must be reached to generate an alarm, e.g., 54.
Specify the severity of the max subscriber alarm above. This value is numeric.
Alarm severity values:
5 is Critical
4 is Major
3 is Minor
2 is Warning
1 is Informational