Hi,
bear with me - I am still trying to wrap my head around async API issues.
Having thought about it for a while I am thinking right now that using the Async API actually only makes sense if the async response is parked for a while. The important aspect being having eventually more responses than threads dealing with them.
In other words, it IMHO makes no sense to have an async response be handled by another thread (e.g. via @Asynchronous) right away because that would also consume one thread per response.
I fail to see the difference between using more 'backend' threads in order to have less http handling threads. One could equally well just increase the http pool max size.
Or yet in other words: If one does not park more than one response in a single thread the number of used threads will simply O(n) increase with the number of requests. (Which to prevent is the very reason of the Async API AFAIU).
Or is there anything in any of the containers around that makes an Http handling thread any different from another thread?
Bottom line of all this being: I think the mandatory advice on using the Async API would be: store more than one response in a single thread until response processing can be started. We should see a collection-type variable holding async responses. Otherwise the effect of the Async API would be zero at beast (given its own overhead)
Agreed?
Jan