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
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:
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.
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.
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.