I guess I should clarify. What’s the intended lifecycle of a Scanner or BatchScanner vs a Connector? Is it intended to have a single long lived Connector from which a Scanner or BatchScanner is created and closed per request? Or is a Scanner or BatchScanner (or a pool of them) meant to be long lived and serve multiple subsequent requests?
Sent from my iPhone On Jun 5, 2023, at 15:14, Christopher <ctubb...@apache.org> wrote:
In Accumulo code, we do try to reuse thrift connections, but I'm not sure if the thrift code itself is reusing TLS sessions or not.
Keep in mind that Accumulo is a distributed system. Many of these handshakes might be going to different servers in a cluster. Are you able to tell if that is the case? It might be possible to increase session timeouts or the number of cached sessions, but the best case is that you'll still need to do a handshake with each server your client talks to.
It might also help if you told us the version of Accumulo you are using, and how you are using the client code (like, are you reusing client objects). If you can share a bit of the jstack with us, that might also be helpful if we need to troubleshoot further. We've recently been required to enable TLS between our Accumulo clients and the tablet servers. We've got it working, but we're experiencing a significant performance impact. I'm running jstack on our client processes and consistently seeing a number of Accumulo client threads in sun.security.ssl.SSLSocketImpl.performInitialHandshake. This implies to me that the Accumulo client is not reusing TLS sessions, and instead establishing a new session for each connection. Am I reading this correctly? Is there a way to configure the Accumulo client to reuse TLS sessions?
|
