- Having some trouble with my API calls timing out. Using the Get Devices API and trying to get 1000 devices at a time with a URL like this: /webacs/api/v2/data/Devices.json?.full=true&.firstResult=0&.maxResults=1000 . Got ~5600 devices in Prime and have set the timeout on HTTP object to 900 seconds.
- The timeout does not happen 100% of the time, but it is often enough to be interfering with a daily process. According to the API Health, the average response time is 160304 ms (~2.5 mins). Is there some way to troubleshoot why it is taking over 900s for this call to come back at times. Running 3.1.4 Update 1 with Device Pack 6.
We noticed that, especially on instances running over a long period of time or on instances with low alarm thresholds (or a lot rules that create alarms), that the performance of the Devices resource pretty quickly degraded. We've addressed this in API v3 (which will be released with PI 3.2) by removing alarm counts from the Devices API. It could be something else causing the issue on your appliance, but if it's specific to that API resource, it's very likely the alarm counts that's causing the problem.
For an immediate workaround, try adding the ".nocount=true" parameter to your query string. This will instruct the API to bypass the query that it does to get you the count, first, and last attributes; but we generally see API response times cut in half with the use of this parameter.
- As per the documentation, adding the .nocount parameter will remove the first, last, and count attributes which you need to page through all the devices. How to return all of the devices when the URL contains the .nocount parameter.
You're right in that those attributes will be removed from the response. However, you'll still be able to request pages via the .firstResult and .maxResults query parameters in your request. So you'd still send .firstResult=0&.maxResults=1000 in the first request, .firstResult=1000&.maxResults=1000 in the second request, and so on. To figure out if you've reached the end of the data set, you can count the number of entities in the response and if it equals .maxResults, you keep going, if it's less, then you've reached the last page.
This is not a perfect solution, but hopefully the response times will get back within acceptable ranges. Would also suggest you talk to your Cisco account team and ask them to get you in the PI 3.2 beta; that way you can check if the v3/Devices response times are indeed better for you.
- Unable to maintain my inventory which is over 5,600 devices.
- getting this exception with the 500 error:
- exception": "org.springframework.orm.hibernate3.HibernateJdbcException: JDBC exception on Hibernate data access: SQLException for SQL [select this_.ID as ID2183_0_, this_.DeviceId as DeviceId2183_0_, this_.Reachability as Reachabi3_2183_0_, this_.ManagementStatus as Manageme4_2183_0_, this_.DeviceName as DeviceName2183_0_, this_.IpAddress as IpAddress2183_0_, this_.DeviceType as DeviceType2183_0_, this_.CollectionDetail as Collecti8_2183_0_, this_.CollectionTime as Collecti9_2183_0_, this_.SoftwareType as Softwar10_2183_0_, this_.SoftwareVersion as Softwar11_2183_0_, this_.CreationTime as Creatio12_2183_0_, this_.Location as Location2183_0_, this_.productFamily as product14_2183_0_, this_.criticalAlarms as critica15_2183_0_, this_.majorAlarms as majorAl16_2183_0_, this_.minorAlarms as minorAl17_2183_0_, this_.warningAlarms as warning18_2183_0_, this_.clearedAlarms as cleared19_2183_0_, this_.informationAlarms as informa20_2183_0_, this_.AuthEntityId as AuthEnt21_2183_0_, this_.AuthEntityClass as AuthEnt22_2183_0_ from Devices this_ order by this_.ID asc]; SQL state ; error code ; could not execute query; nested exception is org.hibernate.QueryTimeoutException: could not execute query",
- also found the full stack trace in the xmpNbiFw.log file.
Have you tried using the InventoryDetails resource as an alternative.
- constructed a request with Postman and it appears the data structure has the fields needed. It will take a decent bit of code changes though.
- The /webacs/api/v2/data/InventoryDetails.json?.full=true&.nocount=true Postman call returned in 527114ms, or close to 9 minutes. Does that seem normal for ~5600 devices.
No, that's high as well. It could be that there is something in particular wrong with your appliance. Have you noticed any performance problems or slowness elsewhere. Are any jobs in the system running for long periods of time (>15 minutes).