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
