[
https://issues.apache.org/jira/browse/GEODE-9338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17397635#comment-17397635
]
ASF subversion and git services commented on GEODE-9338:
--------------------------------------------------------
Commit 8aeec3960e0c40f93ea5272c573da5b8f4b045ff in geode's branch
refs/heads/develop from Hale Bales
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=8aeec39 ]
GEODE-9338: Remove strong guarantees for Radish PUBLISH command (#6704)
GEODE-9338: Remove strong guarantees for Radish PUBLISH command
Previously we guaranteed that when we published something, we would return the
number of members who acknowledged that message. This is not required based on
native Redis’s behavior, so this commit makes changes to instead return the
number of currently subscribed members.
- Use StripedCoordinator instead of StripedExecutor
- Remove event loop latches in executors
- Remove subscriber group
- Max number of publish threads set to 10
- Use a striped runnable in PubSubImpl to do the publish operation
- Add StripedExecutorService from Heinz Kabutz
- Netty version 4.1.59 -> 4.1.66
- Change pubsub work queue to a LinkedBlockingQueue
Co-authored-by: Jens Deppe <[email protected]>
> Remove strong guarantees for redis PUBLISH command response
> -----------------------------------------------------------
>
> Key: GEODE-9338
> URL: https://issues.apache.org/jira/browse/GEODE-9338
> Project: Geode
> Issue Type: Improvement
> Components: redis
> Reporter: Jens Deppe
> Assignee: Hale Bales
> Priority: Major
> Labels: pull-request-available
>
> Redis' {{PUBLISH}} command responds with the number of clients that have
> received the published message. Our current implementation attempts to
> respond with as accurate a number as possible. To that end, each publish (see
> {{PubSubImpl.publishMessageToSubscribers}} and
> {{AbstractSubscription.publishMessage}} are effectively synchronous
> operations. The current flow is:
> - PUBLISH some_message
> - Issue a fn call to each server and attempt to publish to each subscribed
> client
> - Count how many successful publish messages were written and return those
> - Respond to the redis client with the aggregated successful publishings
> In redis clustering mode, the response is only the number of local
> publishings. We can go even further and not attempt to first publish before
> subscribing, but simply respond with the current number of subscribers,
> regardless whether they are connected or not.
> We should be able to perform all pubsub work on the regular netty thread and
> completely remove the subscriber EventLoopGroup.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
