ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shtykh <rsht...@yahoo.com.INVALID>
Subject Re: Null cache names
Date Wed, 26 Apr 2017 05:58:21 GMT
Denis,
PR is created. https://issues.apache.org/jira/browse/IGNITE-5083 for review.
We will have to find a good solution to "externalize" the default cache name in future, as
Vladimir suggested. As Igor pointed out, probably for memcached too.I'll create another JIRA
issue for that.
Roman
 

    On Wednesday, April 26, 2017 1:16 PM, Denis Magda <dmagda@apache.org> wrote:
 

 > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message