ctubbsii commented on PR #4879: URL: https://github.com/apache/accumulo/pull/4879#issuecomment-2418185962
> The comment in #4982 is on a PR for 3.1. Are you suggesting that we should look to move to a Thrift RPC for logs in 2.1? I was investigating options to limit the number of TCP connections above. I don't think we should do what was suggested in that comment in 2.1... I wasn't careful about which branch I was referring to. We still need to constrain the number of connections in 2.1 based off the current design. My earlier comment was suggesting that we could fix it with a different design in newer Accumulo versions... however, I'm not a fan of the fact that it would restrict the Appender to only being usable by Accumulo itself (and specifically, servers that the accumulo-monitor knows to poll). When we spoke earlier today about that approach for metrics, I didn't consider that point. I also didn't consider that there would be additional complexity regarding how many logs to preserve per-server for retrieval by the monitor. Overall, I'd rather drop the feature than try to handle increasing complexity for something users shouldn't even be using (because it's an awful way to do log collection, analysis, or alerting). > If we need to support the current Appender, then we may want to look http/2 as a solution, as that allows for multiple concurrent requests over the same connection. This should reduce the overall number of connections to the Monitor for logs. That won't work. I discovered you can't upgrade a plaintext HTTP/1.1 to HTTP/2 using the "Upgrade:" header with POST calls, so this can't use HTTP/2 over plaintext anyway. We'd either have to use TLS on the monitor to get HTTP/2 or add in extra round-trip GET calls that we wait on to upgrade the connection before we can send POST. Furthermore, the "h2c" upgrade token to upgrade to HTTP/2 is obsoleted by the latest [HTTP/2 RFC](https://datatracker.ietf.org/doc/html/rfc9113), so we should probably not start relying on it now. -- 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]
