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