Jdk sslhandler have blocking call #12425
Comments
|
What does blockhound log? We'll need the stack trace for that blocking call. |
|
chrisvest
added a commit
to chrisvest/netty
that referenced
this issue
May 31, 2022
Motivation: Classes might be initialized inside the event loop where blocking calls are otherwise forbidden. The JdkSslContext has a blocking call in its class initializer through initializing the Java SSLContext which does IO to deserialize its key store. Modification: Collect the class initialization code in a method, and allow it to have blocking calls in blockhound. Result: No more blockhound warnings about blocking calls in JdkSslContext class initializer. Fixes netty#12425
chrisvest
added a commit
that referenced
this issue
Jun 1, 2022
Motivation: Classes might be initialized inside the event loop where blocking calls are otherwise forbidden. The JdkSslContext has a blocking call in its class initializer through initializing the Java SSLContext which does IO to deserialize its key store. Modification: Collect the class initialization code in a method, and allow it to have blocking calls in blockhound. Result: No more blockhound warnings about blocking calls in JdkSslContext class initializer. Fixes #12425 Co-authored-by: Norman Maurer <norman_maurer@apple.com>
chrisvest
added a commit
that referenced
this issue
Jun 1, 2022
Motivation: Classes might be initialized inside the event loop where blocking calls are otherwise forbidden. The JdkSslContext has a blocking call in its class initializer through initializing the Java SSLContext which does IO to deserialize its key store. Modification: Collect the class initialization code in a method, and allow it to have blocking calls in blockhound. Result: No more blockhound warnings about blocking calls in JdkSslContext class initializer. Fixes #12425 Co-authored-by: Norman Maurer <norman_maurer@apple.com>
raidyue
pushed a commit
to raidyue/netty
that referenced
this issue
Jul 8, 2022
Motivation: Classes might be initialized inside the event loop where blocking calls are otherwise forbidden. The JdkSslContext has a blocking call in its class initializer through initializing the Java SSLContext which does IO to deserialize its key store. Modification: Collect the class initialization code in a method, and allow it to have blocking calls in blockhound. Result: No more blockhound warnings about blocking calls in JdkSslContext class initializer. Fixes netty#12425 Co-authored-by: Norman Maurer <norman_maurer@apple.com>
franz1981
pushed a commit
to franz1981/netty
that referenced
this issue
Aug 22, 2022
Motivation: Classes might be initialized inside the event loop where blocking calls are otherwise forbidden. The JdkSslContext has a blocking call in its class initializer through initializing the Java SSLContext which does IO to deserialize its key store. Modification: Collect the class initialization code in a method, and allow it to have blocking calls in blockhound. Result: No more blockhound warnings about blocking calls in JdkSslContext class initializer. Fixes netty#12425 Co-authored-by: Norman Maurer <norman_maurer@apple.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I tried to integrate some reactive tests with miku-mysql and blockhound (which uses netty-handler under the hood), and noticed that there's a blocking call when using jdkssl implementation (leading to noclassdeffound in the end).
With the netty version embedded in spring-boot-webflux 2.6.7 (tried to upgrade netty-handler version, with no more luck).
What info do you need?
Bests
The text was updated successfully, but these errors were encountered: