On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <akuznet...@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 <dma...@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 <yzhda...@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 <dsetrak...@apache.org>: > > > > > >> On Mon, Aug 1, 2016 at 3:46 AM, Yakov Zhdanov <yzhda...@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 <dsetrak...@apache.org > >: > > >>> > > >>>> On Wed, Jul 27, 2016 at 11:36 AM, Yakov Zhdanov < > yzhda...@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.goncha...@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 >
