[ 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)