Spectrum OneClick disconnects from the SpectroSERVER when you have many connections modeled to devices in your network (Legacy KB ID CNC TS33227)
Article ID: 51772
Updated On:
Products
Issue/Introduction
Description:
Spectrum OneClick disconnects from the SpectroSERVER when you have many connections modeled to devices in your network.
OC gets a red box and times out.
OneClick hangs and disconnects.
(swbug021820)
Causes of this problem:
The cause of the problem was that devices with many connections are asked to recalculate their adjacency relations. Due to the very large number of connections and the fact that this task does not give up control, other functions could not run until this was finished which can take a lot of time.
Solution:
In Spectrum 8.1, you will need to install H19 or greater and add the following entry to the .vnmrc file in the SS directory before starting the SS back up:
use_adjacency_queue=true
In Spectrum 9.0, you will need to install H06 or greater and add the following entry to the .vnmrc file in the SS directory before starting the SS back up:
use_adjacency_queue=true
In 9.0 and above there are also two other .vnmrc entries that can be used. Here are the descriptions of the entries:
use_adjacency_queue
Default is 'FALSE', meaning 'maintain adjacency' requests and relation changes are processed as usual, running through the request without scheduling When set to 'TRUE', those requests are put on a work queue, to be processed on separate threads later. The queue is serialized to ensure we process adjacencies in the same order as before (so to not processes some quicker ones incorrectly while a longer update to a related model is still in progress)
Note: In 9.2 H04 and above, the default is 'TRUE'.
Note that the update is in the background then, so that the connection info might not be shown correctly right after e.g. a 'rediscover connection' action, etc. This drawback, and the fact that the adjacency calculation process will have to be completely redesigned in the very near future are the main reasons why I don't turn the queue on per default (plus I've seen very few customers actually running into problems with the current way things are handled, only seems to happen with massively connected devices. A generally poor server performance helps as well to see the issue, of course)
update_adjacency_thread_priority
Range 5-98, default is 50. Higher values mean higher priority, running preferentially then lower priority threads.
max_update_adjacencies_per_batch
Default is 5, needs to be > 0
Specifies the number of individual adjacencies calculated per batch, before the adjacency task will schedule to give other tasks a chance to perform their work.
The higher you set that value, the closer you get to the original behavior, where all adjacencies were processed before other tasks could run.
Environment
Component:
Feedback
