reactor / BlockHound

Java agent to detect blocking calls from non-blocking threads.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

More description for "DefaultDriverConfigLoader : [s0] Unexpected exception during scheduled reload (BlockingOperationError: Blocking call! java.io.FileInputStream#readBytes)"

patpatpat123 opened this issue · comments

Hello BlockHound Team,

Hope you are well, safe and sound.
During one of our tests, where we activate BlockHound in order to find blocking calls in our business logic, we found this issue:

2021-09-04 19:44:55.766  WARN [myservice,,] 10639 --- [     s0-admin-1] .d.o.d.i.c.c.t.DefaultDriverConfigLoader : [s0] Unexpected exception during scheduled reload (BlockingOperationError: Blocking call! java.io.FileInputStream#readBytes)

What is surprising is that it is not coming from the handler. I.e, we send requests to our business handlers, and it is fine, not blocking, but the app, periodically, will yield this warning.

What is hard to troubleshoot, is that we do not know the root cause of this warning.

For example, when there is a blocking call, we can see a stack trace, up until where the blocking call is from.

For this warning, I can only see this one line, coming periodically.

May I ask why BlockHound is not displaying more information that that please?

Also, what would be possible to do in order to investigate the origin of this warning please?

Thank you

Have you been able to troubleshoot this issue? It seems to me the reason you don't see a stacktrace from BlockHound is that this message is produced by .d.o.d.i.c.c.t.DefaultDriverConfigLoader (whatever that is), probably catching the BlockHound exception.

If you can reproduce it in a controlled test environment, you might have a chance to get further information by using this tip from the FAQ: https://github.com/reactor/BlockHound/blob/master/docs/tips.md#debugging