-
Bug
-
Resolution: Unresolved
-
Normal
-
None
-
None
-
None
-
Low
-
ZStream
-
rhel-idm-ds
-
0
-
False
-
False
-
-
None
-
None
-
Regression Exception
-
None
-
None
-
Unspecified
-
Unspecified
-
Unspecified
-
None
Ticket created from upstream issue: https://github.com/389ds/389-ds-base/issues/6979
*Issue Description*
Some applications using asynchronous operations can consume multiple workers. If the load remains under maxthreadperconn it can not be detected. Even if it hit that limit, it is not easy to identify which client (connection) is responsible of such requests.
Monitoring the server is the easiest way to detect that behavior but it is impacting (slowdown the connections) and sometime impossible if the server is unresponsive.
As a result, if a server becomes unresponsive because of too many asynchronous requests it is difficult to diagnose.
The suggested fix is to log a new 'notes' character (e.g. 'a') in the access log to identify asynchronous requests
*Package Version and Platform:*
- all versions
*Steps to Reproduce*
Steps to reproduce the behavior:
1. runs asynchronous requests under maxthreadperconn, the server becomes unresponsive
*Expected results*
asynchronous requests should be tagged in access logs so that a simple grep will find them
- links to