Max # of active AXL sessions supported?

[Christopher Rossetti]

Hi All,

CUCM 10.5.2

I have been trying to research a few questions stemming from a large # active AXL sessions being observed. Even in a re-use there are large number of active sessions being seen - upwards of anywhere from 4xx to 12xx. The apps and sessions are trying to be identified but some general questions were raised in troubleshooting this.

1. What is the max # of AXL active sessions that is supported? OR best practice recommend?

Any CCO guides on this?

2. Are there any logs or commands that can be done to show the details of

the AXL sessions, who/what traffic is in the sessions, if sessions are

stale/inactive and just holding there? Basically the low-level details of

all the AXL active sessions

3. We¹re wondering if we are getting stale AXL session entries somehow

(showing active but not really active). Is there an AXL active session

timeout setting that can be tuned?

thanks!

[npetrele]

The key here is that AXL acts as a provisioning and configuration API, not as a real-time API.  When people try to build interactive user-facing applications using AXL, they often run into problems, because that's not what AXL is for.  Best practice is to use it as intended, which is for provisioning and configuration. 

AXL sessions are actually Tomcat sessions, and the timeout for these sessions is 30 minutes.  So even if you aren't performing any AXL operations, the session remains active until the 30 minute timeout expires.

You can take advantage of this by re-using the JSESSIONID that Tomcat returns in the header of the AXL response. This allows you to use a single HTTP session to Tomcat for making multiple AXL requests.

Here’s how it works. When you perform an AXL SOAP operation, it returns a JSESSIONID in the header as a cookie. For example:

Set-Cookie: JSESSIONID=3FC45B4CA24651208412AA73C162F164; Path=/axl/; Secure; HttpOnly

In order to continue to use the same HTTP connection to AXL instead of opening a new connection for each subsequent request, you should return the same JSESSIONID in a cookie header with the next request.  As you continue using the same JSESSIONID, Tomcat will continue to use the same session, thus reducing the stress on the server when compared to opening new Tomcat sessions with every request.

The JSESSIONID has a default timeout of 30 minutes in Tomcat, but the timeout clock only starts ticking when the connection is idle. You could theoretically continue to use the same JSESSIONID indefinitely, or at least until you stop performing requests with that particular JSESSIONID for 30 minutes. If your JSESSIONID-based connection is idle for more than 30 minutes, make a new request without specifying a JSESSIONID. This new request should return a new JSESSIONID.

[Christopher Rossetti]

Thank you for the clarification and overall concept information. The 30 minute timeout and re-use info is very good info - thank you!

One follow-up - I know that they are taking advantage of the re-use method you mention,  in one of their App scenarios.

Even with that, are there any limits to be concerned with in terms of re-used sessions from different APPs or perhaps AXL requests/calls to DB?

Basically, in an Enterprise setting - how should scalability be looked at in terms of too many # of sessions, max # AXL DB calls/writes, avoiding congestion/slowness/delays, etc.

Do we have some design guidelines documented anywhere on this?

thank you!

[npetrele]

Scalability is going to vary based on what kind of operations you are executing, how much data is returned, and how often you touch the database, among other things.  Check out the Data Throttling section of the documentation linked below for some tips.  We're about to publish new and updated documentation so check back now and then.  The new documentation is easier to navigate, clarifies a few things and adds the above information on JSESSIONID.

Cisco Unified Communications Manager AXL Developers Guide

[stephan.steiner]

Having just run into 503 behavior by apparently overloading the server, I see a lot of sense in the questions Christopher is asking here. Of course you can write your apps to handle the 503s with configurable retry delays and retry counters (and in my case.. the operations ran fine in the end), but it's better to avoid those issues by adding suitable request throttling rather than react to when problems arise. There should probably some middle ground between throttling on the side of the application using AXL, and the retry mechanism.