ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yakov Zhdanov <yzhda...@apache.org>
Subject Re: Ignite 2.0 tasks/roadmap
Date Tue, 02 Aug 2016 07:45:32 GMT
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
> > > > >
> > > >
> > >
> >
>

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