We have Cisco Prime 3.0. When my Java client code is making the following REST API calls it sometimes returns 401 from the http request.
Requesting Device data:
Requesting the unsanitized device config:
I have added the "Connection:close" to the http request header as mentioned in the FAQ, but still getting the 401 error code.
Is there another setting I can change? I also have the following in my nbi.properties file on the Cisco Prime server:
So, there are three general reasons for 401 errors.
Regarding concurrent session limit reach. Is it possible to increase from the 5 active session limit at once for a given user in Cisco 3.0 and 3.1?
I am doing a netstat -an | grep <java client ip address> on the Cisco Prime server to see all the TCP connections states for my Java client making HTTP REST API calls to the Cisco Prime server. Is this a good way to determine how many concurrent sessions for a user are being used between my Java Client and Cisco Prime? In my tests with my Java client I am using the same user.
When making a HTTP REST API call in my Java client, is a new session created each time since I have to pass the username and password in the header of the HTTP GET request each time? Or is the new session only created when adding the connection:close to the HTTP header? If the connection:close is not issued then I would have to wait for the server to time out the connection which could result in a large number of sessions opened? I am also using the HttpClient class to make my HTTP GET requests in my Java client. Is my understanding correct?
I am not clear of the definition of a session. Are sessions and the TCP connection viewed in the netstat -an command considered the same?
Thanks for all your help!!
Starting in 3.2, we added support to configure the concurrent session limit via the UI. Before that point, it was fixed at five. To configure, go to Administration > Settings > System Settings, then General > Server. You'll need to restart Prime Infrastructure for the change to take effect.
Yes, using netstat is generally a good approach. But there are some caveats:
Yes, a new session is created upon the receipt of each HTTP request, and (in 3.1+) torn down after the request has been handled. The TCP connection is not really the same as a Prime Infrastructure session, but because the API uses basic authentication, if you send "Connection: close" or just ensure that you gracefully close the TCP connection after every request, then they will be close to the same.
I hope that clarifies things
Regarding reason 2 for the 401 error:
The concurrent session limit is reached. If you make five requests with persistent connections in a short period of time, the sixth and subsequent requests will yield 401 errors. In Prime Infrastructure 3.1 and 3.2, we changed the way the session manager handles persistent connections for API requests, however, this limit can still be hit when more than five sessions are active at once for a given user.
When you mention five requests with persistent connections in a short period of time:
What was the change made to the session manager in handling persistent connections for API requests in Cisco Prime 3.1 and 3.2?
When you mentioned more than fire sessions are active at once for a given user, does that mean when I run a netstat -an | grep <java client ip address> on the Cisco Prime server, the ESTABLISHED state is counted against the active count and the CLOSE_WAIT state does not count against the active session count? I am including a Connection:Close in the header with every HTTP API request I make from my Java client to Cisco Prime. Trying to understand why I am still getting the 401 error.
The period of time is the session duration (which, if I recall correctly, defaults at 60 minutes). The session duration is configurable, however lowering it too low may have a negative impact on the UI user experience.
The change in 3.1 was to kill the session after we finished preparing the response to the API query.
Regarding the relation between TCP connections and sessions, this method of estimating the sessions is most accurate when persistent connections are not in use. A connection in CLOSE_WAIT, in 3.1+, is unlikely have an active session associated with it.