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