It is in non-blocking mode.
After removing the call to SSL_get_error for the SSL_read case (0 return value)
I discovered we call SSL_get_error in a couple more places. Here is a simple
request and the return codes on SSL_accept, SSL_read, and SSL_write and the
return codes from SSL_get_error.
You can private message me the patch and I can benchmark it for you. Please
let me know what release version or hash on git that it will cleanly apply. Do
you know what release this will be going in?
-Bryan
On May 1, 2015, at 6:49 AM, Salz, Rich rs...@akamai.com wrote:
Lock #1 is
I will just grab master then. Will this change be in the next 1.0.2 release?
-Bryan
On May 8, 2015, at 10:12 AM, Salz, Rich rs...@akamai.com wrote:
You can private message me the patch and I can benchmark it for you.
Please let me know what release version or hash on git that it will
Do you know if there is a way from preventing a call to SSL_get_error() after
getting a 0 byte read from SSL_read()? This is the main issue I am facing with
the OpenSSL error locking right now.
-Bryan
On May 1, 2015, at 6:49 AM, Salz, Rich rs...@akamai.com wrote:
Lock #1 is
, Bryan Call wrote:
This is for Apache Traffic Server and we have no knobs for turning on/off
FIPS. I am thinking about always disabling FIPS right now and that would
happen before we create the threads.
I was able to get rid of all the FIPS lock connection with the changes you
recommend
=0b732440636ab4e9eaedf237a5674bdc790c3e73;hp=2fae4820d7bab301340368e6be22445476d8d948;hb=d41e96f;hpb=ba1d6f7c9394c5efadb68cf9cf06f9b90f267b09
-Bryan
On Apr 30, 2015, at 3:52 PM, Bryan Call bc...@apache.org wrote:
This is for Apache Traffic Server and we have no knobs for turning on/off
FIPS. I am thinking about always
of the
process and never disabled/re-enabled. You would invoke FIPS_mode_set(1) once
prior to spinning up the worker threads. Therefore, the POST would be
finished prior to any multi-threaded processing.
On 04/29/2015 01:53 PM, Bryan Call wrote:
Can I safely assume that if I call FIPS_mode_set(0
. Any future FIPS validations would
be subject to the new rules. Hence, the behavior of FIPS_mode_set() may
change in the future if OpenSSL decides to pursue another validation.
On 04/28/2015 12:43 PM, Bryan Call wrote:
What do you mean by “FIPS POST has completed”?
-Bryan
40
You should try adding some logic to skip the lock in your lock handler when
the lock ID is 39 or 40. Again, it should be safe to not lock on these two as
long as the FIPS POST has completed.
On 04/24/2015 05:56 PM, Bryan Call wrote:
In my last email I ran the benchmark
lock IDs defined in crypto/crypto.h. You'll
need to identify which lock is causing the thread contention. Once you know
that, then you can look in the code to see where that lock is used and
troubleshoot from there.
On 04/23/2015 07:23 PM, Bryan Call wrote:
I was running
you checked the OpenSSL error log to see what errors are being generated?
Also, if you disable FIPS, does the thread contention still occur?
On 04/24/2015 01:36 PM, Bryan Call wrote:
We are using a single SSL_CTX across all the threads, so I will create
multiple SSL_CTX per thread. I
I was running a benchmark on a 28 core (56 hyper-threaded) server that is
running 84 threads in the process and I am seeing a lot of lock contention. I
saw a lot of lock contention in the calls to SSL_get_error() ssl3_accept(). I
am running RHEL 6.5 and openssl-1.0.1e-30.el6_6.7.x86_64. We
12 matches
Mail list logo
