ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@apache.org>
Subject Re: Null cache names
Date Wed, 26 Apr 2017 04:16:01 GMT
> So it is approach 1 ("redis_cache") I proposed initially. Any concerns? If it is ok, I
set Redis to that cache and update the documentation.

Let’s handle the way Roman suggests. Don’t see any reason why we keep discussing this
if the whole story is about a “one line” fix.

Roman, could you implement your suggestion and do a pull-request?

—
Denis

> On Apr 25, 2017, at 6:53 PM, Roman Shtykh <rshtykh@yahoo.com.INVALID> wrote:
> 
> Vladimir,
> I agree. But, if I get it right, according to your concern for using memcached and Redis
simultaneously, we'll need a separate default cache for each. So it is approach 1 ("redis_cache")
I proposed initially. Any concerns? If it is ok, I set Redis to that cache and update the
documentation.
> Btw, I agree ConnectorConfiguration is not the proper place, but having 'jettyPath' in
it made me think it could be done ;) Probably we will need refactoring to make it generic
and more separate configuration classes as more protocols get implemented.
> Roman 
> 
>    On Wednesday, April 26, 2017 4:49 AM, Sergi Vladykin <sergi.vladykin@gmail.com>
wrote:
> 
> 
> Agree, lets move forward with the simplest possible solution for now.
> 
> Sergi
> 
> 2017-04-25 13:07 GMT+03:00 Vladimir Ozerov <vozerov@gridgain.com>:
> 
>> Folks,
>> 
>> I do not think it is legal to add such property to ConnectorConfiguration.
>> Connector is a generic gateway to cluster resources. It should not bother
>> about caches anyhow. What if there are multiple caches in the cluster? What
>> is I want to access "cache A" from Memcached and "cache B" from Redis
>> simultaneously? Etc.. This kind of property should be defined on client
>> level, not on the server.
>> 
>> For now, provided that 2.0 is about to be freezed, I propose to stick to
>> Dmitriy's approach and use "default" cache name instead of null. This
>> should work fine for AI 2.0. We will be able to improve it in further
>> releases.
>> 
>> Thoughts?
>> 
>> Vladimir.
>> 
>> On Tue, Apr 25, 2017 at 7:22 AM, Roman Shtykh <rshtykh@yahoo.com.invalid>
>> wrote:
>> 
>>> Igor, +1 from me.We can add a field to ConnectorConfiguration (not sure
>> if
>>> it's a proper place, but it's shared by REST, memcached and Redis). A
>> user
>>> will have to create a cache, configure as needed and specify the name in
>>> ConnectorConfiguration.
>>> Roman
>>> 
>>> 
>>> 
>>>     On Monday, April 24, 2017 10:34 PM, Seliverstov Igor <
>>> gvvinblade@gmail.com> wrote:
>>> 
>>> 
>>>   Dear Igniters,
>>> 
>>> Seems we have almost the same issue with Memcached protocol.
>>> 
>>> There is an ability to define a cache name via operation extras message
>>> part (
>>> https://github.com/memcached/memcached/wiki/
>> BinaryProtocolRevamped#packet-
>>> structure)
>>> but it looks a bit complicated from my point of view...
>>> 
>>> Different client implementations might provide such functionality or not
>> (I
>>> mean an additional info in an operation extras), so, potential user might
>>> have some difficultes using Ignite as a Memcached server because of this
>>> ignite-specific message part becomes mandatory.
>>> 
>>> An alternative (an the best way, I think) is introducing a configuration
>>> property to define which cache to use in case it hasn't be defined in a
>>> message.
>>> 
>>> I'll appreciate any thoughts on that.
>>> 
>>> Regards,
>>> Igor
>>> 
>>> 2017-04-24 12:43 GMT+03:00 Roman Shtykh <rshtykh@yahoo.com.invalid>:
>>> 
>>>> Vladimir,
>>>> Probably we may set the cache name via https://redis.io/commands/
>>>> client-setname, save it and use until the user specifies another name.
>>>> #That will be the name for the default cache (mainly for STRING data).
>>> For
>>>> other data types, like hashes (https://redis.io/topics/data-types), I
>> am
>>>> thinking about putting data into caches specified by key.
>>>> Or use https://redis.io/commands/config-set CONFIG SET DFLT_CACHE
>>>> cache_name,and save cache name somewhere in Ignite cluster (what is the
>>>> proper place to store such info?).
>>>> For that, we have to implement one of the above-mentioned commands.
>>>> What do you think?
>>>> 
>>>> 
>>>> 
>>>>     On Monday, April 24, 2017 4:34 PM, Vladimir Ozerov <
>>>> vozerov@gridgain.com> wrote:
>>>> 
>>>> 
>>>>   Roman,
>>>> Is it possible to define a kind of property in Redis connection string
>>> (or
>>>> property map) for this purpose? IMO ideally we should "externalize"
>> cache
>>>> name somehow, so that it can be changed with no changes to user's code.
>>>> 
>>>> Alex,
>>>> Not sure if this is a good idea as you will end up with PARTITIONED
>> cache
>>>> without backups with no ability to change that.
>>>> 
>>>> On Mon, Apr 24, 2017 at 9:35 AM, Alexey Kuznetsov <
>> akuznetsov@apache.org
>>>> 
>>>> wrote:
>>>> 
>>>>> Roman,
>>>>> 
>>>>> Just as idea, how about in case of user does not configured
>>> "REDIS_CACHE"
>>>>>   then create it via ignite.getOrCreateCache(new
>>>>> CacheConfiguration("REDIS_CACHE"))
>>>>> and prin warning to log "REDIS_CACHE not configured, using default
>>>>> partitioned cache".
>>>>> 
>>>>> What do you think?
>>>>> 
>>>>> On Mon, Apr 24, 2017 at 10:26 AM, Roman Shtykh
>>> <rshtykh@yahoo.com.invalid
>>>>> 
>>>>> wrote:
>>>>> 
>>>>>> Denis, Igor,
>>>>>> What can be done now
>>>>>> 1. create a default cache name for Redis data, e.g. "REDIS_CACHE"
>>> that
>>>>> has
>>>>>> to be configured explicitly in xml file (as it is done with other
>>>> caches)
>>>>>> by a user if he/she needs Redis protocol.
>>>>>> 2. Force users to specify cache names as prefix to their keys, so
>>> that
>>>> we
>>>>>> can parse and switch between caches.
>>>>>> The 1st one is a very quick fix I can do today. This can be
>> extended
>>> in
>>>>>> future to have a separate cache for each data type.
>>>>>> Roman
>>>>>> 
>>>>>> 
>>>>>>     On Monday, April 24, 2017 12:15 AM, Denis Magda <
>>>> dmagda@gridgain.com
>>>>>> 
>>>>>> wrote:
>>>>>> 
>>>>>> 
>>>>>>   Roman, would you suggest a quick solution for the redis
>> integration
>>> or
>>>>>> even
>>>>>> implement it in the nearest couple of days? We need to change the
>>>> defaul
>>>>>> cache name in 2.0. Otherwise, it can be done only in an year or so
>> in
>>>>> 3.0.
>>>>>> 
>>>>>> Denis
>>>>>> 
>>>>>> On Sunday, April 23, 2017, Seliverstov Igor <gvvinblade@gmail.com>
>>>>> wrote:
>>>>>> 
>>>>>>> Hi Roman,
>>>>>>> 
>>>>>>> The ticket number is IGNITE-3488.
>>>>>>> 
>>>>>>> It's planned not to have null-named or default caches at all.
All
>>> the
>>>>>>> caches must be defined explicitly or via templates and have
>> names.
>>>> The
>>>>>>> current implementation uses a cache with null name, so, we need
>>> some
>>>>>>> configuration property to define which cache to use or mapping
in
>>>> case
>>>>> of
>>>>>>> using Redis databases.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Igor
>>>>>>> 
>>>>>>> 22 апр. 2017 г. 8:47 пользователь "Roman Shtykh"
>>>>>> <rshtykh@yahoo.com.invalid
>>>>>>>> 
>>>>>>> написал:
>>>>>>> 
>>>>>>>> Hi Igor,
>>>>>>>> The current implementation supports only STRING data type
of
>>> Redis.
>>>>> In
>>>>>>>> addition, AFAIK, scaling Redis per dataset is normally done
via
>>>>> running
>>>>>>>> separate instances of Redis for each dataset. Therefore my
>> choice
>>>> was
>>>>>>>> storing to the default cache. It looks fine from Redis'
>>>> perspective,
>>>>>> but
>>>>>>>> probably not from Ignite's.For other data types like HASH
or
>>> SORTED
>>>>>> SET,
>>>>>>> I
>>>>>>>> planned to specify cache name by key and treat value inside
as
>>>>> Ignite's
>>>>>>>> key-values.# Redis has a notion of 'database' and you can
>> switch
>>>>>> between
>>>>>>>> them, but they can be referred only by the number, and limited
>> to
>>>> 16
>>>>>>>> databases... Not very useful, IMO.
>>>>>>>> If you still have the default cache, the current Redis
>>> integration
>>>>>> should
>>>>>>>> work as is (I have to recheck it, what is the JIRA ticket
for
>> the
>>>>> null
>>>>>>>> cache issue?)
>>>>>>>> Do you just want to be sure your changes don't affect the
Redis
>>>>>>>> integration, or do you want to extend it to switch between
>>> caches?
>>>>>>>> Roman
>>>>>>>> 
>>>>>>>>     On Friday, April 21, 2017 8:17 PM, Seliverstov Igor <
>>>>>>>> gvvinblade@gmail.com <javascript:;>> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>>   Hi Roman,
>>>>>>>> 
>>>>>>>> As far as I inderstand you're the author of the Redis protocol
>>>>>>>> implementation.
>>>>>>>> 
>>>>>>>> Currently I'm working on a task to prohibit null names for
>> caches
>>>> and
>>>>>>> I've
>>>>>>>> found that current implementation implies using of default
(aka
>>>> null
>>>>>>> named)
>>>>>>>> cache as a Redis database.
>>>>>>>> 
>>>>>>>> So, I need your assistance to implement Redis databases and
>>>> mappings
>>>>>> them
>>>>>>>> to particular caches.
>>>>>>>> 
>>>>>>>> Is it in your plans to do it in near time?
>>>>>>>> 
>>>>>>>> If not I'll appriciate your thoughts on how to do it properly)
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Igor
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Alexey Kuznetsov
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
> 


Mime
View raw message