Idea Details

Develop a queue for "Discover Connections"

Last activity 05-31-2019 01:51 AM
Martina Smith's profile image
01-10-2013 03:26 PM

Issue:Spectrum only allows you to run one “discover connections “ task at a time. If you are trying to start another the system displays a message that it is already running one. You will have to wait and retry to start a discovery which can be very time consuming.


Idea: It would be beneficial to have the option to place the discovery of the connections in a queue, much like a printer queue. If a job is already running and you would like to start another you can place it in the queue and the system will run it in the order they have been received. This would enable us to continue working on other tasks without having to check back continuously to see if the system has finished the previous “discover connections” task.


02-03-2016 01:18 AM

Good news!

Thank you, Kiran!

02-02-2016 10:23 AM

Good feedback - we got this from Princy as well. we will be considering this soon

Regards,Kiran Diwakar

02-01-2016 05:36 AM

Yes, without the queue there was no reason for such a wish, but now...

(...the appetite comes while eating. )

02-01-2016 05:13 AM

Good Point Frank!

That was always a pain in the ... work flow .

But of course - without a queue for discoveries it just was not possible to start more than on discovery at a time...




02-01-2016 04:54 AM

Thanks Frank_Elliger. I made a note to the request. Will keep you posted.




02-01-2016 04:30 AM

Thank you too. I've tested it and it works.


... now it would be useful if it becommes possible to select more then one device and say "Discover Connections".

Regards, Frank

01-14-2016 06:39 AM

Thank you so much.

It is always great to see that you take our ideas and implement them.


Thank you,


Martina Smith

01-14-2016 06:34 AM



The idea is delivered as part of CA Spectrum 10.1 release.




07-22-2015 10:10 AM

Hi franktonjes, MartinaE,


Thanks for your quick responses here. The feedback is really helpful.




07-22-2015 08:40 AM

I don’t think I would need any notification, just a queue for the discover connections with the ability to move items up or down in the queue or delete them from the queue all together would be a major improvement.


Thank you,


Martina Smith

07-22-2015 06:22 AM

For me it is not so much a notification system, but more a way to see what was successful and what failed. I would suggest simply populating attributes with the list of passed and failed devices (perhaps discConnPassed = '0x100223d, 0x123123, etc' and discConnFailed. You could use the attributes like the USMOtherIPAddresses where each entry is seperated by a comma.


You could also have an attribute showing the cued items. e.g.: discConnQueued.


We use the REST api to do a add a device and then issue the discover connections, but because of the limitation of 1 discover connection process per landscape have to do this in serial and have to wait for each one to finish. These attributes would allow us to 'manage' the what passes and what fails.


The only issue would be how long to keep history for. Perhaps limit the queue to 100 devices. It would be great to also be able to just change for example the discConnQueued to list the devices and then the discoverConnection would kick off when there are values in it.


These are some ideas, but you would need to gather what people want and make decisions based on that.


All I would ask is that the procedure and all information be possible via REST API. I wouldn't want to have to read a log file on the local host as this total nullifies the use of the API.

07-22-2015 05:50 AM



We get the idea for queue for "Discover Connections". But going through the comments members also requested about notification mechanism. And we have mixed views.


Can we nail down on this? What kind of notifications members are interested in? Example: Successful Notification, Failure notification, etc.


What would be the mechanism of notification? Example: Email, Alarm, Log file, Pop up message, etc. ?




06-18-2015 12:28 PM



This idea is lined up and planned for future releases of CA Spectrum.




04-20-2015 05:11 AM

If you implement a queue there could be a view to show the events with regards to the queued discoveries, so you could always find out when your request finished. In the meantime you could carry on and do other tasks.

04-20-2015 04:00 AM

Yes, that was the intention.

04-15-2015 09:06 AM

The thing I really like about Joern's idea is not getting notification that a discovery is done, but more finding out what the stuck discovery is so we can investigate the troublesome device, or being able to delay the re-discover of something that will take a long time until after the re-discover of a number of devices that wont take a long time.

04-15-2015 07:17 AM

That is exactly what I am looking for. It is very time consuming to babysit the discovery processes. I hope with all the current input that they reconsider and put that challenge out to the developers.

04-15-2015 06:09 AM

I think the problem is that you can only run one discover connections at a time per landscape. This was just a mechanism to be able to manage that single pipeline, so we could see what devices were still scheduled to have connections discovered. The example of a printer queue was used. We could place devices in a 'discover connections' queue and Spectrum would process them one at a time and possibly notify when the job is done, or let us query one or a set of attributes to see what it's progress is.


Perhaps have a special model for 'discoverConnections' like the 'onlineBackup' model - which has specific attributes for:


Current Device to have Discover Connections running

Next Device to have Discover Connections executed on it

Total devices left

List of devices in queue (model handle or name)


We should also be able to set a global timeout value as I notice some Discover connections takes eons


I guess there should also some error handling. If a device in the queue gets deleted from spectrum to just ignore it and not generate errors. I guess there would be a lot for the Developers to have too look at

03-12-2015 04:47 AM

Hello Folks,


We reviewed and felt not to queue the manual discovery actions like user triggering the discover connection.

This is because, If we queue such actions, we never know when it will be completed and will not be able to notify the user once complete or drive any actions thereof.

Is the expectation that, whenever discover connections is triggered and there is already a discovery mapping process running, it pops a dialog saying “Your request is queued”?




Kiran Diwakar

01-13-2015 10:24 AM

I agree and would like to add: just like in a printer queue - you should have te ability to view and edit the queue (in order to speed up things when necessary.

Also I would like to have more control over the discovery protocols (like in AutoDiscovery) in order to speed the tasks up.

01-09-2015 10:59 AM

I would go one further and find out if you could have multiple discover connections threads running at the same time. In our automation this is the bottle-neck as each landscape can only do one discover connections at a time. I've had to split up work for each landscape so it's done in parallel (each landscape has it's own 'dispatcher') but this still takes ages if you have a large Spectrum Domain with many devices. We do a rediscover connections for all devices once a month.


It would also be nice to be able to query the API / Spectrum to find out if any discover jobs are already running and which devices are in the queue as described by Martina.

07-22-2014 10:19 AM

We are reviewing this.


Kiran Diwakar

07-02-2014 03:07 PM

I agree would be helpful, especially if you initiate "discover connections" on a single device, then close the dialog so you can perform other tasks in OneClick. On a device with a large number of interfaces, it can take a long time to complete, and once the dialog is closed, you have no indication of the status of that discovery until you see "The action succeeded". If another user initiated a "discover connections" and you need to discover connections on other devices, you simply have to keep trying until you no longer get an error message about the discovery already in process. I would also suggest that it would be useful to be able to select multiple devices within a list, container or group and initiate a sequential "discover connections" on each, rather than having to do it on a whole LAN container. I'd love to be able to initiate "discover connections" on the members of a global collection too. I have a GC setup to list all devices with no neighbors (search contains "NeighborList Less Than "1"" AND several Model Class Equal To arguments to target routers, switches and firewalls).