ctubbsii commented on issue #4877: URL: https://github.com/apache/accumulo/issues/4877#issuecomment-2347075963
> So thinking the code should wait on that future and that would allow the log4j async mechanism to kick in. I'm having trouble understanding how waiting on the future would have anything to do with the number of threads. The future represents the executable task, not the thread, right? Since this is a best effort, we shouldn't care if the task finished or not. My expectation for the httpClient is that it will maintain threads/connections internally and that is largely abstracted from us. However, this is not the log4j async mechanism. That's just how the appender works when it has events to append to the connection. The log4j async works at a level above this, prior to entering the appender, and is handled by the lmax disruptor threads/executors for the log messages, not the http messages that they get translated into. The log4j async mechanism is supposed to drop messages after a best effort append. We could fail more often in this http code in response to backpressure from the http connection, to let it do that, but I think that would end up resulting in a lot of retries in the log4j code, without additional config to limit them. The other aspect I'm not sure about is whether the log4j async queues are actually filling up. If so, a user might want to more agressively drop stuff from the async queues at the max log level threshold. I think by default it only drops stuff at INFO and lower. That should be a user configuration change, though, not a code change. So, I think there's potential optimization in the client: 1. User configuration of async logging options, 2. HttpClient executor threads/future handling, 3. Applying backpressure from the HttpClient-based Appender by throwing exceptions back out to the log4j framework to be handled by the log4j async stuff. The potential optimization in the server is: 1. Reduce thread contention by using a better concurrency model or data structure, instead of a synchronized method that gets called by everybody and blocks even simple things like string concatenation/building, (#4876) 2. Implement QoS handler to rate limit the flood of incoming events (#4877, this issue), 3. Drop deduplication feature or alter it in some other way to remove the need for concurrency (also discussed on #4876) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
