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
