On Mon, Jun 27, 2016 at 12:04 PM, <therealnewo...@gmail.com> wrote: > On Mon, Jun 27, 2016 at 11:54 AM, Rainer Jung <rainer.j...@kippdata.de> wrote: >> Great analysis. I was really wondering, what could make the hash map so huge >> and hadn't thought about the hash function as the problem. >> >> Before OpenSSL 1.1.0 there's a callback for applications to provide their >> own thread IDs: >> >> https://www.openssl.org/docs/man1.0.2/crypto/CRYPTO_THREADID_set_callback.html >> >> So we could probably work around the problem of the poor hashing function by >> passing in IDs that work for hashing (pre-hashed ID?). Of course then we >> loose the direct association of the OpenSSL thread ID with the real platform >> thread id. >> >> Currently our callback in tcnative is ssl_set_thread_id() which refers to >> ssl_thread_id(), which on Linux gets the ID from the APR function >> apr_os_thread_current(). So we could add some hashing formula in >> ssl_thread_id(). > > I think just using the real thread id would work, since now it isn't > using the real thread id instead it is using the address location of > errno. If this was the real thread id I think the hash algorithm and > bucket selection they have now will work much better since the thread > ids are basically numerically increasing and aren't aligned to powers > of 2.
Sorry, I need to read code a bit closer. I misread the OPENSSL_VERSION_NUMBER < 0x10100000L as version < 1.0.1 and not 1.1.0. I would still expect real thread ids to provide enough of a distribution in a map where the hash bucket ends up being is ((ID * 13) & 0X7F). -nate --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
