ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Kozlov <skoz...@gridgain.com>
Subject Re: Ignite 2.0 tasks/roadmap
Date Thu, 11 Aug 2016 14:24:26 GMT
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

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