Home Original page

Add BlockHound integration by bsideup · Pull Request #9687 · netty/netty

@bsideup mentioned this pull request

Oct 18, 2019

johnou

carl-mastrangelo

normanmaurer

bsideup added a commit to reactor/BlockHound that referenced this pull request

Oct 22, 2019 
As seen in netty/netty#9687, due to GradleUp/shadow#519,
we have `reactor/shaded/META-INF/versions/9/module-info.class`
file in the final JAR, although we thought that we excluded it.

This PR fixes a few related shading issues
and adds the missing tests for the shadowed jar,
so that we will never miss such issues again.

It also changes the shading package to `reactor.blockhound.shaded`
for better package alignment.

bsideup

bsideup

normanmaurer

carl-mastrangelo

mosesn

@bsideup 

Motivation:

Netty is an asynchronous framework.
If somebody uses a blocking call inside Netty's event loops,
it may lead to a severe performance degradation.
BlockHound is a tool that helps detecting such calls.

Modifications:

This change adds a BlockHound's SPI integration that marks
threads created by Netty (`FastThreadLocalThread`s) as non-blocking.
It also marks some of Netty's internal methods as whitelisted
as they are required to run the event loops.

Result:

When BlockHound is installed, any blocking call inside event loops
is intercepted and reported (by default an error will be thrown).

normanmaurer pushed a commit that referenced this pull request

Oct 25, 2019 
…#9687)

Motivation:

Netty is an asynchronous framework.
If somebody uses a blocking call inside Netty's event loops,
it may lead to a severe performance degradation.
BlockHound is a tool that helps detecting such calls.

Modifications:

This change adds a BlockHound's SPI integration that marks
threads created by Netty (`FastThreadLocalThread`s) as non-blocking.
It also marks some of Netty's internal methods as whitelisted
as they are required to run the event loops.

Result:

When BlockHound is installed, any blocking call inside event loops
is intercepted and reported (by default an error will be thrown).

@bsideup bsideup deleted the blockhound_integration branch

October 25, 2019 13:19

carterkozak added a commit to carterkozak/undertow that referenced this pull request

Jan 21, 2022 
This defines a BlockHound integration within undertow-core, however
this could be an entirely separate module. For this to become
mergable, BlockHound would minimally have to become a `provided`
dependency so it's not added to consumers classpaths unnecessarily,
but applied in test modules

Arguably the blockhound integration belongs in an xnio-associated
module because xnio defines the relevant XnioIoThread class.

This idea is borrowed from Netty, which added BlockHound here:
netty/netty#9687