IGNITE-4211 Update Sprint dependency to latest stable version <https://issues.apache.org/jira/browse/IGNITE-4211>
On Thu, Nov 10, 2016 at 5:57 PM, Denis Magda <dma...@gridgain.com> wrote: > 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 > > -- Sergey Kozlov GridGain Systems www.gridgain.com
