newrelic / newrelic/newrelic-java-agent
Jedis Instrumentation Bug
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 240
- Forks
- 170
- Avg merge
- 3d 2h
- Merged PRs (30d)
- 21
Description
I think Jedis instrumentation of Redis shows wrong data in the databases section when we compared it to lettuce instrumentation.
Description
The problem we encountered in NewRelic Java Agent is that we cannot measure the exact time elapsed in Redis when using the Jedis library, and we see the elapsed time as very short. We can explain the main reason for this as follows, Jedis library opens a connection between client-server and performs 2 operations after the connection is opened, one of them is sendCommand, this command only tells Redis which command we use and which key. function ends. Then the getBinaryBulkReply command is called on the same connection. This command waits for the answer from the connection and reads it when the server returned. In other words, the elapsed time on Redis should be the total time elapsed in the sendCommand and getBinaryBulkReply functions. But New Relic Java Agent seems to only trace the sendCommand function and show its duration, so we can't see very realistic times. However, Java Agent only traces sendCommand.
Expected Behavior
The elapsed time on Redis should be the total time elapsed in the sendCommand and getBinaryBulkReply functions. But New Relic Java Agent seems to only trace the sendCommand function and show its duration, so we can't see very realistic times.
Additional context

We implemented custom instrumentation here to trace getBinaryBulkReply function and you can see that redis get is very very short compared to getBinaryBulkReply function. But actual redis get time should be sum of these operations.
Code Snippets - Jedis Related - Jedis Version v3.7.1:
BinaryJedis - get() - https://github.com/redis/jedis/blob/v3.7.1/src/main/java/redis/clients/jedis/BinaryJedis.java#L424
BinaryClient - client.get()
https://github.com/redis/jedis/blob/5e01cca0e72bdafca8bf207508eb6aa629cd2a6c/src/main/java/redis/clients/jedis/BinaryClient.java#L206
Connection - client.getBinaryBulkReply
https://github.com/redis/jedis/blob/5e01cca0e72bdafca8bf207508eb6aa629cd2a6c/src/main/java/redis/clients/jedis/Connection.java#L287
Connection - sendCommand
https://github.com/redis/jedis/blob/5e01cca0e72bdafca8bf207508eb6aa629cd2a6c/src/main/java/redis/clients/jedis/Connection.java#L149
New Relic Java Agent - Jedis - Connection_Instrumentation.class
https://github.com/newrelic/newrelic-java-agent/blob/16840a8e7440009433564277f0c24e9232782e2f/instrumentation/jedis-3.0.0/src/main/java/redis/clients/jedis/Connection_Instrumentation.java
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with instrumentation/jedis-3.0.0/src/main/java/redis/clients/jedis/Connection_Instrumentation.java and compare its tracing with Jedis Connection.sendCommand and getBinaryBulkReply. Review the linked Jedis v3.7.1 call sites and verify that the reported Redis elapsed time covers both operations, using the described timing comparison as the completion check.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, redis
- Domain
- backend, observability
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 35/100