ssl java implemntation blocking?

[ad...@cs.miami.edu]

Hi,

Quick question:  When using the standard java implementation of ssl, does the extra ssl cpu computation block any important Vertx threads?  Is the ssl cpu computation done in parallel among many requests in several threads, or is the ssl computation only done in one thread and then done in serial?

Thanks,

-Adam

[creativedotit]

Maybe it blocks, i cannot answer this, but it's well known that it is slower than openssl (10MB/s vs 200MB/s i read somewhere in the vert.x docs) so tncnative is the way for now 

[ad...@cs.miami.edu]

I asked this question a while back, but the thread kind of died out.  So I thought I would bump it.

The question is:  for the java implementation of SSL, on what thread does the encrypt/decrypt computation occur?  Is it on the event loop (if so, would this be considered blocking) or does it occur on another thread.

thanks,

-Adam

[Tim Fox]

By "blocks" I assume you mean "takes a long time" rather than actually blocking the thread (e.g. on IO)?

AFAIK the encryption is done in chunks so shouldn't block anything.

(IIRC, there is/was an issue when running SSL in debug mode, a global mutex comes into play and kills performance)

[ad...@cs.miami.edu]

>> By "blocks" I assume you mean "takes a long time"

exactly!

>> AFAIK the encryption is done in chunks so shouldn't block anything.

Is there anyway to do the entire  encryption on a worker thread at once, as opposed to in chuncks on the io threads?  In the case that the entire response is known, maybe it could be passed through an executeBlocking function, and then the the response.end() would send the encrypted response directly?

>>there is/was an issue when running SSL in debug mode

Is this problem only if vert.x uses "debug mode" (not even sure what that is), or do you mean that wehn running in a debugger the cause of the problem became apparent.

-Adam

[Tim Fox]

On Monday, 26 June 2017 09:13:55 UTC+1, ad...@cs.miami.edu wrote:

>> By "blocks" I assume you mean "takes a long time"

exactly!

>> AFAIK the encryption is done in chunks so shouldn't block anything.

Is there anyway to do the entire  encryption on a worker thread at once, as opposed to in chuncks on the io threads?  In the case that the entire response is known, maybe it could be passed through an executeBlocking function, and then the the response.end() would send the encrypted response directly?

It's not something Vert.x has control over, and I don't see what benefit that would provide tbh.

 

>>there is/was an issue when running SSL in debug mode

Is this problem only if vert.x uses "debug mode" (not even sure what that is), or do you mean that wehn running in a debugger the cause of the problem became apparent.

JDK SSL debug mode, nothing to do with Vert.x.

http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/ReadDebug.html 

It's recommended though to use openssl impl not the JDK impl:

http://netty.io/wiki/requirements-for-4.x.html#wiki-h4-4