[
https://issues.apache.org/jira/browse/GEODE-9752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17436176#comment-17436176
]
Dan Smith commented on GEODE-9752:
----------------------------------
> it could be better if as we iterate over data structure we start writing the
> result
I guess I'm not sure if this is doable in a thread safe way or not. We don't
want to hold the stripe locked while we are sending data to the client. But we
also can't use an iterator from our non threadsafe data structures outside the
lock.
> 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)
