I remember couple more thing for 2.0 How about to drop **ignite-scalar** module in Ignite 2.0? And may be drop **ignite-spark-2.10** module support as of **Spark** 2 is on **scala 2.11**.
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
