Changing cache name when using Redis protocol

[Roman Shtykh <rs...@yahoo.com.INVALID>]

Igniters,
Getting back to the discussion on how to switch between caches when using Redis (and potentially memcached).# Please note, that this is a problem only with a part of Redis data stuctures such as currently implemented STRING. For sets and hash tables, set/hash name can be treated as a cache name -- no problem here.
I have several questions to discuss.1. I think this can be done by introducing RedisConfiguration where a user can specify a cache name for STRING data.Redis is implemented on top of REST processing which is configured with ConnectorConfiguration. Is that so wrong then to have RedisConfiguration/MemcachedConfiguration as a part of it? (Or having a list of configurations for several protocols to use simultaneously in IgniteConfiguration instead of one -- currently only one per IgniteConfiguration?)
2. Putting aside memcached etc., I can implement "CONFIG SET parameter value" command of Redis protocol to set the cache name, so that a user, prior to working with Ignite via Redis, issues the command and uses the once-specified cache. The question -- is it safe to hold it in GridRestProcessor? Will all nodes see this cache name setting request and all its processors safely hold it?

Any ideas/advice on how to do it better?

Jira issue: https://issues.apache.org/jira/browse/IGNITE-5229
Roman

Re: Changing cache name when using Redis protocol

[Roman Shtykh <rs...@yahoo.com.INVALID>]

Yakov,
Thank you for the pointers! Let's implement it with SELECT then, with 'redis-ignite-internal-cache-0' as a default one.
Sorry, I was wrong about the number of databases, just remembered there was a limit. I should have had to recheck.
-- Roman




    On Friday, May 19, 2017 6:29 PM, Yakov Zhdanov <yz...@apache.org> wrote:
 

 Roman, your description seems fine to me. I don't like CLIENT SETNAME. This
may confuse redis users as well.

Why do you say that we will have only 8 databases. As far as I remember
there are 16 by default and this is configurable and can be increased as
well. Can you please check this?

To get access to per-connection meta you will need to add
"addMeta/meta/removeMeta" methods to
org.apache.ignite.internal.processors.rest.request.GridRestRequest to
provide access to org.apache.ignite.internal.util.nio.GridNioSession's meta
related methods or to attributes' related methods of HttpSession in
depending on where request is created..

--Yakov


   

Re: Changing cache name when using Redis protocol

[Yakov Zhdanov <yz...@apache.org>]

Roman, your description seems fine to me. I don't like CLIENT SETNAME. This
may confuse redis users as well.

Why do you say that we will have only 8 databases. As far as I remember
there are 16 by default and this is configurable and can be increased as
well. Can you please check this?

To get access to per-connection meta you will need to add
"addMeta/meta/removeMeta" methods to
org.apache.ignite.internal.processors.rest.request.GridRestRequest to
provide access to org.apache.ignite.internal.util.nio.GridNioSession's meta
related methods or to attributes' related methods of HttpSession in
depending on where request is created..

--Yakov

Re: Changing cache name when using Redis protocol

[Roman Shtykh <rs...@yahoo.com.INVALID>]

Yakov,

Thanks for sharing your thoughts!

I agree that both configuration and CONFIG SET lack flexibility. Let’s forget about these approaches.

For specifying cache per connection, CLIENT SETNAME [cache_name] [1] can be another option. It can be done with config templates as you proposed too. What do you think about it?

With SELECT a user can specify only 8 caches, but generally I think it should be enough, since, as I mentioned in the previous message, this cache switch is needed mostly for STRING data (for HASH, SET etc. key names can be considered as cache names).
With the approach you proposed, a user
1. Specifies the cache configuration (template) with predefined name ‘redis-ignite-internal-cache’
2. Issues ‘SELECT n’, and uses ‘redis-ignite-internal-cache-n’
Is that correct? 

I like the approach. Can you or anyone from the community advise on how/where to keep the cache number per connection? Couldn’t find something like connection session.
[1] https://redis.io/commands/client-setname

-- Roman


    On Thursday, May 18, 2017 8:50 PM, Yakov Zhdanov <yz...@apache.org> wrote:
 

 Roman,

I don't like implementing of special configuration type - you loose
flexibility in this case, e.g. adding cache will most likely be a pain or a
complete restart. CONFIG SET may work, but for redis this is some kind of
global configuration, so it is pretty far from, let's say, MySQL's USE
command. I would think this should work on per-connection basis, but CONFIG
SET seems to be global.

I would think about using SELECT command for this. I think it may work as
follows. By default client is connected to database '0'. Upon first request
from the client IgniteCache with name "redis-ignite-internal-cache-0" gets
created. Same for other databases - "redis-ignite-itnernal-cache-XX". User
can register a config template for these caches.

This approach seems to be more intuitive for Redis users.

Thoughts?

--Yakov


   

Re: Changing cache name when using Redis protocol

[Yakov Zhdanov <yz...@apache.org>]

Roman,

I don't like implementing of special configuration type - you loose
flexibility in this case, e.g. adding cache will most likely be a pain or a
complete restart. CONFIG SET may work, but for redis this is some kind of
global configuration, so it is pretty far from, let's say, MySQL's USE
command. I would think this should work on per-connection basis, but CONFIG
SET seems to be global.

I would think about using SELECT command for this. I think it may work as
follows. By default client is connected to database '0'. Upon first request
from the client IgniteCache with name "redis-ignite-internal-cache-0" gets
created. Same for other databases - "redis-ignite-itnernal-cache-XX". User
can register a config template for these caches.

This approach seems to be more intuitive for Redis users.

Thoughts?

--Yakov