ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Kuznetsov <akuznet...@gridgain.com>
Subject Re: Ignite 2.0 tasks/roadmap
Date Thu, 11 Aug 2016 15:58:56 GMT
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
>

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