[
https://issues.apache.org/jira/browse/GEODE-9752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17430712#comment-17430712
]
Dan Smith commented on GEODE-9752:
----------------------------------
I think the current behavior in RedisSortedSet, where it returns a
List<byte[]>, isn't so bad. Yes, the list can be long, but those byte[] objects
are references to the existing members.
I think the big problem is that later, when we start sending the response to
the client, we serialize the whole thing into one ByteBuf. If we optimize that
part of the code and only serlialize and send part of the list at a time I
think we can avoid most OOME issues with a large zrange.
> 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)
