I agree with Ivan, let's return an error on any attempt to create or use a
LOCAL cache from thin clients.
On Tue, Sep 14, 2021 at 2:25 PM Ivan Daschinsky wrote:
> I am not about creation per se, but creation from a thin client side.
>
> This feature simply doesn't work as expected, broken and im
I am not about creation per se, but creation from a thin client side.
This feature simply doesn't work as expected, broken and impossible to fix.
It cannot broke any code, because it was already broken and it is
impossible to use in production.
But it still can embarrass newcomers and brings a lot
Ivan,
I don't think we should rush with this. Banning the creation of LOCAL
caches without a warning through the code sounds not good. Will it be
better to do everything in three steps (releases)? 2.12 deprecate,
2.13 forbid new cache creation, 2.14 remove.
On Tue, 14 Sept 2021 at 12:09, Ivan Das
Few thoughts about LOCAL caches on thin client:
1. If partition awareness is disabled:
a. Inconsistent behaviour if node to which client is connected goes down.
2. If partition awareness is enabled:
a. For Java and .NET -- same as 1a
b. For C++ and python -- use random routing for caches that are
>> Unsupported operation exception.
Binary protocol doesn't have a concept of exception, only error status and
message, but it is just a remark
I suppose that response with error status and message is ok, but may be
others have different opinion?
>> Removal should happen at 2.13.
A few thin client
> 1. What is expected behaviour if an old thin client requests creation of
> LOCAL cache on the newest ignite cluster?
Unsupported operation exception.
> 2. Should we completely remove LOCAL caches support in thin clients (i.e.
pyignite) before 2.13 release?
Removal should happen at 2.13.
On Tue,
>> 2. 2.13 - complete removal LOCAL caches from codebase.
Let's discuss this step with more details.
1. What is expected behaviour if an old thin client requests creation of
LOCAL cache on the newest ignite cluster?
2. Should we completely remove LOCAL caches support in thin clients (i.e.
pyignite)
I proposed the following plan:
1. 2.12 - deprecation of LOCAL caches.
2. 2.13 - complete removal LOCAL caches from codebase.
> 13 сент. 2021 г., в 13:30, Ivan Daschinsky написал(а):
>
> I personally support deprecation, but we should at least have a plan.
> I suppose that putting annotations a
I personally support deprecation, but we should at least have a plan.
I suppose that putting annotations and removing documentation are not
enough.
пн, 13 сент. 2021 г. в 13:22, Maxim Muzafarov :
> Ivan,
>
> I don't think we can remove LOCAL caches at the nearest time, so there
> is no plan for
Ivan,
I don't think we can remove LOCAL caches at the nearest time, so there
is no plan for that. I can only imagine a single release that will
contain all the breaking changes we want to apply in 2.x version.
My point here is only about deprecation:
- there are a lot of motivation points to remo
Hi, Maxim. And what is the plan of removing this functionality? And I also
have some questions regarding deprecation in binary protocol
Currently thin client binary protocol
1. Does support LOCAL caches
2. Does not support node filters.
I can hardly imagine the usefulness of this feature on thin
Folks,
Let's get back to the discussion of obsolete LOCAL caches since a lot
of time has passed since the last discussion.
I've created an issue [1] for deprecation. Let's deprecate them at
least at the next 2.12 release.
WDYT?
[1] https://issues.apache.org/jira/browse/IGNITE-15499
On Fri, 27
Guys,
Use cases for local caches are rare, but they definitely exist. I don't
think it's a very good idea to deprecate this functionality at this point.
At the same point, it's obviously not the most critical part of the
product, so maintaining the whole separate implementation for it is
probably
Hi Dmitriy,
I would like to stress this: I'm not saying local cache it useless. I'm
supposing it is not used widely. I want to figure out if I'm mistaking.
All folks involved into user list says it is not used, so why not to
deprecate? If we make a mistake, somebody will come to user list and say
Guys,
I just want to make sure we are all on the same page. The main use case for
LOCAL caches is to have a local hash map querable with SQL and
automatically persisted to a 3rd party DB.
I want to discourage people from saying "nobody needs some feature". None
of the people in this discussion ar
Hi Alexey,
There is nothing to be sorry about :) Сommunity appreciates an alternative
vision, this allows us to make as informed decisions as it possible.
Thank you for finding this fact, it is very interesting.
I'm not sure all these examples were prepared by experienced Ignite users.
So idea o
t;
> > Stan
> >
> > From: Pavel Kovalenko
> > Sent: 25 июля 2018 г. 15:27
> > To: dev@ignite.apache.org
> > Subject: Re: Deprecating LOCAL cache
> >
> > It's not easy to just make such caches as PARTITIONED with NodeFilter.
> > Even in the case when
pect.
>
> Stan
>
> From: Pavel Kovalenko
> Sent: 25 июля 2018 г. 15:27
> To: dev@ignite.apache.org
> Subject: Re: Deprecating LOCAL cache
>
> It's not easy to just make such caches as PARTITIONED with NodeFilter.
> Even in the case when a node is not affinity no
Sorry, guys, I'll put my 1 cent
I'd like this idea "Implement LOCAL caches as PARTITIONED caches over the
local node."
It make sense for examples/testing in pseudo-distributed mode and so far.
But I think that the deprecation based on user-list mentions is a wrong
way. Please look here
https://g
I meant LOCAL + non-LOCAL transactions of course.
On Wed, Jul 25, 2018 at 10:42 PM Dmitriy Setrakyan
wrote:
> Vladimir,
>
> Are you suggesting that a user cannot span more than one local cache in a
> cross cache LOCAL transactions. This is extremely surprising to me, as it
> would require almost
Vladimir,
Are you suggesting that a user cannot span more than one local cache in a
cross cache LOCAL transactions. This is extremely surprising to me, as it
would require almost no effort to support it. As far as mixing the local
caches with distributed caches, then I agree, cross-cache transacti
From: Pavel Kovalenko
Sent: 25 июля 2018 г. 15:27
To: dev@ignite.apache.org
Subject: Re: Deprecating LOCAL cache
It's not easy to just make such caches as PARTITIONED with NodeFilter.
Even in the case when a node is not affinity node for this cache we create
entities like GridClientPartitionTopolog
Not sure that we can create cache with same name by different clients for
this approach.
On Wed, Jul 25, 2018 at 12:35 PM, Pavel Kovalenko
wrote:
> It's not easy to just make such caches as PARTITIONED with NodeFilter.
> Even in the case when a node is not affinity node for this cache we create
Vladimir, do we have a ticket for cross-cache transactions with LOCAL
cache? I can't find it. In my task I met this situation in tests and I want
to fail such tests with link to this ticket.
2018-07-25 12:55 GMT+03:00 Vladimir Ozerov :
> Dima,
>
> LOCAL cache adds very little value to the product
Hello!
I have never seen the usage of LOCAL cache so far, so I am for its
deprecation.
Regards,
--
Ilya Kasnacheev
2018-07-25 12:55 GMT+03:00 Vladimir Ozerov :
> Dima,
>
> LOCAL cache adds very little value to the product. It doesn't support
> cross-cache transactions, consumes a lot of memor
Hi Igniters,
I've never seen the LOCAL cache in the user list for 1 year. I've tried to
search in archives and found only that mention
http://apache-ignite-users.70518.x6.nabble.com/LOCAL-cache-and-EntryProcessor-td7419.html
in
2016.
Who can provide any additional usage examples?
My vote goes to
It's not easy to just make such caches as PARTITIONED with NodeFilter.
Even in the case when a node is not affinity node for this cache we create
entities like GridClientPartitionTopology for such caches on all nodes.
These caches participate in the exchange, calculate affinity, etc. on all
nodes.
Setrakyan
Sent: 25 июля 2018 г. 11:51
To: dev
Subject: Re: Deprecating LOCAL cache
I would stay away from deprecating such huge pieces as a whole LOCAL cache.
In retrospect, we should probably not even have LOCAL caches, but now I am
certain that it is used by many users.
I would do one of the following
cleaning.
>
> Stan
>
> From: Valentin Kulichenko
> Sent: 25 июля 2018 г. 11:09
> To: dev@ignite.apache.org
> Subject: Re: Deprecating LOCAL cache
>
> It sounds like the main drawback of LOCAL cache is that it's implemented
> separately and therefore has to be maintained
@ignite.apache.org
Subject: Re: Deprecating LOCAL cache
It sounds like the main drawback of LOCAL cache is that it's implemented
separately and therefore has to be maintained separately. If that's the
only issue, why not keep LOCAL cache mode on public API, but implement it
as a PARTITIONED cache w
Dima,
LOCAL cache adds very little value to the product. It doesn't support
cross-cache transactions, consumes a lot of memory, much slower than any
widely-used concurrent hash map. Let's go the same way as Java - mark LOCAL
cache as "deprecated for removal", and then remove it in 3.0.
On Wed, Ju
+1 to make LOCAL as filtered PARTITIONED cache. I think it would be much
easier and faster than fixing all bugs.
2018-07-25 11:51 GMT+03:00 Dmitriy Setrakyan :
> I would stay away from deprecating such huge pieces as a whole LOCAL cache.
> In retrospect, we should probably not even have LOCAL cac
I would stay away from deprecating such huge pieces as a whole LOCAL cache.
In retrospect, we should probably not even have LOCAL caches, but now I am
certain that it is used by many users.
I would do one of the following, whichever one is easier:
- Fix the issues found with LOCAL caches, incl
It sounds like the main drawback of LOCAL cache is that it's implemented
separately and therefore has to be maintained separately. If that's the
only issue, why not keep LOCAL cache mode on public API, but implement it
as a PARTITIONED cache with a node filter forcefully set? That's similar to
what
Huge +1 from me.
One more SO question about LOCAL caches -
https://stackoverflow.com/questions/49051079/is-it-possible-to-perform-sql-query-with-distributed-join-over-a-local-cache-and
"It is not possible to perform joins (both distributed an co-located) between
LOCAL and PARTITIONED caches. Th
35 matches
Mail list logo
