Any good ways to filter common concurrency framework lines from stack traces?
Matt Sicker <[email protected]> Wed, 4 Jun 2025 12:01:43 -0500
| Newsgroups | gmane.comp.jakarta.log4j.user |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail=_B94BDF43-E3DC-4775-A527-6926A1DC2F29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 For example, in the simple case, suppose I=E2=80=99m using = CompletableFuture and the value times out with a TimeoutException. This = stack trace will include tons of entries for = java.util.concurrent.CompletableFuture related to the transformation = pipeline leading up to that point (i.e., transforming CompletableFuture = instances creates a complicated call stack as an implementation detail). Suppose we then combine some combination of other typical libraries like = resilience4j, failsafe, spring-retry, micrometer, open telemetry, and = then integrate with some asynchronous things like netty, reactor, Kotlin = coroutines, various thread pools and queues, and potentially even some = sort of context propagation wrappers. In the end, I get a stack trace = that=E2=80=99s about 200% longer than necessary. IDEs seem to have a = feature that can collapse these sorts of common parts of the stack trace = for comparison. While I have found that the throwable converter pattern [1] supports = filtering by a list of package names, this may be overly broad for my = use case here depending on the structure of the library I=E2=80=99m = trying to filter out. [1]: = https://logging.apache.org/log4j/2.x/manual/pattern-layout.html#converter-= exception --Apple-Mail=_B94BDF43-E3DC-4775-A527-6926A1DC2F29--