{"id":5317,"date":"2026-09-18T01:56:15","date_gmt":"2026-09-18T04:56:15","guid":{"rendered":"https:\/\/tucumandevelopers.com\/index.php\/2026\/09\/18\/logpoints-walkthrough\/"},"modified":"2026-09-18T01:56:15","modified_gmt":"2026-09-18T04:56:15","slug":"logpoints-walkthrough","status":"publish","type":"post","link":"https:\/\/tucumandevelopers.com\/index.php\/2026\/09\/18\/logpoints-walkthrough\/","title":{"rendered":"Logpoints Walkthrough"},"content":{"rendered":"
\n
\n
\n
\n

IntelliJ IDEA<\/a><\/p>\n

Modern development tools, especially IntelliJ IDEA, have such comprehensive debugging support that for virtually any niche use case, there is a specialized tool for the job. This can make it hard to know where to begin. If you are new to debugging tools and want the biggest return on your learning investment, the best feature to start with is logpoints.<\/p>\n

Even though working with them is as simple as debugging with plain println statements (and arguably simpler), they vastly<\/em> broaden the range of issues that you can debug. For some issues, logpoints are the only practical approach. And for the rest, logpoints provide a convenience that saves a lot of time and effort.<\/p>\n

Also, in IntelliJ IDEA 2026.2, logpoints got some very cool improvements<\/a>, so it\u2019s a perfect time to explore them.<\/p>\n

Our example problem<\/strong><\/h2>\n

Here\u2019s a mini client and server<\/a> that use gRPC<\/a> for communication. The server has a bug that makes it return incorrect discount values for some tenants.<\/p>\n

So we\u2019ll follow the usual debugging flow. We\u2019ll reproduce the problem, set up visibility into the inner workings of the server, send a problematic request, and observe exactly how it produces the wrong result.<\/p>\n

Reproducing the bug<\/strong><\/h2>\n

To simulate running in another environment, the project bundles a Dockerfile with the listening and debug ports exposed. You can launch it using the supplied GrpcQuoteServerContainer<\/kbd> run configuration or directly from the command line:<\/p>\n

docker build -t grpc-timeout . docker run --rm -p 50051:50051 -p 5005:5005 grpc-timeout<\/pre>\n
Then for a problematic request, use the GrpcQuoteClientLoop<\/kbd> run configuration, which will periodically query the server. This lets us forget about sending requests manually and focus more on what happens on the server.<\/p>\n
When both the server and the client loop are running, the console shows the following:<\/p>\n
tenant='JetBrains' region='EMEA' status=OK symbol=IDEA price=100.00 USD source=live detail=region=emea, discount_bps=0<\/pre>\n
But we would expect to see:<\/p>\n
tenant='JetBrains' region='EMEA' status=OK symbol=IDEA price=80.00 USD source=live detail=region=emea, discount_bps=2000<\/pre>\n
Attaching to the server<\/strong><\/h2>\n
The server is not launched from a local IntelliJ IDEA debug session, but it listens for debugger connections, so we can still attach to it using the provided GrpcQuoteServer<\/kbd> attach run configuration.<\/p>\n
It\u2019s worth noting that, for the debugger, there is no difference whether the process runs locally, in a separate environment, or on a remote host. In all three cases, the communication happens over a socket, so our exercise is valid for debugging any Java process regardless of locality.<\/p>\n
Logpoints<\/strong><\/h2>\n
Logpoints are similar to println<\/kbd> statements in that they don\u2019t suspend the program but only log the necessary details to the console. Unlike println<\/kbd> statements, however, they can be changed without rebuilding or redeploying the application.<\/p>\n
You might already know how to set a logpoint, but IntelliJ IDEA 2026.2 introduced a faster way. Click in the gutter in between any two executable lines and enter the expression you want to log. As the starting point, we can use the beginning of the query handling method ( QuoteEndpoint:12 <\/kbd>):<\/p>\n
<\/figure>\n
Warning:<\/strong> Beware of heavy computations in hot paths. They are executed in the same VM and are not magically free. As of version 2026.2, IntelliJ IDEA removes the debugger-introduced overhead through instrumentation, but heavy logging expressions may still take time to execute.<\/p>\n
For every incoming request, the console now prints:<\/p>\n
EMEA JetBrains<\/pre>\n
Now, with the request loop running, we can progressively change and add logpoints until the output points to the bug. Just add more logpoints or update the existing ones and watch for new messages in the console as new requests come in.<\/p>\n
\n<\/figure>\n
After following the call chain, which allows us to rule out any initial suspicions we might have had, we arrive at the discountBpsFor()<\/kbd> method:<\/p>\n
<\/figure>\n
The console points at the tenant name not being properly normalized:<\/p>\n
tenant = JetBrains expected: jetbrains<\/pre>\n
Also, the absence of discount applied tells us that the block with the correct discount is never entered. Normalizing the tenant name should fix the bug:<\/p>\n
private static int discountBpsFor(String tenant) { if (\"jetbrains\".equalsIgnoreCase(tenant)) { return 2_000; }     return 0; }<\/pre>\n
Pro tip<\/strong>: When in doubt about what produced specific console output, click the line in the console, and IntelliJ IDEA will take you to the relevant logpoint or piece of code:<\/p>\n
<\/figure>\n
Even if you are using println<\/kbd> statements for logging, the navigation will work for you as long as you are running the process with IntelliJ IDEA\u2019s debugger.<\/p>\n
Testing the fix<\/strong><\/h2>\n
Let\u2019s test the fix while we\u2019re here. Logpoints are meant for logging, not for modifying the program, but nothing really prevents us from testing how a particular fix would behave:<\/p>\n
<\/figure>\n
The prototype works as expected:<\/p>\n
EMEA JetBrains jetbrains discount applied<\/pre>\n
Now that we\u2019ve tested the fix, we can change the actual server code.<\/p>\n
Why not use <\/strong>println<\/strong> statements?<\/strong><\/h2>\n
You\u2019re probably thinking logpoints look like nicer println statements. And they do, in a sense, because the core mechanic is the same. In both cases, you add probes in a simple way that doesn\u2019t affect how the program runs<\/strong>.<\/p>\n
Despite their similarities, there are several reasons why logpoints can be a better choice:<\/p>\n