JSESSIONID and concurrent requests

[stephan.steiner]

Hi

I have an application that is making a lot of executeSqlQuery requests.. and these requests may be sequential, but they may also be concurrent (no way to tell beforehand.. ).

Given that the doc mentions JSESSIONID in the context of sequential execution I'm wondering if you'd still get any benefit if some request may be concurrent.. would you have to determine which requests are concurrent and which are sequential and remove JSESSIONID from the concurrent ones, or could you keep using the JSESSIONID for every request regardless (the whole thing starts with some initial data extraction that is sequential.. but what happens thereafter is very dynamic).

Thanks

[npetrele]

This is actually a Tomcat thing, and the way I understand it is that you can't do concurrent requests with the same JSESSIONID.   I suspect that even if it "works", it will simply take what you planned as a concurrent request and queue it as the next sequential request. 

I searched the Tomcat docs and couldn't find out if Tomcat will queue a duplicate JSESSIONID request while it's working on one, thread it as a concurrent request, or reject the second request or respond that it's busy.  My gut tells me the second request will get queued, but the only way to find out is to either find info in the docs that I couldn't find, or test it.

Either way, unless you can find something in the Tomcat docs I can't find, if you want to ensure that you run two requests concurrently, you'd have to start a new session and get a new JSESSIONID.

[stephan.steiner]

Okay, I just give it a shot and see where it gets me

[dstaudt]

Request authentication is apparently a quite heavyweight and latency-causing process for AXL, and re-using the session cookie apparently reduces the overhead by a couple of orders of magnitude.  Not aware of any impact on processing order, so best practice is to re-use it whenever feasible.

[stephan.steiner]

Alright.. I've just added support for the cookie into my AXL lib.. first program to use it will go productive tonight in a large installation.

[stephan.steiner]

So far no problems (except maybe the 503 behavior I mentioned yesterday, but that may be unrelated). Can't say I've monitored CPU Usage closely though but at least we don't seem to be generating any new problems by re-using the JSESSIONID.

[dstaudt]

Good to hear, thanks for the trip report

I would note that re-using the session will not magically reduce the actual AXL/SQL processing overhead, but rather means that the AXL service does not have to spin up, execute and wait for the authentication backend (typically LDAP) to process and respond to the auth request.  Apparently that process is pretty heavy and latent, so a clean shortcut right at the Tomcat layer is really beneficial.

I also understand that recent CUCM versions have fairly tight throttle on rapid sequential/concurrent full-stack authentication attempts, which session re-use should avoid.  (I suppose that might possibly be related to your other 503 throttle issue...)