ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Ignite 2.0 tasks/roadmap
Date Thu, 11 Aug 2016 17:40:49 GMT
On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <skozlov@gridgain.com> wrote:

> Alexey
>
> You're right. Of course I meant growth of caches number.
>
> I see a few points here:
>
> 1. If a grid used by various applications the cache names may overlap (like
> "accounts") and the application needs to use prefixed names and etc.
> 2. For clear or destory caches I need to know their names (or iterate over
> caches but I'm not sure that it is supported by API). For destroy/clear
> caches belonging to same group we will do it by single operation without
> knowledge of cache names.
> 3. Cache group can have cache attributes which will be inherited by a cache
> created in that group (like eviction policy or cache mode).
> 4. No reason to add specific feature like SqlShema if it applicable for
> regular caches as well.
>

Sergey K, setting the same SQL schema for multiple caches, as proposed by
Sergi, solves a different problem of having too many SQL schemas due to too
many different caches. I think Sergi proposed a good solution for it.


>
> On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov <akuznetsov@gridgain.com
> >
> wrote:
>
> > Sergey, I belive you mean "increase" instead of "reduce"?
> >
> > How grouping will help?
> > To do some operation, for example, clear on group of cashes at once?
> >
> > 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <skozlov@gridgain.com>
> > написал:
> >
> > > I mean not only SQL features for caches. Single type per cache
> definitely
> > > reduces number of caches for regular user and grouping caches will help
> > to
> > > manage caches in grid.
> > >
> > > On Thu, Aug 11, 2016 at 5:41 PM, Sergi Vladykin <
> > sergi.vladykin@gmail.com>
> > > wrote:
> > >
> > > > I'm aware of this issue. My plan was to allow setting the same schema
> > > name
> > > > to different caches using CacheConfiguration.setSqlSchema(...). This
> > way
> > > > we
> > > > will have separate caches but from SQL point of view respective
> tables
> > > will
> > > > reside in the same schema. No need to introduce new concepts.
> > > >
> > > > Sergi
> > > >
> > > >
> > > > 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <skozlov@gridgain.com>:
> > > >
> > > > > HI
> > > > >
> > > > > Due to approach to disable to store more than one type per cache
> the
> > > > cache
> > > > > use becomes similar the table use for databases.
> > > > > So I suppose would be good to introduce a database/schema-similar
> > > concept
> > > > > for caches. It may be implemented as a non-default behavior for
> > > backward
> > > > > compatibility.
> > > > >
> > > > > On Sat, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan <
> > > dsetrakyan@apache.org
> > > > >
> > > > > wrote:
> > > > >
> > > > > > On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
> > > > > akuznetsov@gridgain.com>
> > > > > > wrote:
> > > > > >
> > > > > > > I remember couple more thing for 2.0
> > > > > > >
> > > > > > > How about to drop **ignite-scalar** module in Ignite 2.0?
> > > > > > >
> > > > > >
> > > > > > Why?
> > > > > >
> > > > > >
> > > > > > > And may be drop **ignite-spark-2.10** module support as
of
> > > **Spark**
> > > > 2
> > > > > is
> > > > > > > on **scala 2.11**.
> > > > > > >
> > > > > >
> > > > > > I would drop it only if it is difficult to support. Do we know
> what
> > > > kind
> > > > > of
> > > > > > impact will it have on the community? Anyone is still using
2.10?
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <
> > dmagda@gridgain.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > Let’s add this [1] issue to the list because it
requires
> > > > significant
> > > > > > work
> > > > > > > > on the side of metrics SPI.
> > > > > > > >
> > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-3495
<
> > > > > > > > https://issues.apache.org/jira/browse/IGNITE-3495>
> > > > > > > >
> > > > > > > > —
> > > > > > > > Denis
> > > > > > > >
> > > > > > > > > On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov <
> > > yzhdanov@apache.org>
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Not yet. The thing is that our recent experience
showed
> that
> > it
> > > > was
> > > > > > not
> > > > > > > > > very good idea to go with caches. E.g. when you
try to
> > > > deserialize
> > > > > > > inside
> > > > > > > > > continuous query listener on client side it implicitly
> calls
> > > > > > > cache.get()
> > > > > > > > > which in turn may cause deadlock under some circumstances.
> > > > > > > > >
> > > > > > > > > --Yakov
> > > > > > > > >
> > > > > > > > > 2016-08-02 2:41 GMT+03:00 Dmitriy Setrakyan <
> > > > dsetrakyan@apache.org
> > > > > >:
> > > > > > > > >
> > > > > > > > >> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov
<
> > > > > yzhdanov@apache.org>
> > > > > > > > wrote:
> > > > > > > > >>
> > > > > > > > >>> One more point.
> > > > > > > > >>>
> > > > > > > > >>> I insist on stop using marshaller and
meta caches but
> > switch
> > > to
> > > > > > > > spreading
> > > > > > > > >>> this info via custom discovery events.
> > > > > > > > >>>
> > > > > > > > >>
> > > > > > > > >> Do we have a ticket explaining why this needs
to be done?
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>>
> > > > > > > > >>> --Yakov
> > > > > > > > >>>
> > > > > > > > >>> 2016-07-27 19:57 GMT+03:00 Dmitriy Setrakyan
<
> > > > > > dsetrakyan@apache.org
> > > > > > > >:
> > > > > > > > >>>
> > > > > > > > >>>> On Wed, Jul 27, 2016 at 11:36 AM,
Yakov Zhdanov <
> > > > > > > yzhdanov@apache.org>
> > > > > > > > >>>> wrote:
> > > > > > > > >>>>
> > > > > > > > >>>>> Guys, I think we can also split
event notification for
> > user
> > > > > > > listeners
> > > > > > > > >>> and
> > > > > > > > >>>>> internal system listeners. I
have been seeing a lot of
> > > issues
> > > > > > > caused
> > > > > > > > >> by
> > > > > > > > >>>>> some heavy or blocking operations
in user-defined
> > > listeners.
> > > > > This
> > > > > > > may
> > > > > > > > >>>> block
> > > > > > > > >>>>> internal component notification
(e.g. on discovery
> event)
> > > > > causing
> > > > > > > > >>>> topology
> > > > > > > > >>>>> hangings.
> > > > > > > > >>>>>
> > > > > > > > >>>>
> > > > > > > > >>>> Sure. There are a lot of features
being added. Would be
> > nice
> > > > to
> > > > > > > assign
> > > > > > > > >> a
> > > > > > > > >>>> release manager for Ignite 2.0 and
document all the
> > > discussed
> > > > > > > features
> > > > > > > > >> on
> > > > > > > > >>>> the Wiki.
> > > > > > > > >>>>
> > > > > > > > >>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>> --Yakov
> > > > > > > > >>>>>
> > > > > > > > >>>>> 2016-06-25 2:42 GMT+03:00 Alexey
Goncharuk <
> > > > > > > > >> alexey.goncharuk@gmail.com
> > > > > > > > >>>> :
> > > > > > > > >>>>>
> > > > > > > > >>>>>> Folks,
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> Recently I have seen a couple
of emails suggesting
> > > > > > > > >> tasks/improvements
> > > > > > > > >>>>> that
> > > > > > > > >>>>>> we cannot do in 1.x releases
due to API compatibility
> > > > reasons,
> > > > > > so
> > > > > > > > >>> they
> > > > > > > > >>>>> are
> > > > > > > > >>>>>> postponed to 2.0. I would
like to keep track of these
> > > tasks
> > > > in
> > > > > > > some
> > > > > > > > >>> way
> > > > > > > > >>>>> in
> > > > > > > > >>>>>> our Jira to make sure we
do not have anything obsolete
> > > when
> > > > it
> > > > > > > > >> comes
> > > > > > > > >>> to
> > > > > > > > >>>>> the
> > > > > > > > >>>>>> next major version release.
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> My question for now is how
should we track such tasks?
> > > > Should
> > > > > it
> > > > > > > > >> be a
> > > > > > > > >>>>>> label, a parent task with
subtasks, something else?
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> I would go with a label +
release version.
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> --AG
> > > > > > > > >>>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>
> > > > > > > > >>>
> > > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Alexey Kuznetsov
> > > > > > > GridGain Systems
> > > > > > > www.gridgain.com
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Sergey Kozlov
> > > > > GridGain Systems
> > > > > www.gridgain.com
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Sergey Kozlov
> > > GridGain Systems
> > > www.gridgain.com
> > >
> >
>
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message