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 >>>>>> >>>>> >>>> >>> >>
