spring-cloud / spring-cloud/spring-cloud-gateway
Provide additional debug information when there is a memory leak (Reactor Netty client)
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 4.9k
- Forks
- 3.5k
- Avg merge
- 20h 57m
- Merged PRs (30d)
- 8
Description
Hi,
Netty provides the following API
io.netty.buffer.ByteBuf.touch()
/**
* Records the current access location of this object for debugging purposes.
* If this object is determined to be leaked, the information recorded by this operation will be provided to you
* via {@link ResourceLeakDetector}. This method is a shortcut to {@link #touch(Object) touch(null)}.
*/
ReferenceCounted touch();
Currently Reactor Netty is the last component that records access to the byte buffers.
It will be very helpful if the Spring Gateway implementation uses this functionality when it does additional transformations of the content or buffers the object.
If there is a memory leak, when Netty dumps the stack traces of the components that accessed this object, it will be easier to find where the buffer was leaked.
Thanks,
Violeta
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 by locating the Reactor Netty client paths where Spring Gateway transforms or buffers content, then review how Netty ByteBuf.touch() and ResourceLeakDetector expose access locations. Done means the relevant Gateway buffer accesses are recorded so leak stack traces identify those transformations more clearly.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, spring, spring-boot
- Domain
- api, backend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100