Sound reasonable. Please create a ticket and paste it number into this discussion.
— Denis > On Nov 10, 2016, at 1:27 AM, Sergey Kozlov <skoz...@gridgain.com> wrote: > > Hi > > It seems the Spring dependency looks outdated for now. Apache Ignite still > uses 4.1.0 released two years ago. Could we include to the list of issues > for the release 2.0 to update to latest stable version (4.3.4 at the > moment)? > > On Tue, Nov 1, 2016 at 12:39 PM, Alexey Goncharuk < > alexey.goncha...@gmail.com> wrote: > >> Yakov, >> >> I've created a ticket for using discovery custom events instead of >> marshaller cache: https://issues.apache.org/jira/browse/IGNITE-4157 >> >> Guys, feel free to comment. >> >> Thanks! >> AG >> >> 2016-09-09 20:53 GMT+03:00 Denis Magda <dma...@gridgain.com>: >> >>> I’ve created an umbrella ticket for REST >>> https://issues.apache.org/jira/browse/IGNITE-3879 < >>> https://issues.apache.org/jira/browse/IGNITE-3879> >>> >>> And I wouldn’t deprecate anything until the next version gets released ;) >>> >>> — >>> Denis >>> >>>> On Sep 9, 2016, at 6:37 AM, Sergey Kozlov <skoz...@gridgain.com> >> wrote: >>>> >>>> Denis >>>> >>>> Generally I'm fine for your approach. I think for 2.0 (or may be for a >>> next >>>> 1.x minor version) we can note that currently REST API is deprecated. >> It >>>> will allow us to replace REST by a new implementation once it will be >>> done. >>>> >>>> On Fri, Sep 9, 2016 at 4:11 PM, Denis Magda <dma...@gridgain.com> >> wrote: >>>> >>>>> Sergey, >>>>> >>>>> I do agree with you that Ignite’s REST API implementation has to be >>>>> revisited. Your concerns sound reasonable. But personally I wouldn’t >>> rush >>>>> trying to release it under 2.0 because NodeJS won’t be a part of this >>>>> release while it can propose additional requirements to the next >>> generation >>>>> of REST API implementation. >>>>> >>>>> Does it make sense to you? >>>>> >>>>> — >>>>> Denis >>>>> >>>>>> On Sep 9, 2016, at 1:56 AM, Sergey Kozlov <skoz...@gridgain.com> >>> wrote: >>>>>> >>>>>> Vova, >>>>>> >>>>>> There are more issues than processing (String, String) only: we can't >>>>>> process JSON objects as values, current implementation doesn't follow >>>>>> general RESTfull API requirements. >>>>>> Moreover we're still have no connectors for PHP, Python and other >>> popular >>>>>> languages for web development of LAMP market and REST API is a single >>> way >>>>>> get access to Apache Ignite. >>>>>> >>>>>> On Fri, Sep 9, 2016 at 10:39 AM, Vladimir Ozerov < >> voze...@gridgain.com >>>> >>>>>> wrote: >>>>>> >>>>>>> Denis, >>>>>>> >>>>>>> Very good catch! Our REST API in ir is current appearance are >>> virtually >>>>>>> useless because it only operates on strings. We'd better to design >> the >>>>> new >>>>>>> one.with blackjack and etc.. >>>>>>> >>>>>>> On Fri, Sep 9, 2016 at 3:39 AM, Denis Magda <dma...@gridgain.com> >>>>> wrote: >>>>>>> >>>>>>>> Basically, we can have two versions of the REST API if we want to >>> care >>>>>>>> about the compatibility and remove the old one (deprecated) at some >>>>> point >>>>>>>> of time. Moreover, NodeJS feature [1] can highly influence on the >>> next >>>>>>>> generation of our REST API implementation. So I wouldn’t introduce >>> the >>>>>>> next >>>>>>>> version of REST API implementation before NodeJS component is done. >>>>>>>> >>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-961 >>>>>>>> >>>>>>>> — >>>>>>>> Denis >>>>>>>> >>>>>>>>> On Sep 8, 2016, at 1:54 AM, Sergey Kozlov <skoz...@gridgain.com> >>>>>>> wrote: >>>>>>>>> >>>>>>>>> I agree with Alexey. >>>>>>>>> >>>>>>>>> The key point is a chance to don't care for compatibility. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Sep 8, 2016 at 9:56 AM, Alexey Kuznetsov < >>>>>>>> akuznet...@gridgain.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Just my opinion. If we move this to 2.1 that will result that we >>> will >>>>>>>> have >>>>>>>>>> to support 2 versions of REST APIs. >>>>>>>>>> In Ignite 2.0 we could break compatibility and redesign REST API >>> from >>>>>>>>>> scratch. >>>>>>>>>> >>>>>>>>>> On Thu, Sep 8, 2016 at 1:23 PM, Denis Magda <dma...@gridgain.com >>> >>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> I would move it to 2.1 or 2.2. >>>>>>>>>>> >>>>>>>>>>> — >>>>>>>>>>> Denis >>>>>>>>>>> >>>>>>>>>>>> On Sep 7, 2016, at 3:58 PM, Dmitriy Setrakyan < >>>>>>> dsetrak...@apache.org> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Sergey, I don't think we can fit redesigning of HTTP/REST into >>> our >>>>>>> 2.0 >>>>>>>>>>>> release. The 2.0 already looks pretty packed. Perhaps we should >>>>> plan >>>>>>>> it >>>>>>>>>>> for >>>>>>>>>>>> the release after, like 2.1? >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Sep 7, 2016 at 3:00 AM, Sergey Kozlov < >>>>> skoz...@gridgain.com >>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi >>>>>>>>>>>>> >>>>>>>>>>>>> I suppose we should redesign HTTP REST API. We've a dozen >> issues >>>>>>>>>> around >>>>>>>>>>> the >>>>>>>>>>>>> REST implementation and the provided functionality is very >>> limited >>>>>>>> and >>>>>>>>>>>>> doesn't follow last changes for Ignite. The most suitable >> ticket >>>>> is >>>>>>>>>>>>> IGNITE-1774 >>>>>>>>>>>>> REST API should be implemented using Jersey >>>>>>>>>>>>> <https://issues.apache.org/jira/browse/IGNITE-1774> but >>> probably >>>>>>> we >>>>>>>>>>> need >>>>>>>>>>>>> to >>>>>>>>>>>>> have a root ticket for that. >>>>>>>>>>>>> >>>>>>>>>>>>> On Sat, Sep 3, 2016 at 9:28 PM, Dmitriy Setrakyan < >>>>>>>>>>> dsetrak...@apache.org> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Denis, thanks for taking a role of a release manger for 2.0. >> It >>>>> is >>>>>>>>>>>>>> definitely an important release for us and good supervision >> is >>>>>>> going >>>>>>>>>> to >>>>>>>>>>>>> be >>>>>>>>>>>>>> very helpful. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have looked at the tickets and the list seems nice. I would >>>>> also >>>>>>>>>> add >>>>>>>>>>> a >>>>>>>>>>>>>> ticket about migration of the JTA dependency to Geronimo as >>> well, >>>>>>>>>>>>>> IGNITE-3793 [1], however I am not sure if we might be able to >>> do >>>>>>> it >>>>>>>>>>> prior >>>>>>>>>>>>>> to 2.0. >>>>>>>>>>>>>> >>>>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-3793 >>>>>>>>>>>>>> >>>>>>>>>>>>>> D. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sat, Sep 3, 2016 at 3:17 AM, Denis Magda < >>> dma...@gridgain.com >>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Community, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Let me take a role of the release manager for Apache Ignite >>> 2.0 >>>>>>> and >>>>>>>>>>>>>>> coordinate the process. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So, my personal view is that Apache Ignite 2.0 should be >>>>> released >>>>>>>> by >>>>>>>>>>>>> the >>>>>>>>>>>>>>> end of the year. This sounds like a good practice to make a >>>>> major >>>>>>>>>>>>> release >>>>>>>>>>>>>>> once a year. I would suggest us following the same rule. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Actual we have more than 3 month for development and I’ve >>>>> prepare >>>>>>>>>> the >>>>>>>>>>>>>> wiki >>>>>>>>>>>>>>> page that contains tickets that are required to be released >> in >>>>>>> 2.0 >>>>>>>>>> and >>>>>>>>>>>>>> that >>>>>>>>>>>>>>> are optional >>>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/IGNITE/ >>>>>>>>>> Apache+Ignite+2.0 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Proposed release date is December 23rd, 2016. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The tickets that are required for the release basically >> break >>>>> the >>>>>>>>>>>>>>> compatibility and we postpone fixing them in minor release >> or >>>>>>> they >>>>>>>>>>>>> bring >>>>>>>>>>>>>>> significant improvements into the product. Please review the >>>>>>> page, >>>>>>>>>>>>>> provide >>>>>>>>>>>>>>> your comments and assign the tickets on yourself if you’re >>> ready >>>>>>> to >>>>>>>>>>>>> work >>>>>>>>>>>>>> on >>>>>>>>>>>>>>> them. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> — >>>>>>>>>>>>>>> Denis >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Aug 11, 2016, at 4:06 PM, Valentin Kulichenko < >>>>>>>>>>>>>>> valentin.kuliche...@gmail.com> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There is one more use case where several types per cache >> can >>> be >>>>>>>>>>>>> useful >>>>>>>>>>>>>> (I >>>>>>>>>>>>>>>> know that it's utilized by some of our users). The use case >>> is >>>>>>> the >>>>>>>>>>>>>>>> following: transactional updates with write-behind and >>> foreign >>>>>>> key >>>>>>>>>>>>>>>> constraints on the database. In case data within >> transaction >>> is >>>>>>>>>>>>>>> collocated >>>>>>>>>>>>>>>> and all types are in the same cache, it works, because >> there >>> is >>>>>>>>>> only >>>>>>>>>>>>>> one >>>>>>>>>>>>>>>> write-behind queue. Once we split different types into >>>>> different >>>>>>>>>>>>>> caches, >>>>>>>>>>>>>>>> there is no guarantee that objects will be written in the >>>>> proper >>>>>>>>>>>>> order >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> that the constraints will not be violated. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> However, I think this is not a very clean way to achieve >> the >>>>>>>>>> result. >>>>>>>>>>>>>>>> Probably we should just provide better support for this use >>>>> case >>>>>>>> in >>>>>>>>>>>>>> 2.0. >>>>>>>>>>>>>>>> Basically, we somehow need to allow to share a single >>>>>>> write-behind >>>>>>>>>>>>>> queue >>>>>>>>>>>>>>>> between different caches. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Any thoughts? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -Val >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 10:40 AM, Dmitriy Setrakyan < >>>>>>>>>>>>>>> dsetrak...@apache.org> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov < >>>>>>>>>>>>> skoz...@gridgain.com> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Alexey >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> You're right. Of course I meant growth of caches number. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I see a few points here: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 1. If a grid used by various applications the cache names >>> may >>>>>>>>>>>>> overlap >>>>>>>>>>>>>>>>> (like >>>>>>>>>>>>>>>>>> "accounts") and the application needs to use prefixed >> names >>>>>>> and >>>>>>>>>>>>> etc. >>>>>>>>>>>>>>>>>> 2. For clear or destory caches I need to know their names >>> (or >>>>>>>>>>>>> iterate >>>>>>>>>>>>>>>>> over >>>>>>>>>>>>>>>>>> caches but I'm not sure that it is supported by API). For >>>>>>>>>>>>>> destroy/clear >>>>>>>>>>>>>>>>>> caches belonging to same group we will do it by single >>>>>>> operation >>>>>>>>>>>>>>> without >>>>>>>>>>>>>>>>>> knowledge of cache names. >>>>>>>>>>>>>>>>>> 3. Cache group can have cache attributes which will be >>>>>>> inherited >>>>>>>>>>>>> by a >>>>>>>>>>>>>>>>> cache >>>>>>>>>>>>>>>>>> created in that group (like eviction policy or cache >> mode). >>>>>>>>>>>>>>>>>> 4. No reason to add specific feature like SqlShema if it >>>>>>>>>> applicable >>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>> regular caches as well. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Sergey K, setting the same SQL schema for multiple caches, >>> as >>>>>>>>>>>>> proposed >>>>>>>>>>>>>>> by >>>>>>>>>>>>>>>>> Sergi, solves a different problem of having too many SQL >>>>>>> schemas >>>>>>>>>> due >>>>>>>>>>>>>> to >>>>>>>>>>>>>>> too >>>>>>>>>>>>>>>>> many different caches. I think Sergi proposed a good >>> solution >>>>>>> for >>>>>>>>>>>>> it. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov < >>>>>>>>>>>>>>>>> akuznet...@gridgain.com >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Sergey, I belive you mean "increase" instead of >> "reduce"? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> How grouping will help? >>>>>>>>>>>>>>>>>>> To do some operation, for example, clear on group of >>> cashes >>>>>>> at >>>>>>>>>>>>> once? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" < >>>>>>>>>>>>>>>>> skoz...@gridgain.com> >>>>>>>>>>>>>>>>>>> написал: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I mean not only SQL features for caches. Single type >> per >>>>>>> cache >>>>>>>>>>>>>>>>>> definitely >>>>>>>>>>>>>>>>>>>> reduces number of caches for regular user and grouping >>>>>>> caches >>>>>>>>>>>>> will >>>>>>>>>>>>>>>>> help >>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>> manage caches in grid. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Thu, Aug 11, 2016 at 5:41 PM, Sergi Vladykin < >>>>>>>>>>>>>>>>>>> sergi.vlady...@gmail.com> >>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I'm aware of this issue. My plan was to allow setting >>> the >>>>>>>> same >>>>>>>>>>>>>>>>> schema >>>>>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>>>>>>> to different caches using CacheConfiguration. >>>>>>>>>> setSqlSchema(...). >>>>>>>>>>>>>>>>> This >>>>>>>>>>>>>>>>>>> way >>>>>>>>>>>>>>>>>>>>> we >>>>>>>>>>>>>>>>>>>>> will have separate caches but from SQL point of view >>>>>>>>>> respective >>>>>>>>>>>>>>>>>> tables >>>>>>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>>>>>>> reside in the same schema. No need to introduce new >>>>>>> concepts. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Sergi >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 2016-08-11 17:24 GMT+03:00 Sergey Kozlov < >>>>>>>>>> skoz...@gridgain.com >>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>>>>>>> dsetrak...@apache.org >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>> Sergey Kozlov >>>>>>>>>>>>>>>>>>>>>> GridGain Systems >>>>>>>>>>>>>>>>>>>>>> www.gridgain.com >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> Sergey Kozlov >>>>>>>>>>>>>>>>>>>> GridGain Systems >>>>>>>>>>>>>>>>>>>> www.gridgain.com >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Sergey Kozlov >>>>>>>>>>>>>>>>>> GridGain Systems >>>>>>>>>>>>>>>>>> www.gridgain.com >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Sergey Kozlov >>>>>>>>>>>>> GridGain Systems >>>>>>>>>>>>> www.gridgain.com >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Alexey Kuznetsov >>>>>>>>>> GridGain Systems >>>>>>>>>> www.gridgain.com >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Sergey Kozlov >>>>>>>>> GridGain Systems >>>>>>>>> www.gridgain.com >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Sergey Kozlov >>>>>> GridGain Systems >>>>>> www.gridgain.com >>>>> >>>>> >>>> >>>> >>>> -- >>>> Sergey Kozlov >>>> GridGain Systems >>>> www.gridgain.com >>> >>> >> > > > > -- > Sergey Kozlov > GridGain Systems > www.gridgain.com
