[
https://issues.apache.org/jira/browse/GEODE-9752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430259#comment-17430259
]
Darrel Schneider commented on GEODE-9752:
-----------------------------------------
If we find read ops that will consume more memory (than a single netty ByteBuf
for example) then those read ops should probably do a critical memory check
before they consume that memory. The can just call
ExecutionHandlerContext.checkForLowMemory.
> Limit Memory Consumption for Read Operation
> -------------------------------------------
>
> Key: GEODE-9752
> URL: https://issues.apache.org/jira/browse/GEODE-9752
> Project: Geode
> Issue Type: Improvement
> Components: redis
> Affects Versions: 1.15.0
> Reporter: Wayne
> Priority: Major
>
> The "read" commands can be made more memory friendly by streaming back their
> result to netty a "batch" at a time. They can get the netty ByteBuf and write
> the result directly to it. Once the buffer contains a certain number of bytes
> (say 4k) it do a write and flush. Once that completes it can then use the
> same buffer to send the next 4k bytes to the client. Writing the response
> directly to the netty ByteBuf will also produce less garbage. The only
> downside to it is that the writing will be done while holding the stripe
> lock. This probably will not be any slower unless the buffer fills up while
> we still hold the lock. The last buffer (the one that is not full) can be
> done after the lock is released just as we currently do by returning a
> RedisResponse outside the lock and then asking it to write itself to netty.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
