Avoid recursive listener invocation

[shiftleftsecurity]

Avoid recursive listener invocation

[idelvall]

This has a limitation though, listeners should not create new threads. This can be handled by instrumenting java.lang.Thread to populate the parent thread flag state, or at least can just be documented as a limitation

[idelvall]

We could avoid dealing with this if we follow this idea

[idelvall]

I have been thinking in this. And I don't see a way of avoiding the thread local checking at

bctrace/src/main/java/io/shiftleft/bctrace/runtime/Callback.java

Line 35 in dc5caba

private static final ThreadLocal<Boolean> NOTIFYING_FLAG = new ThreadLocal<Boolean>();

, that lets the callback activate/deactivate listener notification, so no recursive notification can occur.

We could load listener implementations in a custom classloader and exclude that classloader from being instrumented (that would improve our current package-based exclusion), but eventually those classes could make use of classes from parent classloaders, namely the bootstrap classloader that are indeed instrumented.

What do you think?

[idelvall]

By removing this check we gain around 3ms in helloshiftleft test latency.
From:

ShiftLefts-MacBook-Pro:~ ignacio$ echo "GET http://0.0.0.0:8080/customers" | vegeta attack -duration 10s -insecure | vegeta report
Requests      [total, rate]            500, 50.10
Duration      [total, attack, wait]    9.993210496s, 9.97999991s, 13.210586ms
Latencies     [mean, 50, 95, 99, max]  13.450733ms, 13.546259ms, 16.432319ms, 17.676689ms, 19.020605ms
Bytes In      [total, mean]            705000, 1410.00
Bytes Out     [total, mean]            0, 0.00
Success       [ratio]                  100.00%
Status Codes  [code:count]             200:500  
Error Set:

to:

ShiftLefts-MacBook-Pro:~ ignacio$ echo "GET http://0.0.0.0:8080/customers" | vegeta attack -duration 10s -insecure | vegeta report
Requests      [total, rate]            500, 50.10
Duration      [total, attack, wait]    9.993284757s, 9.979999899s, 13.284858ms
Latencies     [mean, 50, 95, 99, max]  11.060517ms, 11.333885ms, 13.485156ms, 13.819625ms, 14.48848ms
Bytes In      [total, mean]            705000, 1410.00
Bytes Out     [total, mean]            0, 0.00
Success       [ratio]                  100.00%
Status Codes  [code:count]             200:500