Skip to content

Implement byte array reuse in nio transport #27563

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Tim-Brooks opened this issue Nov 28, 2017 · 1 comment
Closed

Implement byte array reuse in nio transport #27563

Tim-Brooks opened this issue Nov 28, 2017 · 1 comment
Assignees
Labels
:Distributed Coordination/Network Http and internode communication implementations >enhancement v7.0.0-beta1

Comments

@Tim-Brooks
Copy link
Contributor

Currently, we reuse byte arrays when writing messages in the TcpTransport. We request bytes from a page recycler and serialized the message. When the message is written to the channel, a callback releases the bytes. This means that, by default, the NioTransport already includes byte array reusage for the write use case.

The read case is trickier. As read message length is unknown until a message is partially deserialized, we need some method of requesting a new byte array when we run out of space for reading. When the message has been completely read, deserialized, and dispatched, the bytes for the message can be released.

I think that we do not currently want this worked to be hooked onto BigArrays or involve circuit breakers (based on this comment by @jpountz). Instead we want to use the PageRecycler for a specific solution for the nio case.

A solution for the tcp read case would ideally generalize for future protocols.

This is related to #27260

@Tim-Brooks Tim-Brooks added :Distributed Coordination/Network Http and internode communication implementations >enhancement v7.0.0 labels Nov 28, 2017
@Tim-Brooks Tim-Brooks self-assigned this Nov 28, 2017
Tim-Brooks added a commit that referenced this issue Dec 6, 2017
This is related to #27563. In order to interface with java nio, we must
have buffers that are compatible with ByteBuffer. This commit introduces
a basic ByteBufferReference to easily allow transferring bytes off the
wire to usage in the application.

Additionally it introduces an InboundChannelBuffer. This is a buffer
that can internally expand as more space is needed. It is designed to
be integrated with a page recycler so that it can internally reuse pages.
The final piece is moving all of the index work for writing bytes to a
channel into the WriteOperation.
Tim-Brooks added a commit that referenced this issue Dec 6, 2017
This is related to #27563. In order to interface with java nio, we must
have buffers that are compatible with ByteBuffer. This commit introduces
a basic ByteBufferReference to easily allow transferring bytes off the
wire to usage in the application.

Additionally it introduces an InboundChannelBuffer. This is a buffer
that can internally expand as more space is needed. It is designed to
be integrated with a page recycler so that it can internally reuse pages.
The final piece is moving all of the index work for writing bytes to a
channel into the WriteOperation.
Tim-Brooks added a commit that referenced this issue Dec 8, 2017
This is related to #27563. This commit modifies the
InboundChannelBuffer to support releasable byte pages. These byte
pages are provided by the PageCacheRecycler. The PageCacheRecycler
must be passed to the Transport with this change.
Tim-Brooks added a commit that referenced this issue Dec 8, 2017
This is related to #27563. This commit modifies the
InboundChannelBuffer to support releasable byte pages. These byte
pages are provided by the PageCacheRecycler. The PageCacheRecycler
must be passed to the Transport with this change.
@Tim-Brooks
Copy link
Contributor Author

This is closed by #27696.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Distributed Coordination/Network Http and internode communication implementations >enhancement v7.0.0-beta1
Projects
None yet
Development

No branches or pull requests

2 participants