You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Title: Redis proxy - More classes and Design patterns to support additional commands
Description:
HI i am Working for https://www.freshworks.com/ . We have self hosted redis cluster in our organisation
we are using Envoy proxy for our clients interaction . The Envoy in its current form lacks support many commands
To make it useful for us we have made changes in envoy to support more than 50+ commands and its been running in production
We would like to contribute those changes to envoy community ,
starting this issue thread to initiate a conversation and understand is anyone else is working on such improvements
Short summary of Proposal
The current redis proxy code follows a chain of responsibility and observer design pattern , such that the commands received in proxy filter is linearly processed in chain and response is sent back
This design pattern will not allow for supporting commands like pubsub, blocking commands , which requires dedicated 1:1 connections between redis and client , rather than going via upstream connection pool
The proposal is to extend or transform the transaction class in to a bridge class , which will have abstractions to support implementations for pubsub , blocking , transaction commands , based on the input command appropriate implementation will be invoked with a dedicated upstream client
When the response is received for such commands , the regular chain of flow will not happen , we can have a mediator object in client impl which will define which flow the response should take , either directly to command filter in case of pubsub commands or regular chain for other commands
we are preparing a detailed document , before that just wanted to understand
is community willing to take such changes
is anyone already working on such changes
what documents are expected from us to take this as a proposal and then implementation
Below are the list of commands for which we have added support in envoy in our local repo
Title: Redis proxy - More classes and Design patterns to support additional commands
Description:
HI i am Working for https://www.freshworks.com/ . We have self hosted redis cluster in our organisation
we are using Envoy proxy for our clients interaction . The Envoy in its current form lacks support many commands
To make it useful for us we have made changes in envoy to support more than 50+ commands and its been running in production
We would like to contribute those changes to envoy community ,
starting this issue thread to initiate a conversation and understand is anyone else is working on such improvements
Short summary of Proposal
we are preparing a detailed document , before that just wanted to understand
Below are the list of commands for which we have added support in envoy in our local repo
sunion | sdiff | sinter | sinterstore | zunionstore | zinterstore | pfmerge | georadius | georadiusbymember | xrevrange
subscribe | psubscribe | unsubscribe | punsubscribe | publish | pubsub | brpoplpush | bzpopmax | bzpopmin | blpop
brpop | script | flushall | keys | slowlog | config (set & get) | client (getname setname) | info | cluster (slots keyslot) | select
scan | hello* | XCLAIM | rename | xadd | xread | xdel | xtrim | xlen | xrange
getdel | GETEX | SORT | ZMSCORE | SDIFFSTORE | MSETNX | SUBSTR | ZRANGESTORE | ZUNION | ZDIFF
XAUTOCLAIM | XGROUP | XINFO | SUNIONSTORE | SMISMEMBER | HRANDFIELD | GEOSEARCHSTORE | XREADGROUP | ZDIFFSTORE | GEOSEARCH
RANDOMKEY | ZINTER | BLMOVE | ZRANDMEMBER | BITOP | LPOS | RENAMENX |
[optional Relevant Links:]
The text was updated successfully, but these errors were encountered: